Converting encryption configuration from regular setup to simplified setup

You can convert an existing IBM Storage Scale encryption configuration that was previously configured using the regular setup (SKLM) to use the simplified setup.

The simplified setup method is much easier to use and more powerful than the regular setup method with Security Key Lifecycle Manager (SKLM). In the simplified setup method, the mmkeyserv command automatically performs many of the steps that must be done manually in the regular setup method. The simplified setup method can be used for all supported versions of IBM Storage Scale and SKLM. For more information about the simplified and regular setup, see Establishing an encryption-enabled environment.

Perform the following steps to convert from regular setup to simplified setup:

Note: Steps 1, 2, 3, 4, 5.a, and 5.b can be done while in production, and steps 5.c and 5.d must be done during a maintenance window.

Gather information about the current encryption configuration from the /var/mmfs/etc/RKM.conf file. The following details are required:
- Remote Key Manager (RKM) server name
- Backup servers
- RKM stanza ID
- Client name
- Tenant name
For more information about these terminologies, see Preparation for encryption.
A sample content from the RKM.conf file is as follows:
```
SKLM1 {
 type = ISKLM
 kmipServerUri = tls://KeyServer01:5696
 kmipServerUri1 = tls://KeyServer02:5696
 keyStore = /var/mmfs/etc/RKMcerts/c1Client.p12
 passphrase = passw0rd
 clientCertLabel = c1Client
 tenantName = sklmTenant
}
```
Where:
- SKLM1 is the RKM stanza ID.
- KeyServer01 is the primary RKM server.
- KeyServer02 is the backup RKM server.
- c1Client is the key client name.
- sklmTenant is the tenant name.
Add the primary and backup RKM servers to the encryption configuration by using the mmkeyserv command:
1. If SKLM is using a self-signed certificate, use the mmkeyserv server add command to add the SKLM server to the encryption configuration. Depending on how SKLM is configured, you might also need to specify a port number for connecting with SKLM:
```
# mmkeyserv server add KeyServer01 --backup KeyServer02
```
  Where:
  - KeyServer01 is the hostname or IP address of the primary SKLM key server.
  - KeyServer02 is the hostname or IP address of the backup SKLM key server.
2. If SKLM is using a certificate chain that is signed by a certificate authority, use the mmkeyserv server add command with the --kmip-cert option to add the SKLM server to the encryption configuration. Depending on how SKLM is configured, you might also need to specify a port number for connecting with SKLM:
```
mmkeyserv server add KeyServer01 --kmip-cert CertFilesPrefix --backup KeyServer02
```
  Where:
  - KeyServer01 is the hostname or IP address of the primary SKLM key server.
  - KeyServer02 is the hostname or IP address of the backup SKLM key server.
  - CertFilesPrefix is the path and the file name prefix of the files in the certificate chain.
3. Issue the mmkeyserv server show command to verify that the key server was added successfully. The following example shows that keyserver01 is added to the encryption configuration:
```
# mmkeyserv server show
keyserver01
  Type:                         ISKLM
  Hostname:                     keyserver01.gpfs.net
  User ID:                      SKLMAdmin
  REST port:                    9080
  Label:                        1_keyserver01
  NIST:                         on
  FIPS1402:                     off
  Backup Key Servers:           keyserver02
  Distribute:                   yes
  Retrieval Timeout:            120
  Retrieval Retry:              3
  Retrieval Interval:           10000
  REST Certificate Expiration:  2033-05-18 17:01:24 (-0400)
  KMIP Certificate Expiration:  2024-02-22 22:24:54 (-0400)
```
Add the tenant to the encryption configuration:
1. Issue the mmkeyserv command as shown in the following example to add a tenant:
```
# mmkeyserv tenant add sklmTenant --server keyserver01
```
  Where:
  - sklmTenant is the tenant or device group name. Retrieve the tenant name from the tenantName parameter in the /var/mmfs/etc/RKM.conf file.
  - keyserver01 is the hostname or IP address of the primary SKLM key server.
2. Issue the mmkeyserv tenant show command to verify that the tenant was added successfully. The following example shows that the tenant sklmTenant is added to keyserver01:
```
# mmkeyserv tenant show
sklmTenant
  Key Server:  keyserver01.gpfs.net
  Registered Client:  (none)
```
Create a key client. A key client can request master encryption keys from a tenant after it is registered to the tenant. The mmkeyserv client create command creates a client keystore file, which contains client credentials and the certificate of the key server. The command propagates the keystore to all the nodes in the cluster:
1. Issue the following command to create key client c1Client1 for key server keyserver01. Enter the SKLM administrator password and a passphrase for the new keystore when prompted:
```
# mmkeyserv client create c1Client1 --server keyserver01
Enter password for the key server keyserver01:
Create a pass phrase for keystore:
Confirm your pass phrase:
```
  Where:
  - c1Client1 is the key client name. Retrieve the client name from the clientCertLabel parameter in the /var/mmfs/etc/RKM.conf file or specify a new key client name.
  - keyserver01 is the host name or IP address of the primary SKLM key server.
