[gpfsug-discuss] Encryption - checking key server health (SKLM)

Thu Feb 20 06:46:17 GMT 2020

Hi

Also in case that u configure 3 SKLM servers (1 Primary - 2 Slaves, in 
case the Primary is not responding you will see in the logs this messages:

Regards

Yaron Daniel
 94 Em Ha'Moshavot Rd

Storage Architect – IL Lab Services (Storage)
 Petach Tiqva, 49527
IBM Global Markets, Systems HW Sales
 Israel

Phone:
+972-3-916-5672

Fax:
+972-3-916-5672

Mobile:
+972-52-8395593

e-mail:
yard at il.ibm.com

Webex:            https://ibm.webex.com/meet/yard
IBM Israel

From:   "Felipe Knop" <knop at us.ibm.com>
To:     gpfsug-discuss at spectrumscale.org
Cc:     gpfsug-discuss at spectrumscale.org
Date:   20/02/2020 00:08
Subject:        [EXTERNAL] Re: [gpfsug-discuss] Encryption - checking key 
server health (SKLM)
Sent by:        gpfsug-discuss-bounces at spectrumscale.org

Bob,

Scale does not yet have a tool to perform a health-check on a key server, 
or an independent mechanism to retrieve keys.

One can use a command such as 'mmkeyserv key show' to retrieve the list of 
keys from a given SKLM server (and use that to determine whether the key 
server is responsive), but being able to retrieve a list of keys does not 
necessarily mean being able to retrieve the actual keys, as the latter 
goes through the KMIP port/protocol, and the former uses the REST 
port/API:

# mmkeyserv key show --server 192.168.105.146 --server-pwd 
/tmp/configKeyServ_pid11403914_keyServPass --tenant sklm3Tenant
KEY-ad4f3a9-01397ebf-601b-41fb-89bf-6c4ac333290b
KEY-ad4f3a9-019465da-edc8-49d4-b183-80ae89635cbc
KEY-ad4f3a9-0509893d-cf2a-40d3-8f79-67a444ff14d5
KEY-ad4f3a9-08d514af-ebb2-4d72-aa5c-8df46fe4c282
KEY-ad4f3a9-0d3487cb-a674-44ab-a7d0-1f68e86e2fc9
[...]

Having a tool that can retrieve keys independently from mmfsd would be 
useful capability to have. Could you submit an RFE to request such 
function?

Thanks,

  Felipe

----
Felipe Knop knop at us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314

----- Original message -----
From: "Oesterlin, Robert" <Robert.Oesterlin at nuance.com>
Sent by: gpfsug-discuss-bounces at spectrumscale.org
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Cc:
Subject: [EXTERNAL] [gpfsug-discuss] Encryption - checking key server 
health (SKLM)
Date: Wed, Feb 19, 2020 11:35 AM

I’m looking for a way to check the status/health of the encryption key 
servers from the client side - detecting if the key server is unavailable 
or can’t serve a key. I ran into a situation recently where the server was 
answering HTTP requests on the port but wasn’t returning they key. I can’t 
seem to find a way to check if the server will actually return a key.

Any ideas?

Bob Oesterlin
Sr Principal Storage Engineer, Nuance

_______________________________________________
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
https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=Bn1XE9uK2a9CZQ8qKnJE3Q&m=ARpfta6x0GFP8yy67RAuT4SMBrRHROGRUwCOSPVDEF8&s=aMBH47I25734lVmyzTZBiPd6a1ELRuurxoFCTf6Ij_Y&e= 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 11736 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1114 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3847 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0016.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 4266 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0017.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3747 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0018.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3793 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0019.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 4301 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0020.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3739 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0021.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3855 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0022.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 4338 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20200220/78b10061/attachment-0023.jpe>