Chapter 8. Enabling Encryption

Red Hat Gluster Storage supports network encryption using TLS/SSL. Red Hat Gluster Storage uses TLS/SSL for authentication and authorization, in place of the home grown authentication framework used for normal connections. Red Hat Gluster Storage supports the following encryption types:

  • I/O encryption - encryption of the I/O connections between the Red Hat Gluster Storage clients and servers.
  • Management encryption - encryption of the management (glusterd) connections within a trusted storage pool.

8.1. Prerequisites

To enable encryption it is necessary to have 3 certificates per node (glusterfs.key, gluserfs.pem and glusterfs.ca). For more information about the steps to be performed as prerequisites, see https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html-single/administration_guide/index#chap-Network_Encryption-Preparing_Certificates.

Ensure to enable encryption while registering the storageclass file using the volumeoptions parameter. For more information on registering a storageclass file for File storage, see https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/operations_guide/index#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-OpenShift_Creating_Persistent_Volumes-Dynamic_Prov.

Note
  • Ensure to perform the steps on all the OpenShift nodes except master.
  • All the Red Hat Gluster Storage volumes are mounted on the OpenShift nodes and then bind mounted to the application pods. Hence, it is not required to perform any encryption related operations specifically on the application pods.

8.2. Enabling Encryption for a New Red Hat Openshift Container Storage Setup

You can configure network encryption for a new Red Hat Openshift Container Storage setup for both I/O encryption and management encryption.

8.2.1. Enabling Management Encryption

Though Red Hat Gluster Storage can be configured only for I/O encryption without using management encryption, it is recommended to have management encryption. If you want to enable SSL only on the I/O path, skip this section and proceed with Section 8.2.2, “Enabling I/O encryption for a Volume”.

On the server

Perform the following on all the server, ie, the OpenShift nodes on which Red Hat Gluster Storage pods are running.

  1. Create the /var/lib/glusterd/secure-access file. 

    # touch /var/lib/glusterd/secure-access

On the clients

Perform the following on the clients, that is, on all the remaining OpenShift nodes on which Red Hat Gluster Storage is not running.

  1. Create the /var/lib/glusterd/secure-access file. 

    # touch /var/lib/glusterd/secure-access
Note

All the Red Hat Gluster Storage volumes are mounted on the OpenShift nodes and then bind mounted to the application pods. Hence, it is not required to perform any encryption related operations specifically on the application pods.

After running the commands on the server and clients, deploy Red Hat Openshift Container Storage. For more information, see https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/deployment_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-Setting_the_environment-Deploy_CNS.

8.2.2. Enabling I/O encryption for a Volume

Enable the I/O encryption between the servers and clients:

Note

The servers are the OpenShift nodes on which Red Hat Gluster Storage pods are running.

The clients are the remaining OpenShift nodes on which Red Hat Gluster Storage is not running.

  1. Ensure Red Hat Openshift Container Storage is deployed before proceeding with further steps. For more information see, https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/deployment_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-Setting_the_environment-Deploy_CNS

  2. You can either create a statically provisioned volume or a dynamically provisioned volume. For more information about static provisioning of volumes, see https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-OpenShift_Creating_Persistent_Volumes-Static_Prov. For more information about dynamic provisioning of volumes, see https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-OpenShift_Creating_Persistent_Volumes-Dynamic_Prov

    Note

    To enable encryption during the creation of statically provisioned volume, execute the following command: 

     # heketi-cli volume create --size=100 --gluster-volume-options="client.ssl on","server.ssl on"

  3. Stop the volume by executing the following command: 

    # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

    The gluster pod name is the name of one of the Red Hat Gluster Storage pods of the trusted storage pool to which the volume belongs.

    Note

    To get the VOLNAME, execute the following command: 

    # oc describe pv <pv_name>

    For example: 

    # oc describe pv  pvc-01569c5c-1ec9-11e7-a794-005056b38171
