Skip to main content
tiCrypt

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.

New to administering tiCrypt? Setting up a new deployment is the ordered checklist; this page is the reference for what each console section does.

How tiCrypt Entities Connect​

Core tiCrypt entities connect through a small set of relationships. A user account belongs to one or more teams, is assigned a user profile, and can be a member of projects and groups. Teams define resource quotas that limit VM configurations and drives. Projects have a security level, which requires security requirements that users must be certified for. VM configurations and drives can be tagged with a project, and a user profile sets the role and permissions that apply to the account. Understanding these connections is essential for effective administration.

info

For how institutional personas (PI, Lab Manager, Graduate Researcher, etc.) map to these entities, see Institutional Role Mapping.

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 is where you manage accounts. It refers to teams and projects, which have their own sections below. In short: teams set how much computing and storage people can use (every VM and drive belongs to a team), and projects are labels that limit who can use a resource.

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 Vault Files and Directories, Groups, Projects, Virtual Machines, Teams, 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 list of every tiCrypt account. Each row shows a user's name, email, role, and state (Active, Inactive, or Active and escrow on next login). Select one or more users to apply these actions:

  • 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) adds users to teams, which set their resource quotas, and to projects, which control what they can access (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 user 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 one selected user. It appears only when exactly one user is selected.
  • 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

Vault Files and Directories

  • View their files and files shared with them (needed to download)
  • View the history of their files (sharing, project tags, deletion)
  • Get the keys of their files and files shared with them (needed to download)
  • Download the content of files they can access
  • Create files (needed to upload)
  • View their directories and their groups' directories
  • Create directories (also needs “Add items to directories”)
  • Add items to directories

Groups

  • View groups they are a member of
  • Get the keys of groups they are a member of (needed to open and share group files)
  • Create groups
  • Rename groups they own and give ownership to another member
  • Add users to groups they are a member of, if the group allows it
  • Change other members' group permissions in groups they are a member of
  • Remove users from groups they are a member of, if the group allows it
  • Delete groups they own

Projects

  • View projects they are a member of
  • View the members of projects they are a member of
  • View all security requirements
  • View all security levels
  • View their own certifications
  • Tag what they own with a project they are active in

Virtual Machines

  • View their drives
  • Create drives
  • Edit drives (name and backup setting)
  • Get drive keys (needed to share and attach drives)
  • Share drives
  • Unshare drives
  • Attach drives to VMs
  • Detach drives from VMs
  • View the VM hardware setups available to them
  • View their VM configurations and those shared with them
  • Create and edit VM configurations
  • Start VMs from VM configurations
  • Force-stop VMs started from VM configurations
  • View their own VM username
  • View other users' VM usernames (needed to share VMs)
  • Let their VMs transfer files straight to their Vault
  • View their VMs and VMs shared with them
  • Start VMs without a VM configuration
  • Connect to their VMs and VMs shared with them
  • Share VMs with other users
  • Shut down their VMs

Teams

  • View teams they are a member of
  • Edit teams they are a member of, as far as their team role allows

Miscellaneous

  • Transfer ownership of their 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

Vault Files and Directories

  • View their files and files shared with them (needed to download)
  • View the history of their files (sharing, project tags, deletion)
  • Get the keys of their files and files shared with them (needed to download)
  • Download the content of files they can access Blocked
  • Create files (needed to upload)
  • View their directories and their groups' directories
  • Create directories (also needs “Add items to directories”)
  • Add items to directories

Groups

  • View groups they are a member of
  • Get the keys of groups they are a member of (needed to open and share group files)
  • Create groups
  • Rename groups they own and give ownership to another member
  • Add users to groups they are a member of, if the group allows it
  • Change other members' group permissions in groups they are a member of
  • Remove users from groups they are a member of, if the group allows it
  • Delete groups they own

Projects

  • View projects they are a member of
  • View the members of projects they are a member of
  • View all security requirements
  • View all security levels
  • View their own certifications
  • Tag what they own with a project they are active in

Virtual Machines

  • View their drives
  • Create drives
  • Edit drives (name and backup setting)
  • Get drive keys (needed to share and attach drives)
  • Share drives
  • Unshare drives
  • Attach drives to VMs
  • Detach drives from VMs
  • View the VM hardware setups available to them
  • View their VM configurations and those shared with them
  • Create and edit VM configurations
  • Start VMs from VM configurations
  • Force-stop VMs started from VM configurations
  • View their own VM username
  • View other users' VM usernames (needed to share VMs)
  • Let their VMs transfer files straight to their Vault Blocked
  • View their VMs and VMs shared with them
  • Start VMs without a VM configuration
  • Connect to their VMs and VMs shared with them
  • Share VMs with other users
  • Shut down their VMs

Teams

  • View teams they are a member of
  • Edit teams they are a member of, as far as their team role allows

Miscellaneous

  • Transfer ownership of their 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

Vault Files and Directories

  • View their files and files shared with them (needed to download)
  • View the history of their files (sharing, project tags, deletion)
  • Get the keys of their files and files shared with them (needed to download)
  • Download the content of files they can access
  • Create files (needed to upload)
  • View their directories and their groups' directories
  • Create directories (also needs “Add items to directories”)
  • Add items to directories

Groups

  • View groups they are a member of
  • Get the keys of groups they are a member of (needed to open and share group files)
  • Create groups
  • Rename groups they own and give ownership to another member
  • Add users to groups they are a member of, if the group allows it
  • Change other members' group permissions in groups they are a member of
  • Remove users from groups they are a member of, if the group allows it
  • Delete groups they own

Projects

  • View projects they are a member of
  • View the members of projects they are a member of
  • View all security requirements
  • View all security levels
  • View their own certifications
  • Tag what they own with a project they are active in

Teams

  • View teams they are a member of
  • Edit teams they are a member of, as far as their team role allows

Miscellaneous

  • Transfer ownership of their files and drives

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

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

Vault Files and Directories

  • View their files and files shared with them (needed to download)
  • View the history of their files (sharing, project tags, deletion)
  • Get the keys of their files and files shared with them (needed to download)
  • Download the content of files they can access
  • Create files (needed to upload)
  • View their directories and their groups' directories
  • Create directories (also needs “Add items to directories”)
  • Add items to directories

Groups

  • View groups they are a member of
  • Get the keys of groups they are a member of (needed to open and share group files)
  • Create groups
  • Rename groups they own and give ownership to another member
  • Add users to groups they are a member of, if the group allows it
  • Change other members' group permissions in groups they are a member of
  • Remove users from groups they are a member of, if the group allows it
  • Delete groups they own

Projects

  • View projects they are a member of
  • View the members of projects they are a member of
  • View all security requirements
  • View all security levels
  • View their own certifications
  • Tag what they own with a project they are active in

Project Management (scoped to managed projects)

  • Remove project tags of projects they manage
  • Create subprojects in projects they manage
  • Edit projects they manage
  • Delete projects they manage
  • Add users to projects they manage
  • Edit memberships, such as expiration dates, in projects they manage
  • Remove users from projects they manage
  • Certify users for security requirements
  • Edit users' certifications, such as expiration dates
  • Remove users' certifications

Virtual Machines

  • View their drives
  • Create drives
  • Edit drives (name and backup setting)
  • Get drive keys (needed to share and attach drives)
  • Share drives
  • Unshare drives
  • Attach drives to VMs
  • Detach drives from VMs
  • View the VM hardware setups available to them
  • View their VM configurations and those shared with them
  • Create and edit VM configurations
  • Start VMs from VM configurations
  • Force-stop VMs started from VM configurations
  • View their own VM username
  • View other users' VM usernames (needed to share VMs)
  • Let their VMs transfer files straight to their Vault
  • View their VMs and VMs shared with them
  • Start VMs without a VM configuration
  • Connect to their VMs and VMs shared with them
  • Share VMs with other users
  • Shut down their VMs

Teams

  • View teams they are a member of
  • Edit teams they are a member of, as far as their team role allows

User Administration (scoped to managed objects)

  • View all users, not only those in their teams, groups and projects
  • Edit the details of users with a lower role (name, email, department, position)
  • Change the permissions of users with a lower role
  • View user profiles (permission templates)
  • Activate users with a lower role
  • Deactivate users with a lower role
  • Make users with a lower role escrow their key at their next sign-in

Miscellaneous

  • Transfer ownership of their 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
  • Delete any team
  • Add users to any team
  • Edit the members of any team
  • Remove users from any team

User Administration (full system scope)

  • View all users, not only those in their teams, groups and projects
  • Edit the details of users with a lower role (name, email, department, position)
  • Change the permissions of users with a lower role
  • Raise the role of users with a lower role, up to their own role
  • Lower the role of users with a lower role
  • View, create, edit, and delete user profiles
  • Activate and deactivate users with a lower role
  • Make users with a lower role escrow their key at their next sign-in
  • Delete users with a lower role

VM Administration

  • Delete any drive
  • View, create, edit, and delete storage pools
  • View and upload raw volumes (VM image files)
  • View, create, edit, and delete VM images
  • View, create, edit, and delete VM hardware setups
  • View, edit, and delete any VM configuration
  • View VM host machines and their hardware in any realm
  • Create, edit, and delete hardware profiles
  • Add, edit, and remove VM host machines in any realm
  • Change any user's VM username
  • View the logs of any VM

System Settings

  • View, change, and reset system settings

Escrow Management

  • Put their own private key in escrow
  • Check whether their own key is in escrow
  • View all keys in escrow
  • View escrow recovery keys
  • Delete keys from escrow, with their recovery parts
  • 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​

Shows everything tied to one user: teams, projects, drives, certifications, and admin notes. This is the fastest way to check a user's access without opening several sections.

Sub-Admin Managed Objects​

Assigns teams and projects to Sub-Admins so they can manage them. A Sub-Admin assigned a team or project can create subprojects, manage members, and edit details, 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​

Accounts that have been deleted but can still be restored. Deleting a user from the Users table moves the account here instead of removing 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 decide how much computing and storage their members can use. Every drive, VM configuration, and running VM belongs to a team and counts against that team's quotas.

Teams​

The list of every team. Each team has a name, a description, its members, and quotas that limit what they can use:

  • 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​

Shows which users belong to which teams. Use it to add or remove members in bulk, or to check membership across the organization. Removing a user from their last team triggers automatic deactivation.

Projects​

Projects are labels that limit who can use a resource. When a drive, VM, file, or secure inbox (a way to receive files from people outside tiCrypt) 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 list of every project and subproject. 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 add a second check on top of project membership, 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. Use this table to track compliance: who is qualified for what, when each qualification expires, and who granted it.

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

Resources by Project​

Shows everything tied to one project: its members, drives, security settings, and each member's certification status. It is the project version of Resources by User, and the quickest way to review a project.

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 hardware setup volumes.
  • Raw Volumes: raw VM image volumes.
  • 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 Volumes​

The ISO files found in the storage pools of every Libvirt realm, with their realm, pool, file name and size, and the ISO image registered on each one, if any. An ISO volume is the file on disk; an ISO image is tiCrypt's record on top of it, and only ISO images can be attached to VMs. See ISO Volumes.

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:

A job is submitted on the local side but starts running on the global side. Keeping those two apart is the key to reading everything below: submission enters at Local Slurm, execution begins at Global Slurm, and the job then runs back on the local side once a VM exists to run it.

  1. User submits a job with sbatch from inside their VM. Local Slurm receives it.
  2. Local Slurm intercepts the job and forwards a resource request onward to the tiCrypt backend. The request carries resource specifications, such as CPUs, memory, and time, and never the job script or the data.
  3. The backend creates a Global Slurm job tagged with the user's account and project.
  4. Global Slurm starts the job, scheduling and allocating it across the physical compute nodes. This is where the job begins running as far as the cluster is concerned.
  5. Worker VMs start inside encrypted enclaves on the allocated nodes and join the Local Slurm cluster as nodes.
  6. Local Slurm starts the work on those VMs. The job's actual code runs here.
  7. Job completes. The worker VMs are destroyed along with their encryption keys, and the Global Slurm job releases its resources.

The split matters because of what each layer can see. Local Slurm runs inside the encrypted enclave and has the job scripts and data; Global Slurm allocates cluster resources and never sees either. Job failures propagate up to Global Slurm, so a failed job surfaces at the platform layer even though its contents do not.

The Management Console reads Global Slurm. The jobs, nodes, and accounts in this section are the platform-level scheduling and accounting records. Local Slurm instances inside project enclaves are not visible here, which is what lets an administrator account for cluster usage without being able to see what any job ran.

Partition Assignments​

tiCrypt's own entry for each Global Slurm partition that its VMs may use: a description, a priority, a default flag, and an access list of teams, projects and VM configurations. A partition without an entry here cannot be used by tiCrypt jobs. Creating or deleting an entry does not create or delete the partition in Slurm. See Partition Assignments.

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 here. The table is read-only: it has no action to drain or resume a node.

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 running 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 monitor fair share and historical usage here; the table is read-only.

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 key parts, one per escrow group.
  2. Key part distribution: Each key part is encrypted with every group member's public key, so any member of a group can contribute that group's key part.
  3. Recovery process: One representative from each escrow group contributes their key part to reconstruct the recovery key.
  4. Key recovery: The recovery key decrypts the user's private key, restoring access.

The Escrow section is hidden when the backend reports that key escrow is not available. It has two tables, Escrow Users and Escrow Certificates. Escrow groups have no table of their own: they are created with the site key and are visible in the Escrow application.

Escrow Groups​

Escrow groups are sets of escrow officers who collectively manage private key recovery. Three groups are required by default (key-escrow.min-keys), and the minimum can be lowered to two. During key escrow, the recovery key is split into key parts, one per group. Each key part is encrypted with every group member's public key, so any member of a group can contribute that group's key part. Recovery requires one representative from each group to contribute their key part; 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 must be signed directly by the site key (the root signing key for the tiCrypt deployment), establishing a chain of trust; the backend rejects an escrow key signed by anything else. 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.

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:

  • Login: login logo, login ID validation, login message.
  • Servers: update URL, external SFTP inbox endpoints and survey deployment servers, XSS headers.
  • Timeouts: private key timeout, session timeout (screen lock).
  • User: copy settings, helpdesk configuration, password strength requirements, inbox URL and maximum inbox duration, admin session downgrade.
  • Caching: private key caching and MFA token caching.
  • Files: default file share duration.
  • Notices: CUI disclosure and terms of service.
  • Drives: track drive backup.
  • VMs: Windows VM domain for RDP connection files.

A saved change reaches each user at their next login or app load, and is tracked in System Settings History for audit purposes. See System Settings.

System Settings History​

A complete audit trail of settings changes, visible to Super Admins only. Each entry shows the setting's deployment file key, 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.

Miscellaneous​

The Miscellaneous section provides visibility into runtime health and programmatic access to tiCrypt. System Services, Audit Logs and API Keys are visible to Super Admins only.

System Services​

The backend services and whether each one is running: ticrypt-auth, ticrypt-file-manager, ticrypt-proxy, ticrypt-stats, ticrypt-vm, ticrypt-logger, ticrypt-notifications, ticrypt-rest, and the maintenance tasks. The table shows only Running (yes or no), not versions or uptime. Super Admins can view each service's logs and configuration and restart it from this table. See System Services.

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 most recent audit log lines: the lines the logger service has not yet rotated into its archive. Every significant action is logged: user logins, file operations, VM lifecycle events, administrative changes, and security events. Each row shows the log type, timestamp and up to 20 arguments; you can filter the type and argument columns by text and export rows to CSV or JSON. There is no time-range or user filter. See Audit Logs.

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

API Keys​

Authentication tokens for the REST API, which gives programmatic access for automation, external integration and custom tooling. Each key has:

  • Description: an optional note on what the key is used for.
  • Owner: the Super Admin who created it.
  • Created, Expires and Last Used: when it was created, when it becomes invalid, and when it was last used.
  • Access level: Full control or Read-only.
  • Token type: the routes the key can reach (Drive, Project, Team, User, VM, or Multi with a set of Capabilities).
  • ID: the key's identifier. The key value itself is shown only once, at creation.

Create keys for specific integrations and Delete them when no longer needed or when rotating keys after a security incident. See API Keys.

External SFTP Servers​

External SFTP servers are the destinations users can push Vault files to with an SFTP bidirectional connection from tiCrypt Connect. Each entry holds a name, host, port, optional expiration date and an allowlist of users and teams. It holds no credentials: users sign in with their own account on the server. Use this when data must be delivered from tiCrypt to an approved external system.

Registering a server here does not by itself grant anyone the ability to use it. Outbound SFTP is allowlisted: the backend checks the allowlist every time a user connects, and an entry with an empty allowlist cannot be used by anyone. Files arrive on the server decrypted, so treat each entry as an export authorization rather than a connection setting. See External SFTP Servers.

Audit​

The Audit section connects to tiCrypt Audit, the separately deployed audit platform. While the Miscellaneous section 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.