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!


-- 
slurm-users mailing list -- slurm-users@lists.schedmd.com
To unsubscribe send an email to slurm-users-leave@lists.schedmd.com