Preparation for encryption

Terms defined

The following terms are important:

device group

See tenant.

file encryption key

A file encryption key (FEK) is a key for encrypting file data. See Encryption keys.

host

See tenant.

key client

A key client is an entity in the cluster that represents the nodes that access encrypted files. The key client receives master encryption keys (MEKs) from the tenant of the Remote Key Management (RKM) server.

key server or Remote Key Management (RKM) server

A key server is a server that authenticates key clients and provides them with MEKs. Examples of key server software products are IBM® Security Key Lifecycle Manager (SKLM) and Thales Vormetric Data Security Manager (DSM).

master encryption key

A master encryption key (MEK) is a key for encrypting FEKs.

tenant

A tenant is an entity on a key server that contains MEKs and certificates.

• In SKLM, a tenant is called a device group.
• In DSM, a tenant is called a host.
• The mmkeyserv command uses the generic keyword tenant.

Simplified setup and regular setup

The simplified setup is a method for configuring the encryption environment in which you use the mmkeyserv command to configure and manage cluster-wide encryption configuration. This method is much preferred if your key server is SKLM or HashiCorp Vault Enterprise because the mmkeyserv command automatically performs many of the steps that must be done manually in the regular setup. You can use this setup method only with SKLM or HashiCorp Vault Enterprise KMIP Secrets Engine.

The regular setup is a method for configuring the encryption environment in which you generate client credentials and then manually edit and distribute encryption configuration files to the nodes in the cluster. You can use this setup method with either SKLM or DSM.

Required software: IBM Storage Scale

Required software: Remote Key Management (RKM) server

The next table shows the RKM server software that IBM Storage Scale supports.

Preparing your cluster for encryption

Follow these steps:

1. Verify the following items in your IBM Storage Scale cluster:
   • The cluster is running the correct version of IBM Storage Scale and the correct version of a supported RKM server. These versions are listed in Table 1 and Table 2.
   • The file system daemon is running.
2. Ensure that the following packages are installed:
   • gpfs.gskit
   • gpfs.crypto
3. Set up an IBM Storage Scale file system on the cluster. The version of the file system must be IBM Storage Scale Release 4.1 or later. Configure the following features on the file system:
   1. Create the file system with the inode size of 4 KiB. Choosing this minimum size is a good idea because 4 KiB accommodates the GPFS encryption extended attribute that is assigned to each encrypted file at file creation time. This extended attribute contains one or more wrapped FEKs so it can potentially grow large. For more information, see Encryption policies.
   2. Enable fast extended attributes. This setting is the default for a newly created file system if you are running 4.1 or later. To verify that fast extended attributes are enabled, issue the following command, where <Device> is the name of the file system:

      mmlsfs <Device> --fastea

      However, if your file system was migrated from an earlier level, issue the following command to add support for fast extended attributes:

      mmmigrate <Device> --fastea

      For more information, see Completing the upgrade to a new level of IBM Storage Scale.

Preparing the remote key management (RKM) server

RKM back ends

An RKM back end defines a connection between a local key client, a remote key tenant, and an RKM server. Each RKM back end is described in an RKM stanza in an RKM.conf file on each node that is configured for encryption.

By controlling the contents of the RKM.conf file, the cluster administrator can control which client nodes have access to MEKs. For example, the same RKM server can be given two different names in /var/mmfs/etc/RKM.conf stanzas. Then, the administrator can partition a set of MEKs hosted on a single RKM server into separate subsets of MEKs. These subsets of MEKs might belong to subsets of the nodes of the cluster.

Because the MEKs are cached in memory, some short-term outages while a key client is attempting to access a key server might not cause issues. However, failure to retrieve the keys might result in errors while the file system is creating, opening, reading, or writing files. Although the keys are cached, they are periodically retrieved from the key server to ensure their validity.

To ensure that MEKs are always available, it is a good practice to set up multiple key servers in a high-availability configuration. See the subtopic Adding backup RKM servers in a high-availability configuration.

The RKM.conf file and the RKM stanza

The length of the RKM.conf file cannot exceed 1 MiB. No limit is set on the number of RKM stanzas, if the length limit is not exceeded.

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.

RKM ID {
   type = ISKLM
   kmipServerUri = tls://host:port
   keyStore = PathToKeyStoreFile
   passphrase = Password
   clientCertLabel = LabelName
   tenantName = NameOfTenant
   [connectionTimeout = ConnectionTimeout]
   [connectionAttempts = ConnectionAttempts]
   [retrySleep = RetrySleepUsec]
}

The client keystore directory and its files

The files in the client keystore directory include the client keystore file, the public and private key files for the client, and possibly other files that are described in later topics.

Adding backup RKM servers in a high-availability configuration

<server_name>=<IP_address:port_number>

rkmname3 {
   type = ISKLM
   kmipServerUri = tls://host:port
   kmipServerUri2 = tls://host:port     # TLS connection to backup RKM server 1
   kmipServerUri3 = tls://host:port     # TLS connection to backup RKM server 2
   kmipServerUri4 = tls://host:port     # TLS connection to backup RKM server 3
   kmipServerUri5 = tls://host:port     # TLS connection to backup RKM server 4
   kmipServerUri6 = tls://host:port     # TLS connection to backup RKM server 5
   keyStore = PathToKeyStoreFile
   passphrase = Password
   clientCertLabel = LabelName
   tenantName = NameOfTenant
   [connectionTimeout = ConnectionTimeout]
   [connectionAttempts = ConnectionAttempts]
   [retrySleep = RetrySleepUsec]
}

If at least one backup RKM server is configured, then whenever key retrieval from the primary RKM server fails, IBM Storage Scale queries each backup RKM server in the list, in order, until it finds the MEK. The addition of the URIs for the backup RKM servers is the only change that is required within IBM Storage Scale. All other configuration parameters (certificates, keys, node, and tenant information) do not need to change, because they are also part of the set of information that is replicated. The administrator is responsible for creating and maintaining any backups.

Additionally, setting up backup RKM servers can help gain some performance advantage by distributing MEK retrieval requests across the backup RKM servers in a round-robin fashion. To achieve this result, the administrator must specify different orderings of the server endpoints on different IBM Storage Scale nodes in the /var/mmfs/etc/RKM.conf file.

...
   kmipServerUri  = tls://keysrv.ibm.com:5696
   kmipServerUri2 = tls://keysrv_backup.ibm.com:5696
...

...
   kmipServerUri  = tls://keysrv_backup.ibm.com:5696
   kmipServerUri2 = tls://keysrv.ibm.com:5696
...