Skip to main content
Last updated: June 29, 2026Latest Frontend Version:

Management Console Overview

The Management Console is the central administration interface in tiCrypt. Access it via the Management icon in the top-left taskbar. tiCrypt defines three administrator roles, each with a different scope in the Management Console: Sub-Admins see only the teams and projects assigned to them, while Admins and Super Admins see the full system. Several Management views and settings, such as deployment settings, system services, and licensing configuration, are restricted to Super Admins only.

The console contains nine sections, each with one or more tables. This article covers every section and table: what it controls, how it connects to the rest of tiCrypt, and what administrators need to know day-to-day.

How tiCrypt Entities Connect​

The diagram below shows the relationships between core tiCrypt entities. Understanding these connections is essential for effective administration.

Key relationships:

  • Users must belong to at least one team to be active. Removing a user from all teams automatically deactivates them.
  • Teams define resource quotas (CPU cores, memory, storage). Every VM and drive consumes quota from the team it belongs to.
  • User profiles bundle a role (User, Sub-Admin, Admin, Super Admin) with granular permissions. Apply profiles to users individually or in bulk.
  • Projects restrict resource access through tagging. A file, drive, VM, or inbox tagged with a project is accessible only to active project members.
  • Security levels and requirements add certification gates to projects. Users must hold valid certifications for every requirement at the project's security level to access its resources.
  • Onboarding templates automate the setup of new users by pre-assigning profiles, teams, projects, and certifications in a single action.

Users​

The Users section handles identity management. It references teams and projects, which are defined in their own sections below. In brief: teams control resource allocation (every VM and drive belongs to a team), and projects restrict access to resources by tagging them so only authorized members can use them.

Every person who logs into tiCrypt has a user account created and maintained here. The typical provisioning workflow is:

  1. User registers for a tiCrypt account.
  2. Apply a User Profile that configures three things:
    • Permissions: granular controls across categories including Basic Vault Interaction, Basic Group Interaction, Basic Project Interaction, Basic VM Interaction, Basic Team Interaction, Project Management, VM Administration, Team Administration, User Administration, and Miscellaneous.
    • Role: User, Sub-Admin, Admin, or Super Admin. Each role determines what level of the Management Console the user can access. Super Admins always have all permissions, can modify system-wide settings, and control licensing server entries.
    • State: Active (standard activation) or Active and escrow on next login (the user is activated, but their encryption keys are backed up on their next login so they can be recovered if the user loses access).
  3. Add to team(s) so the user has access to resources. Users cannot be active without at least one team.

Steps 2 and 3 can be combined into a single action using an Onboarding Template, a reusable configuration that pre-assigns a user profile, team memberships, project memberships, certifications, and VM configurations all at once. See the Onboarding subsection below.

Users​

