[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.
Best,
ellis
More information about the Beowulf
mailing list