Create a storage class for persistent volume (PV) encryption.
Before you begin
Based on your use case, you must ensure to configure access to KMS for one of the following,
as detailed in Access configuration for Key Management System (KMS).
- Using
vaulttokens: allows users to authenticate using a token
- Using
vaulttenantsa: allows users to use serviceaccounts to
authenticate with Vault
Procedure
- Create a storage class by going to
and
clicking Create Storage Class.
Fill in the form with the
following information:
- Fill in the storage class Name and
Description.
- Select the Relcaim Policy.
Use either
Delete or
Retain.
Note: Delete is the default
selection.
- Select Volume binding mode.
Use either
Immediate or
WaitForFirstConsumer.
Note: WaitForFirstConsumer is
the default selection.
- Select RBD Provisioner
openshift-storage.rbd.csi.ceph.com which is the
plugin used for provisioning the persistent volumes.
- Select Storage Pool, where the volume data is stored from the list or
create a new pool.
- Select Enable encryption.
Use one of the following KMS connection details:
- Select existing KMS connection
- Select an existing KMS connection from the drop-down list. The list is populated from the the
connection details available in the
csi-kms-connection-details ConfigMap.
- Select the Provider from the drop down menu.
- Select the Key service for the given provider from the list.
- Create new KMS connection
- This is applicable for
vaulttokens and only.Select the
Key
Management Service Provider.
- If
Vault is selected as the Key Management Service
Provider, follow these steps:
- Enter a unique Connection Name, host Address of
the Vault server (https://<hostname or ip>),
Port number and Token.
- Expand Advanced Settings to enter additional settings and certificate
details based on your
Vault configuration:
- Enter the Key Value secret path in Backend Path that is dedicated and
unique to Fusion Data Foundation.
- Enter TLS Server Name and Vault
Enterprise Namespace.
- Upload the respective PEM encoded certificate file to provide the CA
Certificate, Client Certificate and Client Private
Key.
- Click Save.
- Click Save.
- Click Create.
- Edit the ConfigMap to add the
vaultBackend 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: vaultBackend is an optional parameters 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.
- Identify the encryptionKMSID being used by the newly created storage
class.
From the OpenShift Web Console:
- Go to .
- Click on the storage class name and go to the YAML tab.
- Capture the encryptionKMSID being used by the storage class.
For
example:
encryptionKMSID: 1-vault
- Go to
.
- View the KMS connection details, by clicking
csi-kms-connection-details.
- Edit the ConfigMaps.
- Click .
- Add the vaultBackend 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.
Example:
kind: ConfigMap
apiVersion: v1
metadata:
name: csi-kms-connection-details
[...]
data:
1-vault: |-
{
"encryptionKMSType": "vaulttokens",
"kmsServiceName": "1-vault",
[...]
"vaultBackend": "kv-v2"
}
2-vault: |-
{
"encryptionKMSType": "vaulttenantsa",
[...]
"vaultBackend": "kv"
}
- Click Save.
What to do next
The storage class can be used to create encrypted persistent volumes. For more information,
see Managing persistent volume claims.Important: IBM works with the
technology partners to provide this documentation as a service to the customers. However, IBM does
not provide support for the HashiCorp product. For technical assistance with this product, contact
HashiCorp.