Chapter 2. Storage classes and storage pools

The OpenShift Container Storage operator installs a default storage class depending on the platform in use. This default storage class is owned and controlled by the operator and it cannot be deleted or modified. However, you can create custom storage classes to use other storage resources or to offer a different behavior to applications.

With OpenShift Container Platform, You can create multiple storage pools which map to storage classes that provide the following features:

  • Enable applications with their own high availability to use persistent volumes with two replicas, potentially improving application performance.
  • Save space for persistent volume claims using storage classes with compression enabled.
Note

Custom storage classes are not supported for external mode OpenShift Container Storage clusters.

2.1. Creating storage classes and pools

You can create a storage class using an existing pool or you can create a new pool for the storage class while creating it.

Prerequisites

Ensure that the OpenShift Container Storage cluster is in Ready state.

Procedure

  1. Log in to OpenShift Web Console.
  2. Click Storage → Storage Classes.
  3. Click Create Storage Class.
  4. Enter the storage class Name and Description.
  5. Select either Delete or Retain for the Reclaim Policy. By default, Delete is selected.
  6. Select RBD Provisioner which is the plugin used for provisioning the persistent volumes.

  7. You can either create a new pool or use an existing one.

    Create a new pool
    1. Enter a name for the pool.
    2. Choose 2-way-Replication or 3-way-Replication as the Data Protection Policy.

    3. Select Enable compression if you need to compress the data.

      Enabling compression can impact application performance and might prove ineffective when data to be written is already compressed or encrypted. Data written before enabling compression will not be compressed.

    4. Click Create to create the storage pool.
    5. Click Finish after the pool is created.
    6. Click Create to create the storage class.
    Use an existing pool
    1. Choose a pool from the list.
    2. Click Create to create the storage class with the selected pool.

2.2. Creating a storage class for persistent volume encryption

Encryption of persistent volume provisioned through storage class encryption using an external key management system (KMS) is a technology preview feature. Persistent volume encryption is only available for RBD PVs.

Important

Storage class encryption is a Technology Preview feature available only for RBD PVs. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information, see Technology Preview Features Support Scope.

Prerequisites

  • The OpenShift Container Storage cluster is in Ready state.

  • On the external key management system (KMS),

    • Ensure that a policy with a token exists and the key value backend path in Vault is enabled. See Enabling key value and policy in Vault.
    • Ensure that you are using signed certificates on your Vault servers.

  • Create a secret in the tenant’s namespace as follows:

    • On the OpenShift Container Platform web console, navigate to Workloads → Secrets.
    • Click Create → Key/value secret.
    • Enter Secret Name as ceph-csi-kms-token.
    • Enter Key as token.
    • Enter Value. It is the token from Vault. You can either click Browse to select and upload the file containing the token or enter the token directly in the text box.
    • Click Create.
Note

The token can be deleted only after all the encrypted PVCs using the ceph-csi-kms-token have been deleted.

Procedure

  1. Navigate to Storage → Storage Classes.
  2. Click Create Storage Class.
  3. Enter the storage class Name and Description.
  4. Select either Delete or Retain for the Reclaim Policy. By default, Delete is selected.
  5. Select RBD Provisioner openshift-storage.rbd.csi.ceph.com which is the plugin used for provisioning the persistent volumes.
  6. Select Storage Pool where the volume data will be stored.

  7. Select Enable Encryption checkbox.

    1. Key Management Service Provider is set to Vault by default.
    2. Enter Vault Service Name, host Address of Vault server ('https://<hostname or ip>'), and Port number.

    3. Expand Advanced Settings to enter certificate details.

      1. Enter the key value secret path in Backend Path that is dedicated and unique to OpenShift Container Storage.
      2. (Optional) Enter TLS Server Name and Vault Enterprise Namespace.
      3. Provide CA Certificate, Client Certificate and Client Private Key by uploading the respective PEM encoded certificate file.
      4. Click Save.
    4. Click Connect.
  8. Review external key management service Connection details. To modify the information, click Change connection details and edit the fields.
  9. Click Create.

  10. Edit the configmap to add the VAULT_BACKEND parameter if the Hashicorp Vault setup does not allow automatic detection of the Key/Value (KV) secret engine API version used by the backend path.

    Note

    VAULT_BACKEND is an optional parameter that is added to the configmap to specify the version of the KV secret engine API associated with the backend path. Ensure that the value matches the KV secret engine API version that is set for the backend path, otherwise it might result in a failure during persistent volume claim (PVC) creation.

    1. Identify the encryptionKMSID being used by the newly created storage class.

      1. On the OpenShift Web Console, navigate to Storage → Storage Classes.
      2. Click the Storage class name → YAML tab.

      3. Capture the encryptionKMSID being used by the storage class.

        Example: 

        encryptionKMSID: 1-vault
    2. On the OpenShift Web Console, navigate to Workloads → ConfigMaps.
    3. To view the KMS connection details, click csi-kms-connection-details.

    4. Edit the configmap.

      1. Click Action menu (⋮) → Edit ConfigMap.

      2. Add the VAULT_BACKEND parameter depending on the backend that is configured for the previously identified encryptionKMSID.

        You can assign kv for KV secret engine API, version 1 and kv-v2 for KV secret engine API, version 2 as the VAULT_BACKEND parameter.

        Example: 

        kind: ConfigMap
apiVersion: v1
metadata:
  name: csi-kms-connection-details
[...]
data:
  1-vault: >-

    {
      "KMS_PROVIDER": "vaulttokens",
      "KMS_SERVICE_NAME": "vault",
      [...]
      "VAULT_BACKEND": "kv-v2"
    }
      3. Click Save.
Important

Red Hat works with the technology partners to provide this documentation as a service to the customers. However, Red Hat does not provide support for the Hashicorp product. For technical assistance with this product, contact Hashicorp.