From Shared Computing Cluster to tiCrypt
- tiCrypt replaces shared login nodes with encrypted VMs and the Vault: same Slurm commands, different plumbing
- Your home directory equivalent is an encrypted VM drive, not the Vault (the Vault is staging/transfer)
- All data moves through the Vault under audit: no direct outbound paths from VMs
- Jump to the concept mapping table for the full row-by-row translation
If you have used a traditional Shared Computing Cluster (SCC) or campus High-Performance Computing (HPC) environment, most of tiCrypt will feel familiar: you still log in, you still request compute, you still run sbatch scripts and check squeue. What changes is where the security boundary sits.
On an SCC, security is built around the perimeter. Administrators harden the login node, control who gets a shell on a compute node, and rely on filesystem permissions to keep one lab's data separate from another's. Once you are inside that perimeter, a great deal of trust is implicit: root on a node can read anything on it, and a misconfigured mount can expose data far beyond its intended audience.
tiCrypt inverts this model. Instead of a perimeter around shared infrastructure, every unit of storage, every drive, every Vault file, is individually encrypted, and the keys are held by the data owner rather than the platform operator. Compute happens inside ephemeral, encrypted virtual machines rather than on long-lived shared nodes. System administrators keep the lights on, but they cannot read your data even with full root access to the underlying infrastructure. This page is not a step-by-step tutorial. It is a concept map: for each piece of your SCC mental model, it shows you the tiCrypt equivalent and links out to the procedural documentation you will need to actually do the work.
This page assumes you are comfortable with Slurm, SSH, and traditional HPC filesystem layouts, and are now ramping up on tiCrypt. If you manage institutional roles (PI, lab manager, department admin) rather than infrastructure, see Institutional Role Mapping instead.
Concept Mapping Table
This table is the core reference for this page. Skim it first, then read the sections below for the concepts that need more than one row to explain.
| SCC Concept | tiCrypt Equivalent | Key Difference | Details |
|---|---|---|---|
| SSH login node | tiCrypt Connect application + browser | No shared login host; Connect brokers a TLS tunnel from your machine directly to your session | Connect Application |
Home directory (/home/user/) | Encrypted drive attached to the VM (the "home drive") | Not the Vault. The home drive is compute-attached storage, encrypted, and only exists while mounted to a VM | Connect and Access VMs |
Shared project directory (/project/mylab/) | Shared encrypted drives (read-only or read-write) | Sharing is granted per-drive, per-user, not via Unix group permissions | Share Drives |
| Staging/transfer area | The Vault | The Vault is not a home directory equivalent. It is the encrypted bridge between the outside world and your VMs | Vault Upload |
Interactive session (srun --pty bash) | RDP or terminal session inside a VM | You connect to a full VM rather than a shell on a shared node | Connect and Access VMs |
Batch job (sbatch myscript.sh) | sbatch inside a tiCrypt VM | Same command, same syntax; it runs against tiCrypt's Local Slurm rather than a cluster-wide scheduler | Slurm Jobs |
| Compute node | Ephemeral encrypted worker VM | Created for the job, destroyed on completion, encryption keys discarded with it | VM Images |
module load python/3.10 | Pre-installed in the VM image | No module system; if you need new software, request it from your admin so it can be baked into an image | VM Images |
Shared filesystem (/scratch/) | Encrypted drives shared between users | Scoped sharing per drive rather than a cluster-wide scratch mount | Share Drives |
scp / rsync to cluster | Vault upload, Inbox, or Direct SFTP to VM | Multiple ingress paths depending on file size and sender | Inboxes |
scp / rsync from cluster | Controlled export: VM to Vault, then download | Egress is logged and may require approval; there is no direct outbound path from a VM | VM File Operations |
| OS user accounts on nodes | No OS accounts; digital signature authentication | Identity is cryptographic, not a Unix UID/GID pair | Register Account |
sudo / root access | VM Owner role (scoped to that VM only) | Ownership is per-VM and grants no access to other VMs, drives, or the Vault | VM Roles and Permissions |
Resource quotas (myquota) | Team resource quotas (CPU, memory, storage) | Quotas apply to the team, not to a per-user filesystem allocation | Teams |
| Slurm partitions / QOS | Slurm partitions within Local Slurm | Partitions are configured inside the enclave rather than cluster-wide | Slurm Configuration |
Job accounting (sacct) | sacct inside the VM, plus the tiCrypt audit trail | You get standard Slurm accounting, and administrators get a separate platform-level audit log | Slurm Jobs |
Notice how many rows in this table replace "a shared thing with permissions" with "an encrypted thing with an owner." That substitution is the entire security model of tiCrypt in one sentence.
The Dual Slurm Architecture
tiCrypt runs two Slurm instances that serve different purposes. Global Slurm operates at the platform level. It schedules VM provisioning across the physical infrastructure, but it never has access to job content, job scripts, or the data your jobs touch. Its job is to decide where and when a worker VM should be created, not what runs inside it.
Local Slurm runs inside your encrypted enclave, alongside your VM. This is the Slurm instance you actually interact with. When you run sbatch, srun, or squeue, you are talking to Local Slurm, and from your perspective the commands, flags, and output are identical to what you would see on a traditional SCC. Submitting a job with sbatch hands the request to Local Slurm. Local Slurm passes it to the tiCrypt backend, which in turn hands provisioning off to Global Slurm. Global Slurm provisions the worker VMs, the job executes on them, and once the workers finish, results are returned to you and the workers are destroyed.
You type sbatch myjob.sh just like on your SCC. The rest happens transparently: Local Slurm, the tiCrypt backend, and Global Slurm coordinate worker provisioning without you needing to think about it. See Slurm Jobs for the full workflow, and read Secure HPC with Slurm for a deeper look at why this split exists.
Data Lifecycle: In, Working, Out
On an SCC, your data typically already sits on a shared filesystem the moment your account is provisioned. In tiCrypt, moving data is a deliberate, logged, three-stage process: it comes in through the Vault, you work on it inside a VM's encrypted drive, and results go back out through the Vault under controlled export. The sections below walk through each stage.
Getting Data In
Choose your ingress method based on file size, where the data is coming from, and who is sending it.
| Situation | Method | Link |
|---|---|---|
| Small to moderate files, you have an account | Vault upload | Vault Upload |
| External collaborator sending data | Inbox (URL or SFTP) | Inboxes |
| Large dataset (5+ TB) | External Drive Builder | Data Ingress |
| Data directly into a running VM | Direct SFTP to VM | VM File Operations |
| Bridging institutional NFS storage | NFS mount (admin-configured) | NFS Mounts |
Any SFTP path from outside the enclave into tiCrypt accepts uploads only. There is no path by which an external SFTP client can pull data back out. Egress always goes through the Vault, described below.
Working With Data
The Vault is staging space, not a working directory. Once data lands in the Vault, you do not analyze it there directly. You transfer it into a VM's attached encrypted drive (the home drive, or a shared drive) and work with it from inside the VM, the same way you would cp data from a transfer node onto /scratch/ before running a job on an SCC.
The typical flow is: upload or receive data into the Vault, start or connect to your VM, then use the VM's file transfer panel to pull the files from the Vault onto an attached drive. From that point, the data behaves like a local, encrypted disk to every process running inside the VM. See VM File Operations for the transfer mechanics.
Getting Results Out
Egress mirrors ingress, but in reverse and under tighter control. Results move from the VM to the Vault using the same file transfer panel, and from there you download them from the Vault to your local machine. Every download is logged, and depending on your project's configuration, downloads may require approval from a project administrator before they complete.
This is deliberately asymmetric. Nothing you can do inside a VM produces an uncontrolled outbound path: no direct internet access from the VM's virtual network (VLAN), no outbound SFTP, no shortcuts around the Vault. Read Data Ingress and Egress for the reasoning behind this design.
If you find yourself looking for a faster way to get a result off a VM than Vault-then-download, stop and ask your project administrator. The extra step exists so that every export is attributable and, where required, reviewable. Working around it defeats the purpose of the enclave.
What Your Admin Does Differently
If you also administer infrastructure, or you are the person your researchers will ask, here is what changes on your side:
- No user accounts to provision on compute nodes. Identity is handled by digital signature authentication at the platform level, not per-node Unix accounts.
- No module system to maintain. Software is baked into VM images ahead of time; see VM Images for how images are built and updated.
- No shared filesystem to tune or back up. The Vault handles encrypted staging storage, and drives handle compute-attached storage, each with its own lifecycle.
- Resource quotas are set at the Team level, not as per-user filesystem quotas. See Teams and Projects.
- VM images take over the role that OS provisioning and configuration management played across a shared node fleet.
Quick-Start Path
If you are a researcher moving your first workflow to tiCrypt, this is the order of operations for your first week:
- Install tiCrypt Connect. Connect Application
- Register and log in. Register Account and Login
- Upload your data to the Vault. Vault Upload
- Create a VM configuration. Create and Configure VMs
- Start the VM and connect to it. Connect and Access VMs
- Transfer data from the Vault to a VM drive. VM File Operations
- Work interactively, or submit Slurm batch jobs. Slurm Jobs
- Transfer results back to the Vault. VM File Operations
- Download or share your results. Share Files
You will likely revisit this mapping table more than once as you translate old habits into tiCrypt equivalents. For deeper dives on any single row, follow the linked page rather than guessing at the SCC analogy.