2. Issue the mmkeyserv client show command to verify that the key client was created successfully. The following example shows that the key client c1Client1 is created for remote server keyserver01:
```
# mmkeyserv client show
c1Client1
  Label:                   c1Client1
  Key Server:              keyserver01.gpfs.net
  Tenants:                 (none)
  Certificate Expiration:  2024-02-22 00:01:03 (-0500)
```
Register the key client with the tenant to allow the key client to access encryption key in the tenant.
To register a client, you must provide a Remote Key Management (RKM) ID. The RKM ID becomes the identifier field of a new RKM stanza that describes the connection between the key client, the tenant, and the key server. In this step, the key client is registered with a temporary RKM ID that will be changed later to match the RKM ID that is used by the regular setup:
1. Issue the mmkeyserv client register command to register the key client with the tenant using a temporary RKM ID. Enter the requested information when prompted:
```
# mmkeyserv client register c1Client1 --tenant sklmTenant --rkm-id SKLM1temp
Enter password for the key server:

mmkeyserv: [I] Client currently does not have access to the key.  Continue the registration process ...
mmkeyserv: Successfully accepted client certificate
```
2. Issue the mmkeyserv rkm show command to verify that the key client is registered to the tenant:
```
# mmkeyserv rkm show
SKLM1temp {
type = ISKLM
kmipServerUri = tls://KeyServer01:5696
kmipServerUri1 = tls://KeyServer02:5696
keyStore = /var/mmfs/ssl/keyServ/serverKmip.1_keyserver01.c1Client1.1.p12
passphrase = fdlgd{(xlwXj.X<zEOaF
clientCertLabel = c1Client1
tenantName = sklmTenant
}
```
  Note: The RKM ID must be unique. Therefore, the regular setup RKM configuration file (/var/mmfs/etc/RKM.conf) and the simplified setup RKM configuration file that is managed by mmkeyserv command cannot have RKM stanzas with duplicate RKM IDs. In the next step, the RKM ID in the regular setup RKM configuration file must be renamed, commented, or removed before changing the temporary RKM ID that is used to register the key client in the previous step to match the RKM ID used by the regular setup and the file system encryption policy. If an operation that requires reading the RKM stanza from the RKM configuration file is run against the encrypted file system after commenting or removing the RKM ID, but before changing the temporary RKM ID, then the operation might fail due to the inability to find the remote key information. Operations that need to parse the RKM.conf file include mounting the file system and installing a policy.
  While the mmkeyserv rkm change command typically runs fast, it is recommended to run the RKM ID change operation during a maintenance window. Steps 5.c and 5.d must be run in quick succession.
3. On all nodes, rename the RKM ID that is being moved to the simplified setup in the regular setup RKM configuration file (/var/mmfs/etc/RKM.conf) or remove the corresponding RKM stanza.
4. Issue the mmkeyserv rkm change command to change the temporary RKM ID (created in step 5.a) to the RKM ID that was used in the regular setup. Enter the requested information when prompted:
```
# mmkeyserv rkm change SKLM1temp --rkm-id SKLM1
 mmkeyserv: Propagating the cluster configuration data to all
     affected nodes.  This is an asynchronous process. 
```
5. Issue the command mmkeyserv rkm show commands as shown in the following example to verify that the RKM ID is changed:
```
# mmkeyserv rkm show
SKLM1 {
type = ISKLM
kmipServerUri = tls://KeyServer01:5696
kmipServerUri1 = tls://KeyServer02:5696
keyStore = /var/mmfs/ssl/keyServ/serverKmip.1_keyserver01.c1Client1.1.p12
passphrase = fdlgd{(xlwXj.X<zEOaF
clientCertLabel = c1Client1
tenantName = sklmTenant
}
```
Upon successful RKM ID change, encryption is configured with the simplified setup. Repeat the previous steps for each RKM stanza in the regular setup to fully migrate the encryption configuration to the simplified setup.
The regular setup configuration files (/var/mmfs/etc/RKM.conf and the old client keystore) can be archived or removed from all nodes in the cluster.