Encryption setup requirements

Setup requirements for encryption are as follows:

GPFS™ software

GPFS 4.1 Advanced Edition is required for encryption.

GPFS node setup

The following are required:

operating system image with a running version of mmfsd deployed on a set of nodes
a GPFS cluster configured and up and running
file system at the latest version level for GPFS 4.1, with the following:
- fast external attributes enabled. This is the default for newly-created 4.1 file systems. However, if the file system was migrated from an earlier level, it may be necessary to issue the mmmigratefs FsName --fastea command.
- 4KB inodes (recommended minimum size). The 4KB 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 will contain one or more wrapped FEKs, so it can potentially grow quite large. (See Encryption policies.)
gpfs.gskit and gpfs.crypto packages installed

RKM Setup

The following are required:

RKM server. The only server currently supported is IBM® Security Key Lifecycle Manager (ISKLM) v2.5.0.1 or later.
Note: ISKLM has a complete implementation of the Key Management Interoperability Protocol (KMIP) standard of the Organization for the Advancement of Structured Information Standards (OASIS). GPFS nodes use the KMIP protocol to retrieve keys from ISKLM servers.
GPFS nodes with direct network access to the RKM server

RKM Backends

Nodes in the cluster that will be used to perform data access (reading and writing files) or participate in administration tasks such as snapshot deletion, disk repair, or file system check must perform encryption. These nodes must therefore be able to contact one or more RKM backends to transparently access keys required by the encryption policies.

The configuration of each RKM backend must be described in a /var/mmfs/etc/RKM.conf file on each such node. The /var/mmfs/etc/RKM.conf file does not have to be identical; by controlling the contents of this file, the cluster administrator can control which client nodes have access to which keys. For example, the same RKM server could be given two different names in /var/mmfs/etc/RKM.conf stanzas, allowing the administrator to partition a set of MEKs hosted on a single RKM server into separate subsets of MEKs, which might belong to subsets of the nodes of the cluster.

/var/mmfs/etc/RKM.conf file

The /var/mmfs/etc/RKM.conf file consists of a series of stanzas, each of which uses the following syntax:

# RKM entry
RkmId {
   type = ISKLM                              # The RKM is an ISKLM
   kmipServerUri = tls://host:port           # TLS connection to host on port
   keyStore = /PathToKeyStoreFile            # The path to the PKCS#12 file containing server certificate
                                             #  and client public/private keypair
   passphrase = Password                     # Passphrase protecting the key store file
   clientCertLabel = LabelName               # Label of the client key pair to be used among those in the
                                             #  key store file
   tenantName = NameOfTenant                 # Name of tenant, set in IBM Security Key Lifecycle Manager set-up
   [connectionTimeout = ConnectionTimeout]   # Connection timeout, in seconds (default 60 seconds)
   [connectionAttempts = ConnectionAttempts] # Number of connection attempts (default 3)
   [retrySleep = RetrySleepUsec]             # Retry sleep time, in microsecsonds
                                             #  (default 100000 = 0.1 seconds)
}

Notes:

Each entry in the /var/mmfs/etc/RKM.conf file starts with an RkmId string that identifies the RKM. (This is the same string that will later be combined with unique KeyId identifiers to specify individual keys in encryption policy rules. See Encryption policy rules.)
The following limits apply:
- 0 < ConnectionAttempts <= 10
- 0 < RetrySleepUsec <= 10000000 (in microseconds)
- 0 < ConnectionTimeout <= 120 (in seconds)
The file size of the /var/mmfs/etc/RKM.conf file cannot exceed 1MiB.
There is no limit on the number of /var/mmfs/etc/RKM.conf entries (as long as the file size does not exceed the file size limit of 1 MiB).
The /var/mmfs/etc/RKM.conf file and the key store file are essential for security. It is best practice to store them as node-local files.

Identifying multiple RKM backends in a high-availability configuration

The ISKLM supports automated replication across multiple nodes for high-availability deployments. To identify multiple RKM backends in a high-availability configuration, specify any of the following optional parameters:

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, GPFS will attempt to fetch the key from each backup in turn until it is able to retrieve the desired MEK. Note that the addition of the URIs for the clone servers is the only required change within GPFS; all other configuration parameters (certificates, keys, node and tenant info) need not change, as 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 ISKLM 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, the administrator must specify different orderings of the server endpoints on different GPFS nodes in the /var/mmfs/etc/RKM.conf file.

For example, if there are two cloned ISKLM servers available (such as tls://keysrv.ibm.com:5696 and tls://keysrv_backup.ibm.com:5696), half of the nodes in the cluster can have the following content in /var/mmfs/etc/RKM.conf:

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

The other half can use the following:

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