File and Object Storage

Spectrum Scale Data Security Modes

By Archive User posted Thu October 31, 2019 09:26 AM

Data is the new oil
Like oil has developed the world into a better place data perhaps holds similar potential and is already responsible for most valuable brands in the IT industry. These companies are collecting tremendous data from billions of users and analyzing it to make gadgets and products even more smarter. But what if the data get leaked? According to a cyber-security research firm, recently more than 540 million records about Facebook users were publicly exposed on Amazon's cloud computing service. Such scenarios governance the importance of Data Security.

IBM Spectrum Scale, a high performance computing file system provides secure data at rest and secure data in motion (on wire).

Secure data at rest can be achieved through file system encryption provided by Spectrum Scale (in advanced edition). When file-system encryption is configured the data (not metadata) is secured at rest as well as in transit (i.e., data flow within the gpfs cluster).
If one wants to secure data in motion within a given spectrum scale cluster without configuring file-system encryption feature, one is required to make use of the cipherList parameter via mmchconfig (available in all Spectrum Scale editions).

This blog will demonstrate how to enable secure data in motion within Spectrum Scale cluster (inter-node communication) and how to verify that data is secured over wire using tcpdump. This is required by the security auditors.
Before we configure the cipherList parameter, let’s quickly understand the security mode of a cluster. The security mode of a cluster determines the level of security that the cluster provides for communications between nodes in the cluster and also for communications between clusters.

There are three security modes:

  1. EMPTY

  2. In this mode both receiving and the sending nodes do not authenticate each other, do not encrypt transmitted data and do not check the integrity of transmitted data.

  4. This is the default security mode you will find on cluster (in IBM Spectrum Scale v4.2 or later). The sending and receiving nodes authenticate each other with a TLS handshake and then close the TLS connection. Communication continues in the readable format. The nodes do not encrypt transmitted data and do not check data integrity.
  5. Cipher

  6. This is the most secure mode among all. The sending and receiving nodes authenticate each other with a TLS handshake. A TLS connection is established. The transmitted data is encrypted with the specified cipher and is checked for data integrity.To set this mode, you must specify the name of a supported cipher, such as AES128-GCM-SHA256.

In nutshell,
Feature | EMPTY | AUTHONLY | CipherList
Authentication | No | Yes | Yes
Data Integrity Check | No | No | Yes
Encryption | No | No | Yes

To identify the current security mode of cluster run the following command
mmlsconfig cipherlist
You can change the security mode with the following command:
mmchconfig cipherlist=security_mode
Note: If you are changing the security mode from EMPTY to another mode, you can do so without stopping the GPFS daemon. However, if you are changing the security mode from another mode to EMPTY, you must stop the GPFS daemon on all the nodes in the cluster. Change the security mode to EMPTY and then restart the GPFS daemon.

Let’s start changing the security mode & sniffing the packets of Spectrum Scale communication in following 3 activities.

  1. Running Spectrum Scale command (mm commands like mmlscluster)

  2. Listing files on Spectrum Scale file system

  3. Write data to file on Spectrum Scale file system


  • Spectrum Scale cluster (any edition)

  • Tcpdump (Network sniffer tool)

  • Wireshark (Optional, Packet Analyzer tool)

1. Identify the interface of Spectrum Scale communication
[root@AaryaStark ~]# mmlscluster
Node Daemon node name IP address Admin node name Designation
1 nsd0 nsd0 quorum-manager-perfmon
2 nsd1 nsd1 quorum-manager-perfmon
3 nsd2 nsd2 quorum-manager-perfmon
4 ces0 ces0 perfmon
5 ces1 ces1 perfmon
[root@AaryaStark ~]# ip a
12: ib1:
1 view



Thu December 19, 2019 05:37 PM

Ciphers are predominately CPU centric . Most processors have AES acceleration within them.

Thu November 14, 2019 06:15 PM

Hallo All are there Any results available how much influence the different cipher the possible latency and bandwith or are there this only a CPU load Problem on the Nodes in the Cluster.
Regards Renar