Name:           pvc-01569c5c-1ec9-11e7-a794-005056b38171
Labels:         <none>
StorageClass:   fast
Status:         Bound
Claim:          storage-project/storage-claim68
Reclaim Policy: Delete
Access Modes:   RWO
Capacity:       1Gi
Message:
Source:
    Type:               Glusterfs (a Glusterfs mount on the host that shares a pod's lifetime)
    EndpointsName:      glusterfs-dynamic-storage-claim68
    Path:               vol_0e81e5d6e46dcbf02c11ffd9721fca28
    ReadOnly:           false
No events.

    The VOLNAME is the value of "path" in the above output.

  4. Set the list of common names of all the servers to access the volume. Ensure to include the common names of clients which will be allowed to access the volume. 

    # oc rsh <gluster_pod_name> gluster volume set VOLNAME auth.ssl-allow 'server1,server2,server3,client1,client2,client3'
    Note

    If you set auth.ssl-allow option with * as value, any TLS authenticated clients can mount and access the volume from the application side. Hence, you set the option’s value to * or provide common names of clients as well as the nodes in the trusted storage pool.

  5. Enable the client.ssl and server.ssl options on the volume. 

    # oc rsh <gluster_pod_name> gluster volume set VOLNAME client.ssl on
# oc rsh <gluster_pod_name> gluster volume set VOLNAME server.ssl on

  6. Start the volume. 

    # oc rsh <gluster_pod_name> gluster volume start VOLNAME

8.3. Enabling Encryption for an Existing Red Hat Openshift Container Storage Setup

You can configure network encryption for an existing Red Hat Openshift Container Storage Storage setup for both I/O encryption and management encryption.

8.3.1. Enabling I/O encryption for a Volume

Enable the I/O encryption between the servers and clients for a volume:

Note

The servers are the OpenShift nodes on which Red Hat Gluster Storage pods are running.

The clients are the remaining OpenShift nodes on which Red Hat Gluster Storage is not running.

  1. Stop all the application pods that have the Red Hat Gluster Storage volumes.

  2. Stop the volume. 

    # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

    The gluster pod name is the name of one of the Red Hat Gluster Storage pods of the trusted storage pool to which the volume belongs.

  3. Set the list of common names for clients allowed to access the volume. Be sure to include the common names of all the servers. 

    # oc rsh <gluster_pod_name> gluster volume set VOLNAME auth.ssl-allow 'server1,server2,server3,client1,client2,client3'
    Note

    If you set auth.ssl-allow option with * as value, any TLS authenticated clients can mount and access the volume from the application side. Hence, you set the option’s value to * or provide common names of clients as well as the nodes in the trusted storage pool.

  4. Enable client.ssl and server.ssl on the volume by using the following command: 

    # oc rsh <gluster_pod_name> gluster volume set VOLNAME client.ssl on
# oc rsh <gluster_pod_name> gluster volume set VOLNAME server.ssl on

  5. Start the volume. 

    # oc rsh <gluster_pod_name> gluster volume start VOLNAME
  6. Start the application pods to use the I/O encrypted Red Hat Gluster Storage volumes.

8.3.2. Enabling Management Encryption

Management encryption is recommended, even though, Red Hat Gluster Storage can be configured only for I/O encryption without using management encryption. On an existing installation, with running servers and clients, schedule a downtime of volumes, applications, clients, and other end-users to enable management encryption.

You cannot currently change between unencrypted and encrypted connections dynamically. Bricks and other local services on the servers and clients do not receive notifications from glusterd if they are running when the switch to management encryption is made.

  1. Stop all the application pods that have the Red Hat Gluster Storage volumes.

  2. Stop all the volumes. 

    # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

  3. Stop the Red Hat Gluster Storage pods. 

    # oc delete daemonset glusterfs-storage

  4. On deletion of daemon set the pods go down. To verify if the pods are down, execute the following command: 

    # oc get pods

  5. Create the /var/lib/glusterd/secure-access file on all OpenShift nodes. 

    # touch /var/lib/glusterd/secure-access

  6. Create the Red Hat Gluster Storage daemonset by executing the following command:

    Note

    For Ansible deployments, the image name and the version has to be specified in the template, before executing the command. 

    # oc process glusterfs | oc create -f -

  7. On creation of daemon set the pods are started. To verify if the pods are started, execute the following command: 

    # oc get pods

  8. Start all the volumes. 

    # oc rsh <gluster_pod_name> gluster volume start VOLNAME
  9. Start the application pods to use the management encrypted Red Hat Gluster Storage.

8.4. Disabling Encryption

You can disable encryption for on Red Hat Openshift Container Storage setup in the following two scenarios:

  • Disabling I/O Encryption for a Volume
  • Disabling Management Encryption

8.4.1. Disabling I/O Encryption for all the Volumes

Execute the following commands to disable the I/O encryption between the servers and clients for a volume:

Note

The servers are the OpenShift nodes on which Red Hat Gluster Storage pods are running.

The clients are the remaining OpenShift nodes on which Red Hat Gluster Storage is not running.

  1. Stop all the application pods that have the Red Hat Gluster Storage volumes.

  2. Stop all the volumes. 

    # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

  3. Reset all the encryption options for a volume: 

    # oc rsh <gluster_pod_name> gluster volume reset VOLNAME auth.ssl-allow
# oc rsh <gluster_pod_name> gluster volume reset VOLNAME client.ssl
# oc rsh <gluster_pod_name> gluster volume reset VOLNAME server.ssl

  4. Delete the files that were used for network encryption using the following command on all the OpenShift nodes: 

    # rm /etc/ssl/glusterfs.pem /etc/ssl/glusterfs.key /etc/ssl/glusterfs.ca
    Note

    Deleting these files in a setup where management encryption is enabled will result in glusterd failing on all gluster pods and hence should be avoided.

  5. Stop the Red Hat Gluster Storage pods. 

    # oc delete daemonset glusterfs

  6. On deletion of daemon set the pods go down. To verify if the pods are down, execute the following command: 

    # oc get pods

  7. Create the Red Hat Gluster Storage daemonset by executing the following command:

    Note

    For Ansible deployments, the image name and the version has to be specified in the template, before executing the command. 

    # oc process glusterfs | oc create -f -

  8. On creation of daemon set the pods are started. To verify if the pods are started, execute the following command: 

    # oc get pods

  9. Start the volume. 

    # oc rsh <gluster_pod_name> gluster volume start VOLNAME
  10. Start the application pods to use the I/O encrypted Red Hat Gluster Storage volumes.

8.4.2. Disabling Management Encryption

You cannot currently change between unencrypted and encrypted connections dynamically. Bricks and other local services on the servers and clients do not receive notifications from glusterd if they are running when the switch to management encryption is made.

Execute the following commands to disable the management encryption

  1. Stop all the application pods that have the Red Hat Gluster Storage volumes.

  2. Stop all the volumes. 

    # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

  3. Stop the Red Hat Gluster Storage pods. 

    # oc delete daemonset glusterfs

  4. On deletion of daemon set the pods go down. To verify if the pods are down, execute the following command: 

    # oc get pods

  5. Delete the /var/lib/glusterd/secure-access file on all OpenShift nodes to disable management encryption. 

    # rm /var/lib/glusterd/secure-access

  6. Delete the files that were used for network encryption using the following command on all the OpenShift nodes: 

    # rm /etc/ssl/glusterfs.pem /etc/ssl/glusterfs.key /etc/ssl/glusterfs.ca

  7. Create the Red Hat Gluster Storage daemonset by executing the following command:

    Note

    For Ansible deployments, the image name and the version has to be specified in the template, before executing the command. 

    # oc process glusterfs | oc create -f -

  8. On creation of daemon set the pods are started. To verify if the pods are started, execute the following command: 

    # oc get pods

  9. Start all the volumes. 

    # oc rsh <gluster_pod_name> gluster volume start VOLNAME
  10. Start the application pods to use the management encrypted Red Hat Gluster Storage.