The primary user directory. Each row represents a tiCrypt account with its name, email, role, and state (Active, Inactive, or Active and escrow on next login). Bulk actions available from this table:

  • Add to onboard template applies an onboarding template that pre-configures teams, projects, permissions, and certifications in one action.
  • Add to team(s) / project(s) assigns users to teams (resource groups) and projects (access-controlled groupings of resources; see the Projects section below).
  • Add certification grants attestations confirming a user meets specific security requirements (e.g., training completion, clearance verification). See the Projects section below for details.
  • Change state activates, deactivates, or flags accounts for key escrow on next login (a recovery process that backs up the user's encryption keys so they can be recovered if the user loses access).
  • Refresh user info refreshes the displayed user information.
  • Apply profile assigns a permission profile (a named bundle of granular permissions).
  • Change role promotes or demotes users between User, Sub-Admin, Admin, and Super Admin.
  • Make announcement sends a notification to selected users.
  • Bulk email sends email to selected users.
  • Export CSV / JSON exports user data for external analysis.

A user removed from all teams is automatically deactivated. Conversely, a user cannot be activated until they belong to at least one team.

User Profiles​

User Profiles (also called Permission Profiles) bundle a role with granular permissions into a named template. Instead of configuring permissions per user, administrators create custom profiles and apply them in bulk. Organizations can create as many or as few profiles as they need. A few example profiles are provided as starting points, but most organizations define their own.

For example, a tiCrypt deployment might define functionality-based profiles like these. Expand each profile to view its individual permissions.

Standard User with VM Access -- Role: User | Full Vault and VM access | Data export allowed

Basic Vault Interaction

  • View metadata for own files (necessary to download)
  • View access/sharing/project history of own files
  • View keys for own files (necessary to download)
  • Download own files' content
  • Create file metadata
  • View directories
  • Create directories
  • Create entries in directories

Basic Group Interaction

  • View groups they are a member of
  • View keys for groups they are a member of
  • Create groups
  • Rename own groups and transfer ownership
  • Add users to groups they are a member of
  • Edit other members in groups they are a member of
  • Remove other users from groups they are a member of
  • Delete groups they are the owner of

Basic Project Interaction

  • View projects they are a member of
  • View other members in projects they are a member of
  • View all security requirements in the system
  • View all security levels in the system
  • View own security requirement certifications
  • Classify resources with projects they are active in

Basic VM Interaction

  • View drives
  • Create drives
  • Edit drives (name and whether to disable backup)
  • View drive keys (necessary to share/attach)
  • Share drives
  • Unshare drives
  • Attach drives to VMs
  • Detach drives from VMs
  • View hardware/image setups made available to them
  • View own VM configs and configs shared with them
  • Create (and edit) VM configs
  • Spawn VMs from VM configs
  • Stop VMs spawned from VM configs
  • View own VM username
  • View anyone's VM username (necessary for sharing VMs)
  • Create sub-session for VM-to-Vault direct transfer
  • View own VMs and VMs shared with them
  • Spawn VMs (without a config)
  • Connect to own VMs and VMs shared with them
  • Share VMs with other users
  • Shutdown own VMs

Basic Team Interaction

  • View own teams
  • Edit own teams (depending on stature per-team)

Miscellaneous

  • Transfer ownership of own files and drives

Not included: Project Management, VM Administration, Team Administration, User Administration.

No Data Export User -- Role: User | Full Vault access | Data export blocked | Full VM access

Basic Vault Interaction

  • View metadata for own files
  • View access/sharing/project history of own files
  • View keys for own files
  • Download own files' content Blocked
  • Create file metadata
  • View directories
  • Create directories
  • Create entries in directories

Basic Group Interaction

  • View groups they are a member of
  • View keys for groups they are a member of
  • Create groups
  • Rename own groups and transfer ownership
  • Add users to groups they are a member of
  • Edit other members in groups they are a member of
  • Remove other users from groups they are a member of
  • Delete groups they are the owner of

Basic Project Interaction

  • View projects they are a member of
  • View other members in projects they are a member of
  • View all security requirements in the system
  • View all security levels in the system
  • View own security requirement certifications
  • Classify resources with projects they are active in

Basic VM Interaction

  • View drives
  • Create drives
  • Edit drives (name and whether to disable backup)
  • View drive keys (necessary to share/attach)
  • Share drives
  • Unshare drives
  • Attach drives to VMs
  • Detach drives from VMs
  • View hardware/image setups made available to them
  • View own VM configs and configs shared with them
  • Create (and edit) VM configs
  • Spawn VMs from VM configs
  • Stop VMs spawned from VM configs
  • View own VM username
  • View anyone's VM username (necessary for sharing VMs)
  • Create sub-session for VM-to-Vault direct transfer Blocked
  • View own VMs and VMs shared with them
  • Spawn VMs (without a config)
  • Connect to own VMs and VMs shared with them
  • Share VMs with other users
  • Shutdown own VMs

Basic Team Interaction

  • View own teams
  • Edit own teams (depending on stature per-team)

Miscellaneous

  • Transfer ownership of own files and drives

Not included: Project Management, VM Administration, Team Administration, User Administration.

Standard User with No VM Access -- Role: User | Full Vault access | Data export allowed | No VM access

Basic Vault Interaction

  • View metadata for own files (necessary to download)
  • View access/sharing/project history of own files
  • View keys for own files (necessary to download)
  • Download own files' content
  • Create file metadata
  • View directories
  • Create directories
  • Create entries in directories

Basic Group Interaction

  • View groups they are a member of
  • View keys for groups they are a member of
  • Create groups
  • Rename own groups and transfer ownership
  • Add users to groups they are a member of
  • Edit other members in groups they are a member of
  • Remove other users from groups they are a member of
  • Delete groups they are the owner of

Basic Project Interaction

  • View projects they are a member of
  • View other members in projects they are a member of
  • View all security requirements in the system
  • View all security levels in the system
  • View own security requirement certifications
  • Classify resources with projects they are active in

Basic Team Interaction

  • View own teams
  • Edit own teams (depending on stature per-team)

Miscellaneous

  • Transfer ownership of own files and drives

Not included: Basic VM Interaction, Project Management, VM Administration, Team Administration, User Administration.

Sub Admin -- Role: Sub-Admin | Full Vault and VM access | Manages assigned teams and projects

Basic Vault Interaction

  • View metadata for own files (necessary to download)
  • View access/sharing/project history of own files
  • View keys for own files (necessary to download)
  • Download own files' content
  • Create file metadata
  • View directories
  • Create directories
  • Create entries in directories

Basic Group Interaction

  • View groups they are a member of
  • View keys for groups they are a member of
  • Create groups
  • Rename own groups and transfer ownership
  • Add users to groups they are a member of
  • Edit other members in groups they are a member of
  • Remove other users from groups they are a member of
  • Delete groups they are the owner of

Basic Project Interaction

  • View projects they are a member of
  • View other members in projects they are a member of
  • View all security requirements in the system
  • View all security levels in the system
  • View own security requirement certifications
  • Classify resources with projects they are active in

Project Management (scoped to managed projects)

  • Declassify resources tagged with projects they manage
  • Create subprojects of projects they manage
  • Edit metadata for projects they manage
  • Delete projects they manage
  • Add users to projects they manage
  • Edit memberships in projects they manage
  • Remove users from projects they manage
  • Certify users for security requirements
  • Edit user certifications for security requirements
  • Delete user certifications for security requirements

Basic VM Interaction

  • View drives
  • Create drives
  • Edit drives (name and whether to disable backup)
  • View drive keys (necessary to share/attach)
  • Share drives
  • Unshare drives
  • Attach drives to VMs
  • Detach drives from VMs
  • View hardware/image setups made available to them
  • View own VM configs and configs shared with them
  • Create (and edit) VM configs
  • Spawn VMs from VM configs
  • Stop VMs spawned from VM configs
  • View own VM username
  • View anyone's VM username (necessary for sharing VMs)
  • Create sub-session for VM-to-Vault direct transfer
  • View own VMs and VMs shared with them
  • Spawn VMs (without a config)
  • Connect to own VMs and VMs shared with them
  • Share VMs with other users
  • Shutdown own VMs

Basic Team Interaction

  • View own teams
  • Edit own teams (depending on stature per-team)

User Administration (scoped to managed objects)

  • View all users in the system
  • Edit their own and lower-roled users' metadata
  • Edit lower-roled users' permissions
  • View profiles (role/permission templates)
  • Activate lower-roled users
  • Deactivate lower-roled users
  • Require lower-roled users to escrow their key

Miscellaneous

  • Transfer ownership of own files and drives

Not included: VM Administration, Team Administration (full system scope).

Super Admin -- Role: Super Admin | All permissions | Full system access

Super Admins have all permissions across all categories. This includes every permission listed in the profiles above, plus:

Team Administration

  • Create teams
  • Edit any team in the system arbitrarily
  • Delete any team in the system arbitrarily
  • Add users to any team arbitrarily
  • Modify any team membership arbitrarily
  • Remove users from any team arbitrarily

User Administration (full system scope)

  • View all users in the system
  • Edit their own and lower-roled users' metadata
  • Edit lower-roled users' permissions
  • Promote lower-roled users up to own role
  • Demote lower-roled users to even lower role
  • View, create, edit, and delete profiles
  • Activate and deactivate lower-roled users
  • Require lower-roled users to escrow their key
  • Delete lower-roled users

VM Administration

  • Delete arbitrary drives
  • View, create, edit, and delete Libvirt storage pools
  • View and upload raw Libvirt volumes (images)
  • View, create, edit, and delete VM images
  • View, create, edit, and delete hardware/image setups
  • View, edit, and delete any VM config
  • View host machines and hardware information in any Libvirt realm
  • Create, edit, and delete hardware profiles
  • Register, edit, and delete VM host machines in Libvirt realms
  • Modify any user's VM username
  • View logs from any VM

System Settings

  • View, edit, and delete system settings

Escrow Management

  • Escrow own key
  • Check if own key is escrowed
  • View all escrowed keys in the system
  • List escrow recovery keys
  • Delete escrowed keys
  • View escrow groups and escrow users

Profiles can be created from scratch or cloned from an existing profile. Editing permissions in a profile changes user access throughout the system for all users assigned to that profile.

Groups​

Groups are collaborative collections of users that share access to resources. Unlike teams (which govern resource quotas), groups are organizational units for shared access and delegation. For example, a research group might include a PI and three students who all need access to the same set of project drives. Groups can be associated with projects, and membership determines which resources are visible to group members.

Onboarding​

Onboarding Templates automate new-user provisioning. Each template bundles:

  • An initial state (Active, Inactive, or Active and escrow on next login)
  • A permission profile (role and permissions)
  • Team memberships
  • Project memberships with roles and restrictions
  • Security requirement certifications
  • VM configurations

Applying a template assigns all of these in a single operation. This is essential for organizations that register users in batches (for example, at the start of a research program) and need consistent, repeatable provisioning.

Resources by User​

A lookup view showing all resources tied to a specific user: teams, projects, drives, certifications, and admin notes. This is the fastest way to audit a user's access without navigating multiple sections.

Sub-Admin Managed Objects​

Maps teams and projects to Sub-Admin accounts for delegated administration. When a Sub-Admin is assigned a managed object, they gain administrative control (creating subprojects, managing members, editing metadata) without full Admin privileges.

Assignments can carry expiration dates for temporary delegation, such as granting a project lead admin rights for the duration of a study. Assignments are created here or generated automatically when a Sub-Admin is promoted to team manager.

Deleted Users​

A recovery interface for soft-deleted accounts. Deleting a user from the Users table moves the account here rather than destroying it permanently. Administrators can restore deleted accounts. Restored users can log in and access all their recovered data in the Vault; however, their roles and permissions are not restored and must be re-assigned manually.

Teams​

Teams are tiCrypt's resource allocation mechanism. Every drive, VM configuration, and running VM belongs to a team, making teams the enforcement point for resource consumption.

Teams​

The primary team directory. Each team has a name, description, member list, and quota configuration defining resource limits:

  • Total and per-user VM cores control CPU core allocation to running VMs.
  • Total and per-user memory control RAM allocation to running VMs.
  • Storage pool allocations limit drive capacity per Libvirt storage pool.
  • Device allocations limit PCI/USB device assignment (GPUs, accelerators).

Setting a quota to zero or removing it entirely grants unlimited access to that resource. This is intentional for administrative or infrastructure teams that should not be constrained.

Teams can be assigned to Sub-Admins for delegated management. All members must be removed before a team can be deleted.

Team Memberships​

A cross-reference view showing which users belong to which teams. Supports bulk management of team composition and is useful for auditing membership across the organization. Removing a user from their last team triggers automatic deactivation.

Projects​

Projects are a tagging mechanism with system-enforced separation. When a drive, VM, file, or secure inbox (a mechanism for receiving files from external sources) is tagged with a project, only active, certified members of that project can access it. This enforcement is automatic and cannot be bypassed by administrators. Projects organize resources around research efforts, contracts, or compliance boundaries.

To grant a user access to a project with a security level:

  1. Define security requirements at the system level (e.g., MFA enrollment, training completion).
  2. Create a security level that groups the required security requirements together.
  3. Assign the security level to the project.
  4. Grant certifications to the user for each required security requirement.
  5. Add the user to the project. Access is granted only when all certifications are satisfied.

Projects​

The project directory showing all top-level projects and subprojects. Each project has:

  • A name and color-coded tag for visual identification across the interface.
  • An optional security level that activates the certification requirement system.
  • A principal investigator field.
  • Support for nested subprojects (subprojects inherit the parent's security model but can define their own members).

Resources tagged with a project are restricted to active, certified members only. Project tags on VMs are enforced on restart (changing a tag on a running VM does not take effect until reboot). Projects can be assigned to Sub-Admins for delegated management.

Project Memberships​

Tracks user membership within projects. Each membership record includes:

  • Role within the project (member, manager).
  • Expiration date (optional; if unset, membership is indefinite).
  • Restrictions (optional constraints on what the member can do within the project).

Members can be added individually or in bulk, and membership records can be edited to update roles, expirations, or restrictions.

Security Levels​

Classification tiers for projects. Each security level specifies a set of named security requirements that members must satisfy. Projects without a security level are accessible to any active member; projects with one require members to hold valid certifications for all requirements at that level.

Security levels create a formal access control layer above basic project membership, suitable for regulated environments (CMMC, ITAR, HIPAA) where specific training, clearances, or attestations are required.

Security Requirements​

Named conditions within each security level. Requirements can represent any organization-defined criteria: MFA enrollment, training completion, background check clearance, data handling certification, or custom attestations. Each requirement is paired with a certification that administrators or project managers grant to individual users.

User Certifications​

Records which users hold certifications for which security requirements. Each certification has a creation date, an optional expiration date, and can be renewed or manually marked as expired. This table is the compliance tracking ledger: who is qualified for what, when qualifications expire, and who granted the certification.

Revoking a certification immediately removes access to all resources tagged with projects that require it.

Resources by Project​

An aggregated view of all resources tied to a specific project: member list, drives, security settings, and certification status of all members. This is the project-level equivalent of Resources by User, providing a single view for project auditing.

Virtual Machines​

The largest section in Management, covering the full VM infrastructure stack from hardware hosts through storage to running instances. The subsections below are ordered from most frequently used to most foundational.

The infrastructure dependency chain builds from the bottom up:

  1. Realms define isolated VM execution environments, each with its own hosts and storage.
  2. Libvirt Hosts and Storage Pools provide the physical compute and storage within a realm.
  3. Volumes in storage pools back VM Images (boot disks) and Drives (user data).
  4. Hardware Profiles describe what each host offers; Hardware Setups pair an image with resource requirements.
  5. VM Configurations combine a hardware setup, drives, team, and optional project tag into a launchable template.
  6. Running VMs and Past VMs are the live and historical results of launching configurations.

Running VMs​

All currently active virtual machines across all realms (independent VM execution environments; see the Realms subsection below). Each entry shows the VM's configuration name, owner, host, allocated resources, and state. Administrators can:

  • Connect via RDP, terminal, or file explorer.
  • Transfer files between the VM and the Vault.
  • Manage user accounts and groups within the VM.
  • Stop or restart the VM.

This is the real-time operations view for monitoring what is running on the infrastructure.

VM Configurations​

Saved templates defining everything needed to launch a VM:

  • Hardware setup (which image and resource profile to use).
  • Home drive (always read-write, created with the configuration).
  • Extra drives (read-write or read-only, attached at launch).
  • Team (which team's quotas this VM consumes).
  • Project tag (optional; restricts access to project members).
  • Preferred host and MAC address (optional scheduling hints).

Configurations can be shared with co-owners who receive full read-write access. Administrators can spawn or stop VMs directly from this table.

VM Hardware Setups​

Pre-configured hardware specifications pairing a VM image with resource requirements: CPU cores, memory, PCI/USB devices, and NFS mounts. Users select a hardware setup when creating a VM configuration. Hardware setups determine what resources the VM consumes from its team's quotas.

VM Images​

The boot image library. Each image contains an operating system (Linux or Windows) and the tiCrypt VM Installer. Images are immutable and reset on every boot, preventing malware persistence. They are stored as qcow2 (QEMU Copy-On-Write) volumes in Libvirt storage pools and support ext4, btrfs, ntfs, xfs, and zfs filesystems.

The image-to-VM path works as follows: a qcow2 volume becomes a VM image (adding OS type, name, and filesystem metadata), which is then paired with a hardware setup that specifies CPU, memory, restrictions (team quotas, access control), and optional devices (GPUs, accelerators, NFS mounts).

Administrators manage the image lifecycle here: creating new images from service VMs, assigning images to hardware setups, and retiring old images.

Drives​

All encrypted virtual drives across the system. Each drive has an owner, team, optional project tag, format (EXT4, BTRFS, NTFS, XFS, ZFS), and capacity. Drives are encrypted inside the VM using LUKS (Linux Unified Key Setup) for Linux or BitLocker for Windows, with encryption keys provided by the data owner.

A read-write drive can attach to only one VM at a time; a read-only drive can attach to multiple VMs simultaneously. Administrators can view drive metadata but cannot access drive contents, since encryption keys never persist on the infrastructure.

Devices​

PCI and USB hardware registered in the system: GPUs, accelerators, specialized peripherals, and other passthrough devices. Devices are allocated to VMs through hardware setups and tracked against team quotas. Administrators register new hardware, assign it to hosts, and manage availability here.

Hardware Profiles​

Server-level resource definitions describing what a VM host can provide: CPU cores, memory, PCI devices, and a scheduling weight. Each host machine is assigned a hardware profile, and the scheduler uses these weights to determine optimal VM placement.

Hardware profiles are distinct from hardware setups: profiles describe what a host has; setups describe what a VM needs.

Libvirt Hosts​

Physical machines registered in Libvirt realms that execute VMs. Each host has:

  • A state: Enabled (accepting new VMs), Do not schedule new VMs (the host is connected but VMs are not scheduled), or Disabled (fully offline).
  • Utilization metrics: current CPU, memory, and device usage.
  • NAT settings: optional static address translation for backend connectivity.
  • MAC address list: for NVIDIA licensing and network identity.

Hosts connect to three networks via OpenVSwitch bridges: the secure network (user VMs), the service network (service VMs), and the data-in network (used by VMs that ingest external data).

Libvirt Storage Pools​

Storage pools provide backing volumes for VM drives and images. Each pool is typed by purpose:

  • Drives: user data volumes.
  • Hardware Setups: VM image volumes.
  • Raw Volumes: unmanaged storage.
  • Images: base OS images.
  • ISOs: installation media.
  • Miscellaneous: other storage needs.

Pools are scoped to a realm with a filesystem path that must be writable on both the VM host and backend. tiCrypt requires pool types that support dynamic volume creation (directory, filesystem, LVM, Ceph RBD, GlusterFS, ZFS). iSCSI pools require layering LVM on top for dynamic provisioning.

Libvirt Volumes​

Raw storage volumes managed by Libvirt. Each volume belongs to a storage pool and serves as backing storage for a drive or VM image. This table shows capacity, allocation, and pool association. Volumes are the lowest-level storage abstraction in tiCrypt's VM infrastructure. Most administrators interact with drives and images rather than volumes directly; this table is primarily useful for troubleshooting storage issues or verifying pool utilization.

ISO Images​

Installation media (ISO format) available for VM provisioning. ISOs can be bootable (for OS installation in service VMs) or service-only (for driver or software installation). Each ISO can be assigned to specific teams and users for access control.

Licensing Servers​

External license management servers for VM software. Each entry defines a server address, TCP/UDP protocol, port, and expiration date. A backend firewall service creates iptables rules that permit the VM to reach the licensing server while blocking all other outbound traffic.

Common use cases: Windows activation (KMS), SAS, ArcGIS, MATLAB, and other commercial software requiring periodic license validation.

NFS Mounts​

Network filesystem paths mounted into VMs at specific slots. NFS mounts provide shared access to centralized storage, typically for large reference datasets, shared application installations, or common tool libraries. Mounts can be configured as read-only or read-write and are set in hardware setups. In secure VMs, NFS mounts are always read-only.

Service VMs​

Administrator-managed VMs that boot on a separate, unrestricted network (br-service) with general internet access. Service VMs are used for image preparation, software installation, and package updates. They operate outside the secure enclave and are managed through a VNC terminal rather than the standard tiCrypt proxy channel. Deleting a service VM leaves its images intact for reuse.

Past VMs​

Historical records of previously running VMs. Each record includes creation and termination timestamps, the configuration used, the host it ran on, and archived logs. When investigating what happened on a VM that no longer exists, Past VMs provides the forensic trail.

Realms​

Fully independent VM execution environments. Each realm has its own:

  • VM images and drive storage.
  • Host machines.
  • Libvirt storage pools.
  • Scheduling infrastructure.

Realms provide complete isolation between infrastructure domains. A typical deployment separates production research VMs from development or testing environments into different realms. Realm configuration is defined in the ticrypt-vm.conf backend configuration file.

Slurm​

The Slurm section manages tiCrypt's integration with Slurm, an open-source workload manager for high-performance computing (HPC) clusters. Slurm schedules batch jobs (non-interactive computational tasks such as simulations, data analysis, or model training) across a pool of compute nodes. tiCrypt extends Slurm with a dual-scheduler architecture. A batch job follows this path:

  1. User submits a job through tiCrypt.
  2. Global Slurm (cluster-wide) allocates cores, memory, and nodes.
  3. Worker VMs are launched inside encrypted enclaves on the allocated nodes.
  4. Local Slurm (inside the VM) executes the job, with access to job scripts and data.
  5. Job completes and the worker VM is destroyed along with its encryption keys.

Global Slurm handles cluster-wide resource allocation (cores, memory, nodes) while Local Slurm instances run inside encrypted VM enclaves where they can see job scripts and data. The Management Console provides visibility into both layers.

Active Jobs​

Currently running Slurm batch jobs. Each entry shows the job ID, submitting user, status, allocated resources (cores, memory, nodes), and execution timestamps. This is the real-time view of HPC work running on the cluster.

Past Jobs​

Historical records of completed, canceled, or failed jobs. Each record includes the final state, resource consumption, and performance metrics. Use this table for post-mortem analysis of batch processing operations.

Nodes​

All Slurm compute nodes in the HPC cluster. Each node shows its hardware specifications, current state (idle, allocated, mixed, drained, down), and resource availability. Administrators monitor cluster capacity and drain nodes for maintenance here.

Worker VMs​

Virtual machines serving as Slurm worker nodes. Each worker VM runs inside the encrypted enclave and is destroyed when its job completes, along with its encryption keys. This table shows which VMs are currently executing batch jobs.

User Accounts​

Slurm user accounts with resource allocation limits, fair share weights, and cumulative usage metrics. Fair share is a scheduling policy that adjusts job priority based on each user's historical resource consumption, preventing any single user from monopolizing the cluster. Administrators configure per-user limits and monitor historical usage here.

VM Accounts​

Slurm accounts linked to specific VM configurations. VM accounts bridge tiCrypt's VM-based resource model and Slurm's account-based scheduling model. Each account tracks share allocations, usage statistics, and Slurm accounting hierarchy levels.

Slurm Configuration​

A read-only view of all cluster configuration parameters: scheduler policies, partition definitions, resource limits, and accounting settings. Use this to verify that the Slurm configuration matches operational requirements.

Slurm Diagnostics​

Real-time diagnostics for the Slurm scheduler:

  • Job statistics (submitted, started, completed, failed).
  • Main scheduler performance metrics (in microseconds).
  • Backfill scheduler statistics and exit states.
  • RPC call statistics by message type and by user.
  • Pending RPC counts.

This is the primary tool for monitoring scheduler health and diagnosing performance issues in the HPC cluster.

Escrow​

The Escrow section manages key recovery. Because tiCrypt uses a zero-knowledge architecture (the server infrastructure never holds or has access to users' encryption keys), a recovery mechanism is essential for organizational continuity when users lose access to their accounts.

The key recovery process works as follows:

  1. Key escrow: The user's private key is used to generate a recovery key (AES-256), which is split into shards, one per escrow group.
  2. Shard distribution: Each shard is encrypted with every group member's public key, so any member of a group can contribute that group's shard.
  3. Recovery process: One representative from each escrow group contributes their shard to reconstruct the recovery key.
  4. Key recovery: The recovery key decrypts the user's private key, restoring access.

Escrow Groups​

Escrow groups are sets of escrow officers who collectively manage private key recovery. A minimum of three groups is required. During key escrow, the recovery key is split into shards, one per group. Each shard is encrypted with every group member's public key, so any member of a group can contribute that group's shard. Recovery requires one representative from each group to contribute their shard; no individual or single group can unilaterally recover a user's private key.

Escrow Users​

Escrow officers who participate in key recovery. Each has a dedicated RSA key pair and a separate account outside the main tiCrypt system. Their public key is signed by the site key (the root signing key for the tiCrypt deployment), or by another escrow user whose key is already signed by the site key, establishing a chain of trust. To maintain separation of duties, escrow users should not be regular tiCrypt users.

Escrow Certificates​

Signed certificates for escrow operations:

  • Escrow group creation certificates: authorize new escrow groups.
  • User activation certificates: authorize escrow user accounts.
  • Deletion request certificates: authorize removal of escrow users or groups.

Each certificate is signed by the site key to establish chain-of-trust authority (see Escrow Users above). This table serves as the audit trail for all escrow administrative actions.

Settings​

The Settings section controls system-wide configuration that affects all users and services.

System Settings​

The centralized configuration interface for global parameters, organized into categories:

  • Logo: login logos, branding, login ID validation, login messages.
  • Servers: backend URLs, external SFTP inbox endpoints, survey deployment servers, XSS headers.
  • Timeouts: private key timeout, session inactivity timeout.
  • User: copy settings, helpdesk configuration, password strength requirements.
  • Caching: caching configuration and policies.
  • Files: file-related settings.
  • Notices: system-wide notification configuration.
  • Miscellaneous: additional system-wide settings.

Changes take effect immediately and are tracked in System Settings History for audit purposes.

System Settings History​

A complete audit trail of settings changes. Each entry shows the setting name, previous value, new value, timestamp, and the administrator who made the change. Supports compliance requirements for change management and provides a rollback reference when a change causes unexpected behavior.

Custom Fields​

Organization-specific metadata fields that appear in team and project creation dialogs. Supported input types:

  • Text: free-form text entry.
  • Number: numeric input with optional validation.
  • Date: date picker.
  • Custom Select: selection from predefined custom choices.

Fields can be marked as mandatory or optional, reordered, and previewed before deployment. Useful for capturing data tiCrypt does not track by default, such as grant numbers, contract IDs, or IRB approval numbers.

Operations and Monitoring​

The Operations section provides visibility into runtime health and programmatic access to tiCrypt.

System Services​

All backend services with their current status, version, uptime, and logs: ticrypt-auth, ticrypt-rest, ticrypt-vm, ticrypt-file-manager, ticrypt-proxy, ticrypt-logger, and others. Administrators can view logs and restart services from this table.

Check here first when investigating system issues: a stopped or unhealthy service explains downstream failures in user-facing functionality.

Audit Logs​

An in-application view of the audit trail. Every significant action is logged: user logins, file operations, VM lifecycle events, administrative changes, and security events. Supports filtering by time range, user, and action type, with export to CSV or JSON for external analysis.

For the full audit platform with advanced queries and reports, see the Audit section below.

REST API​

Documentation and reference for the tiCrypt REST API: available endpoints, authentication methods (API key and session token), request/response formats, and usage examples. The REST API enables programmatic access for automation, external integration, and custom tooling.

API Keys​

Authentication tokens for the REST API. Each key has:

  • Purpose: what the key is used for.
  • Creator: the administrator who created it.
  • Expiration: when it becomes invalid.
  • Hash: a unique identifier (the key value itself is shown only at creation).

Create keys for specific integrations and revoke them when no longer needed or when rotating keys after a security incident.

External SFTP Servers​

External SFTP servers that tiCrypt users and VMs can access for data transfer. Each entry includes connection details, credentials, and access policies. Use this to establish outbound data pathways when data must be pushed from tiCrypt to external systems.

Audit​

The Audit section connects to tiCrypt Audit, the separately deployed audit platform. While Operations includes basic in-application audit logs, this section provides access to the full deployment for deep analysis.

The tiCrypt Audit platform ingests secure logs from the backend via a one-way TCP connection (port 25000) and stores them in ClickHouse for high-performance columnar analysis. Audit data is protected by a tamper-evident hash chain: each log record incorporates the SHA-256 hash of the previous record, making any modification detectable.

The section includes:

  • Overview: dashboard with summary metrics and recent activity.
  • Queries: a TOML-based query builder for structured searches against the audit database, with parameterized queries, autocomplete, and SQL generation.
  • Reports: pre-built and custom reports combining multiple queries with chart visualization and Excel export.
  • Alerts: severity-based monitoring (Info, Low, Medium, High, Critical) for automated detection of security events and policy violations.
  • Management: administrative functions for the audit platform itself, including user management, access tokens, and log upload configuration.

How the Sections Connect​

The Management Console sections form an interconnected system. A change in one section often has implications in others.

  1. Users must belong to Teams to be active. Teams define what resources users can consume.
  2. Teams are the quota boundary for VMs, drives, and devices. Every VM and drive belongs to a team.
  3. Projects restrict access to resources. A drive, VM, or secure inbox tagged with a project is accessible only to certified project members.
  4. Security Levels and Requirements add compliance-grade access control on top of project membership.
  5. VM Configurations reference Hardware Setups, which reference VM Images and Hardware Profiles, which reference Libvirt Hosts and Storage Pools.
  6. Escrow Groups provide the recovery mechanism for the zero-knowledge key management that secures all data.
  7. System Settings control global policies that affect every other section.
  8. Audit captures every action across all sections for compliance and incident investigation.