Preparation for encryption

Terms defined

You should be familiar with the following terms:

device group

See tenant.

file encryption key

A file encryption key (FEK) is an encryption key that a key client uses to encrypt a data file. See Encryption keys.

key client

A key client is a computer system, such as an IBM Spectrum Scale node, that retrieves master encryption keys from a key server.

key server

A key server, also known as a Remote Key Management (RKM) server, is a server that provides master encryption keys for key clients. Examples of key server software products are IBM Security Key Lifecycle Manager (SKLM) and Vormetric Data Security Manager (DSM).

master encryption key

A master encryption key (MEK) is an encryption key that a key client uses to encrypt a file encryption key. See Encryption keys.

tenant

A tenant is an entity on a key server that contains master encryption keys and certificates. In the Vormetric Data Security Manager (DSM), a tenant is called a device group.

Required software: IBM Spectrum Scale

Required software: Remote Key Management (RKM) server

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

Preparing your cluster for encryption

Follow these steps:

1. Verify the following items in your IBM Spectrum Scale cluster:
   • The cluster is running the correct version of IBM Spectrum 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 Spectrum Scale file system on the cluster. The version of the file system must be IBM Spectrum 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 KB.This size is the recommended minimum size. The 4 KB inode size is recommended to accommodate the gpfs.Encryption extended attribute that is assigned to each encrypted file at file creation time. This extended attribute contains one or more wrapped file encryption keys (FEKs) so it can potentially grow large. For more information, see the help topic.
   2. Enable fast extended attributes. This setting is the default for a newly created file system if you are running V4.1 or later. However, if your file system was migrated from an earlier level, you might need to enter the following command to add support for fast extended attributes:

      mmmigratefs FsName --fastea

Preparing the remote key management (RKM) server

RKM back ends

The RKM back end includes a local key client, a remote tenant, and an RKM server. A tenant, or device group, resides on the RKM server and contains master encryption keys that the key client can request. Each RKM back end is described in an RKM stanza in the RKM.conf file on the node.

By controlling the contents of this file, the cluster administrator can control which client nodes have access to master encryption keys (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 master encryption keys (MEK) are cached in memory, some short-term outages while accessing a key server might not cause issues. However, failure to retrieve the keys might result in errors while 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 recommended that multiple key servers be set up in a high-availability configuration. See the subtopic Identifying multiple RKM back ends in a high-availability configuration.

The RKM.conf file and the RKM stanza

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

Identifying multiple RKM back ends in a high-availability configuration

rkmname3 {
...
   kmipServerUri2 = tls://host:port     # TLS connection to clone number 1 to host on port
   kmipServerUri3 = tls://host:port     # TLS connection to clone number 2 to host on port
   kmipServerUri4 = tls://host:port     # TLS connection to clone number 3 to host on port
   kmipServerUri5 = tls://host:port     # TLS connection to clone number 4 to host on port
   kmipServerUri6 = tls://host:port     # TLS connection to clone number 5 to host on port
...
}

If at least one backup is configured, whenever key retrieval from the master fails, IBM Spectrum Scale looks in each backup until it finds the MEK. The addition of the URIs for the clone servers is the only required change within IBM Spectrum 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 SKLM key server clones can help gain some performance advantage by distributing MEK retrieval requests across the different clones in a round-robin fashion. To achieve this result, the administrator must specify different orderings of the server endpoints on different IBM Spectrum 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
...