<font size=2 face="sans-serif">All,</font><br><br><font size=2 face="sans-serif">A few comments on the topics raised
below.</font><br><br><font size=2 face="sans-serif">1) All nodes that mount an encrypted
file system, and also the nodes with management roles on the file system
will need access to the keys have the proper setup (RKM.conf, etc).</font><br><br><font size=2 face="sans-serif">Edward is correct that there was some
change in behavior, introduced in 4.2.1 . Before the change, a mount would
fail unless RKM.conf is present on the node. In addition, once a policy
with encryption rules was applied, nodes without the proper encryption
setup would unmount the file system. With the change, the error gets delayed
to when encrypted files are accessed.</font><br><br><font size=2 face="sans-serif">The change in behavior was introduced
based on feedback that unmounting the file system in that case was too
drastic in that scenario.</font><br><br><tt><font size=2>>> So on a node which I don't want to have access
to any encrypted files, do<br>I just need to have an empty RKM.conf file?</font></tt><br><br><font size=2 face="sans-serif">All nodes which mount an encrypted file
system should have proper setup for encryption, even for a node from where
only unencrypted files are being accessed.</font><br><br><br><font size=2 face="sans-serif">2)</font><br><tt><font size=2>>> 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. </font></tt><br><br><font size=2 face="sans-serif">Correct. Data is not stored in the inode
for encrypted files. On the other hand, since encryption metadata is stored
as an extended attribute in the inode, 4K inodes are still recommended
-- especially in cases where a more complicated encryption policy is used.</font><br><br><font size=2 face="sans-serif">3)</font><br><tt><font size=2>>> Having at least one backup SKLM server is
a good idea.  "kmipServerUri[N+1]" in the conf.<br><br>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. </font></tt><br><br><font size=2 face="sans-serif">Using a backup key server is strongly
recommended.</font><br><br><font size=2 face="sans-serif">While it's true that the files may still
be accessed for a while if the key server becomes unreachable, this was
not something to be counted on. First because keys (MEK) may expire at
any time, requiring the key to be retrieved from the key server again.
Second because a file may require a key may be needed that has not been
cached before.</font><br><br><br><font size=2 face="sans-serif">4)</font><br><tt><font size=2>>> Secondly ... (and maybe I'm misunderstanding
the docs here)<br><br>For the Policy<br></font></tt><a href=https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectru><tt><font size=2>https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectru</font></tt></a><tt><font size=2><br>m.scale.v4r22.doc/bl1adv_encryptionpolicyrules.htm<br><br>KEYS ('Keyname'[, 'Keyname', ... ])<br><br>KeyId:RkmId<br><br>RkmId should match the stanza name in RKM.conf?</font></tt><br><br><font size=2 face="sans-serif">Correct.</font><br><br><tt><font size=2>>> If so, it would be useful if the docs used
the same names in the examples<br>(RKMKMIP3 vs rkmname3)<br><br>And KeyId should match a "Key UUID" in SKLM?</font></tt><br><br><font size=2 face="sans-serif">Correct.</font><br><br><font size=2 face="sans-serif">We'll review the documentation to ensure
that the meaning of the RkmId in the examples is clear.</font><br><br><br><font size=2 face="sans-serif">5)</font><br><br><tt><font size=2>>> Third. My understanding from talking to various
IBM people is that we need<br>ISKLM entitlements for NSD Servers, Protocol nodes and AFM gateways<br>(probably), do we have to do any kind of node registration in ISKLM? Or
is<br>this purely based on the certificates being distributed to clients and<br>keys are mapped in ISKLM to the client cert to determine if the node is<br>able to request the key?</font></tt><br><br><font size=2 face="sans-serif">I'll work on getting clarifications
from the ISKLM folks on this aspect.</font><br><br><font size=2 face="sans-serif">  Felipe</font><br><br><font size=2 face="sans-serif">----<br>Felipe Knop                  
                  knop@us.ibm.com<br>GPFS Development and Security<br>IBM Systems<br>IBM Building 008<br>2455 South Rd, Poughkeepsie, NY 12601<br>(845) 433-9314  T/L 293-9314<br><br></font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">"Wahl, Edward"
<ewahl@osc.edu></font><br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">gpfsug main discussion
list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">04/06/2017 10:55 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Spectrum Scale Encryption</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><tt><font size=2>This is rather dependant on SS version. <br><br>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. <br><br>Depending on your policy for encryption then, this might be exactly what
you want,  but I REALLY REALLY dislike this behaviour.<br><br>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*<br><br>A couple other gotcha's we've seen with Encryption:<br><br>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. <br><br>Having at least one backup SKLM server is a good idea.  "kmipServerUri[N+1]"
in the conf.<br><br>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. <br><br>Ed Wahl<br>OSC<br><br>________________________________________<br>From: gpfsug-discuss-bounces@spectrumscale.org [gpfsug-discuss-bounces@spectrumscale.org]
on behalf of Simon Thompson (Research Computing - IT Services) [S.J.Thompson@bham.ac.uk]<br>Sent: Thursday, April 06, 2017 4:20 AM<br>To: gpfsug-discuss@spectrumscale.org<br>Subject: [gpfsug-discuss] Spectrum Scale Encryption<br><br>We are currently looking at adding encryption to our deployment for some<br>of our data sets and for some of our nodes. Apologies in advance if some<br>of this is a bit vague, we're not yet at the point where we can test this<br>stuff out, so maybe some of it will become clear when we try it out.<br><br><br>For a node that we don't want to have access to any encrypted data, what<br>do we need to set up?<br><br>According to the docs:<br></font></tt><a href=https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.2/com.ibm.spectrum.s><tt><font size=2>https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.2/com.ibm.spectrum.s</font></tt></a><tt><font size=2><br>cale.v4r22.doc/bl1adv_encryption_prep.htm<br><br><br>"After the file system is configured with encryption policy rules,
the<br>file system is considered encrypted. From that point on, each node that<br>has access to that file system must have an RKM.conf file present.<br>Otherwise, the file system might not be mounted or might become unmounted."<br><br>So on a node which I don't want to have access to any encrypted files,
do<br>I just need to have an empty RKM.conf file?<br><br>(If this is the case, would be good to have this added to the docs)<br><br><br>Secondly ... (and maybe I'm misunderstanding the docs here)<br><br>For the Policy<br></font></tt><a href=https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectru><tt><font size=2>https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectru</font></tt></a><tt><font size=2><br>m.scale.v4r22.doc/bl1adv_encryptionpolicyrules.htm<br><br><br>KEYS ('Keyname'[, 'Keyname', ... ])<br><br><br>KeyId:RkmId<br><br><br>RkmId should match the stanza name in RKM.conf?<br><br>If so, it would be useful if the docs used the same names in the examples<br>(RKMKMIP3 vs rkmname3)<br><br>And KeyId should match a "Key UUID" in SKLM?<br><br><br>Third. My understanding from talking to various IBM people is that we need<br>ISKLM entitlements for NSD Servers, Protocol nodes and AFM gateways<br>(probably), do we have to do any kind of node registration in ISKLM? Or
is<br>this purely based on the certificates being distributed to clients and<br>keys are mapped in ISKLM to the client cert to determine if the node is<br>able to request the key?<br><br>Thanks<br><br>Simon<br><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br><br></font></tt><br><BR>