Hi all, I’m new to this list, so hello to everyone. :-) Goal We want to use native lustre client-side encryption (fscrypt) to protect data on a remote HPC cluster, and run Slurm jobs that can work with that data. Current (not so good) concept: The key would temporarily live on the remote network: Key on NFS: /home/username/enc.key Encrypted data on Lustre: /lustre/project The workflow would be: 1. A Slurm prolog loads the key into the kernel keyring on the compute nodes. 2. The same script deletes enc.key from the remote network. 3. The job runs with access to the decrypted data. 4. A Slurm epilog script removes the key from the node’s keyring. The obvious problem: Until the job is scheduled, the key and the encrypted data are on the same remote network, which defeats much of the purpose. Accepted risks We are aware of other attack vectors: remote admins can read enc.key on NFS, and the key can be read from RAM while the job runs. Strict ACLs are essential, and we run the computes --exclusive We accept these risks for now. Question Does anyone know a way to avoid storing enc.key on the remote network before the job starts? Can the key be 'injected' at job start from our side (pushed or pulled) Does slurm have any native mechanism to deal with this? Is there a better pattern for this? Have you implemented something like this on your site, and how? Note: we have an existing site-to-site ipsec tunnel that we could use. Any tips or experiences are welcome. Thanks!