[Beowulf] Data Destruction

Ellis Wilson ellis at ellisv3.com
Thu Sep 30 00:30:07 UTC 2021

On 9/29/21 5:51 PM, Jörg Saßmannshausen wrote:
> interesting concept. I did not know about the Lustre fsencrypt but then, I am
> less the in-detail expert in PFS.
> Just to make sure I get the concept of that correct: Basically Lustre is
> providing projects which itself are encrypted, similar to the encrypted
> containers I mentioned before. So in order to access the project folder, you
> would need some kind of encryption key. Without that, you only have
> meaningless data in front of you. Is that understanding correct?

The lustre kernel client module won't even permit open.  There may be a 
way around that with a hacked kernel module, but even then if you don't 
have the key, you don't have the data.

And it's not explicitly "project" based, in that the key really just 
applies to directories and all of their children (recursively).

Last, apologies, but I typo'd the name.  It's fscrypt, not fsencrypt. 
Was typing too quickly.  See section 30.5 of the Lustre manual for 
details.  At present no directories end up encrypted, so if you have 
*nix perms you'll be able to traverse everything, but you can't open 
anything (or again, even if you could, nonsense comes out).  Full 
directory (including metadata) encryption is slated for the next release 
of Lustre.

> The only problem I have with all these things is: at one point you will need
> to access the decrypted data. Then you need to make sure that this data is not
> leaving your system. So for that reason we are using a Data Safe Haven where
> data ingress and egress is done via a staging system.

I think this is orthogonal to the issue in question.  For sure having a 
form of air gap to control the flow of data in/out is very useful, but 
in multi-tenant PFS you still need to provide some protections against 
malicious tenants convolving other people's data with their own and 
purporting it's a legitimate export.  Client-side encryption (when 
managed appropriately) provides fairly decent protection against this 
form of the problem.



More information about the Beowulf mailing list