[gpfsug-discuss] Spectrum Scale Encryption

Thu Apr 6 16:11:38 BST 2017

Hi Ed,

Thanks.

We already have several SKLM servers (tape backups).

For me, we plan to encrypt specific parts of the FS (probably by
file-set), so as long as all that is needed is an empty RKM.conf file,
sounds like it will work. I suppose I could have an MEK that is granted to
all clients, but then never actually use it for encryption if RKM.conf
needs at least one key (hack hack hack).

(We are at 4.2.2-2 (mostly) or higher (a few nodes)).

I *thought* the FEK was wrapped in the metadata with the MEK (possibly
multiple times with different MEKs), so what the docs say about operation
continuing with no SKLM server sounds sensible, but of course that might
not be what actually happens I guess...

Simon

On 06/04/2017, 15:54, "gpfsug-discuss-bounces at spectrumscale.org on behalf
of Wahl, Edward" <gpfsug-discuss-bounces at spectrumscale.org on behalf of
ewahl at osc.edu> wrote:

>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.spectr
>u
>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
>_______________________________________________
>gpfsug-discuss mailing list
>gpfsug-discuss at spectrumscale.org
>http://gpfsug.org/mailman/listinfo/gpfsug-discuss