[gpfsug-discuss] Spectrum Scale Encryption

[Wahl, Edward]

This is rather dependant on SS version. 

So what used to happen before 4.2.2.* is that a client would be unable to mount the filesystem in question and would give an error in the mmfs.log.latest for an SGPanic,   In 4.2.2.* It appears it will now mount the file system and then give errors on file access instead.  (just tested this on 4.2.2.3) I'll have to read through the changelogs looking for this one. 

Depending on your policy for encryption then, this might be exactly what you want,  but I REALLY REALLY dislike this behaviour.

To me this means clients can now mount an encrypted FS now and then fail during operation.  If I get a client node that comes up improperly, user work will start, and it will fail with "Operation not permitted" errors on file access.  I imagine my batch system could run through a massive amount of jobs on a bad client without anyone noticing immeadiately.  Yet another thing we now have to monitor now I guess.  *shrug*

A couple other gotcha's we've seen with Encryption:

Encrypted file systems do not store data in large MD blocks.  Makes sense. This means large MD blocks aren't as useful as they are in unencrypted FS, if you are using this. 

Having at least one backup SKLM server is a good idea.  "kmipServerUri[N+1]" in the conf.

While the documentation claims the FS can continue operation once it caches the MEK if an SKLM server goes away, in operation this does NOT work as you may expect.  Your users still need access to the FEKs for the files your clients work on.  Logs will fill with Key <key> could not be fetched. errors. 

Ed Wahl
OSC

________________________________________
From: gpfsug-discuss-bounces at spectrumscale.org [gpfsug-discuss-bounces at spectrumscale.org] on behalf of Simon Thompson (Research Computing - IT Services) [S.J.Thompson at bham.ac.uk]
Sent: Thursday, April 06, 2017 4:20 AM
To: gpfsug-discuss at spectrumscale.org
Subject: [gpfsug-discuss] Spectrum Scale Encryption

We are currently looking at adding encryption to our deployment for some
of our data sets and for some of our nodes. Apologies in advance if some
of this is a bit vague, we're not yet at the point where we can test this
stuff out, so maybe some of it will become clear when we try it out.


For a node that we don't want to have access to any encrypted data, what
do we need to set up?

According to the docs:
https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.2/com.ibm.spectrum.s
cale.v4r22.doc/bl1adv_encryption_prep.htm


"After the file system is configured with encryption policy rules, the
file system is considered encrypted. From that point on, each node that
has access to that file system must have an RKM.conf file present.
Otherwise, the file system might not be mounted or might become unmounted."

So on a node which I don't want to have access to any encrypted files, do
I just need to have an empty RKM.conf file?

(If this is the case, would be good to have this added to the docs)


Secondly ... (and maybe I'm misunderstanding the docs here)

For the Policy
https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectru
m.scale.v4r22.doc/bl1adv_encryptionpolicyrules.htm


KEYS ('Keyname'[, 'Keyname', ... ])


KeyId:RkmId


RkmId should match the stanza name in RKM.conf?

If so, it would be useful if the docs used the same names in the examples
(RKMKMIP3 vs rkmname3)

And KeyId should match a "Key UUID" in SKLM?


Third. My understanding from talking to various IBM people is that we need
ISKLM entitlements for NSD Servers, Protocol nodes and AFM gateways
(probably), do we have to do any kind of node registration in ISKLM? Or is
this purely based on the certificates being distributed to clients and
keys are mapped in ISKLM to the client cert to determine if the node is
able to request the key?

Thanks

Simon

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss