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 from the tenant of the RKM server.

key server or Remote Key Management (RKM) server

A key server is a server that authenticates key clients and provides them with master encryption keys. 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 file encryption keys.

tenant

A tenant is an entity on a key server that contains master encryption keys and certificates.

• In the IBM Security Key Lifecycle Manager (SKLM), a tenant is called a device group.
• In the Thales Vormetric Data Security Manager (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 utility to configure and manage cluster-wide encryption configuration. This method is much preferred if your key server is the IBM Security Lifecycle Key Manager (SKLM) because the mmkeyserv utility automatically performs many of the steps that must be done manually in the regular setup. You can use this setup method only with the IBM Security Lifecycle Key Manager.

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 the IBM Security Lifecycle Key Manager (SKLM) or the Thales Vormetric Data Security Manager (DSM).

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 Encryption policies.
   2. Enable fast extended attributes. This setting is the default for a newly created file system if you are running V4.1 or later. To verify that fast extended attributes are enabled, issue a command like the following one:

      mmlsfs <Device> --fastea

      where <Device> is the name of the file system. However, if your file system was migrated from an earlier level, enter the following command to add support for fast extended attributes:

      mmmigrate <Device> --fastea

      where <Device> is the name of the file system. For more information, see Completing the upgrade to a new level of IBM Spectrum 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 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 attempting to access 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 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 Spectrum 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 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 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 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
...