Setting up cluster secret encryption

Enabling secret encryption from the CLI

You can enable a KMS provider, update the KMS provider instance, or update the root key through the CLI.

Setting up cross-account encryption by using a KMS in a different account is supported in the CLI or API.

1. Create a KMS instance and root key. If you want to use cross account KMS encryption, make sure to create the KMS and root key in the account whose KMS instance you want to use.

2. Get the ID of the KMS instance that you previously created.

   ibmcloud oc kms instance ls
   

3. Get the ID of the root key that you previously created.

   ibmcloud oc kms crk ls --instance-id <KMS_instance_ID>
   

4. Enable the KMS provider to encrypt secrets in your cluster. Fill in the options with the information that you previously retrieved. The KMS provider's private cloud service endpoint is used by default to download the encryption keys. To use the public cloud service endpoint instead, include the --public-endpoint option. The enablement process can take some time to complete.

   ibmcloud oc kms enable -c <cluster_name_or_ID> --instance-id <kms_instance_ID> --crk <root_key_ID> [--public-endpoint]
   

   During the enablement, you might not be able to access the Kubernetes master such as to update YAML configurations for deployments.

5. Verify that the KMS enablement process is finished. The process is finished when that the Master Status is Ready and Key management service is enabled.

   ibmcloud oc cluster get -c <cluster_name_or_ID>
   

   Example output when the enablement is in progress

   NAME:                   <cluster_name>   
   ID:                     <cluster_ID>   
   ...
   Master Status:          Key management service feature enablement in progress.  
   

   Example output when the master is ready

   NAME:                   <cluster_name>   
   ID:                     <cluster_ID>   
   ...
   Master Status:          Ready (1 min ago)
   ...
   Key Management Service: enabled   
   

   After the KMS provider is enabled in the cluster, all cluster secrets are automatically encrypted.

6. Optional: Verify that your secrets are encrypted.

Do not delete root keys in your KMS instance, even if you rotate to use a new key. If you delete a root key that a cluster uses, the cluster becomes unusable, loses all its data, and can't be recovered. When you rotate a root key, you can't reuse a previous root key for the same cluster. Similarly, if you disable a root key, operations that rely on reading secrets fail. Unlike deleting a root key, however, you can reenable a disabled key to make your cluster usable again.

Enabling secret encryption from the console

You can enable a KMS provider, update the KMS provider instance, or update the root key through the IBM Cloud console.

1. Create a KMS instance and root key. If you want to use cross account KMS encryption, make sure to create the KMS and root key in the account whose KMS instance you want to use.

2. From the Red Hat OpenShift clusters console, select the cluster that you want to enable encryption for.

3. From the Overview tab, in the Summary > Key management service section, click Enable. If you already enabled the KMS provider, click Update.

4. Select the Key management service instance and Root key that you want to use for the encryption.

   During the enablement, you might not be able to access the Kubernetes master such as to update YAML configurations for deployments.

5. Click Enable (or Update).

6. Verify that the KMS enablement process is finished. From the Summary > Master status section, you can check the progress. Example output when the enablement is in progress.

   Master status   KMS feature enablement in progress.  
   

   Example output when the master is ready.

   Master status   Ready
   

   After the KMS provider is enabled in the cluster, all cluster secrets are automatically encrypted.

7. Optional: Verify that your secrets are encrypted.

Do not delete root keys in your KMS instance, even if you rotate to use a new key. If you delete a root key that a cluster uses, the cluster becomes unusable, loses all its data, and can't be recovered. When you rotate a root key, you can't reuse a previous root key for the same cluster. Similarly, if you disable a root key, operations that rely on reading secrets fail. Unlike deleting a root key, however, you can reenable a disabled key to make your cluster usable again.