IBM Cloud Docs
Encryption overview

Encryption overview

Virtual Private Cloud Classic infrastructure Satellite

Protect sensitive information in your Red Hat® OpenShift® on IBM Cloud® cluster to ensure data integrity and to prevent your data from being exposed to unauthorized users.

The following table outlines the default and optional data encryption for Red Hat OpenShift on IBM Cloud clusters.

Table 1. Default and optional data encryption
Component Encrypted by default? Bring your own key support? Enablement time Supported KMS providers Cross account support?
Control plane Yes No During cluster creation.
  • Hyper Protect Crypto Services
  • Key Protect
Cross account supported for Classic and VPC clusters only.
Worker node disks Yes Yes During cluster creation or worker pool creation.
  • Hyper Protect Crypto Services
  • Key Protect
Yes
Cluster secrets No Yes After cluster creation by using kms enable.
  • Hyper Protect Crypto Services
  • Key Protect
Cross account supported for Classic and VPC clusters only.
Persistent storage Depends on the storage provider. Depends on provider After cluster creation, when setting up storage.
  • Hyper Protect Crypto Services
  • Key Protect
Depends on the storage provider.

Control plane

Components in the Red Hat OpenShift master boot up on a LUKS-encrypted drive using an IBM-managed key. The etcd component of the master stores the configuration files of your Kubernetes resources, such as deployments and secrets. Data in etcd is stored on the local disk of the Kubernetes master and is backed up to IBM Cloud Object Storage. Data is encrypted during transit to IBM Cloud Object Storage and at rest.

Worker node disks

Attached disks are used to boot your worker node, host the container file system, and store locally pulled images. The encryption and number of disks varies by infrastructure provider.

VPC worker nodes
By default, the one primary disk of VPC worker nodes is AES-256 bit encrypted at rest by the underlying VPC infrastructure provider. You can manage the encryption of the worker nodes by enabling a KMS provider at the worker pool level. For more information, about encryption VPC worker node disks, see Setting up worker node disk encryption for VPC clusters.
Classic worker nodes
The primary disk has the kernel images to boot your worker node. This disk is unencrypted. The secondary disk has the container file system and locally pulled images. This disk is AES 256-bit encrypted with an IBM-managed LUKS encryption key that is unique to the worker node and stored as a Kubernetes secret in your cluster. When you reload or update your worker nodes, the LUKS keys are rotated.
Satellite worker nodes
The encryption of the OS disk and secondary disk is managed at the IAAS layer of the platform Satellite is deployed on. The encryption of persistent storage volumes utilized within the cluster is managed at the persistent storage plug-in level and backing storage device level. For more information about encryption for storage devices or plug-ins, see the device provider documentation or the storage plug-in documentation.

Cluster secrets

Kubernetes secrets are base64 encoded by default. You can further protect Kubernetes secrets and any credentials stored in secrets by enabling a key management service (KMS) provider, such as IBM® Key Protect for IBM Cloud® or Hyper Protect Crypto Services.

When you enable a key management service (KMS) provider for your cluster, you bring your own root key. The root key is used to encrypt the data encryption keys (DEKs) which are then used to encrypt the secrets in your cluster. The root key is stored in the KMS provider instance that you control. The encrypted DEKs are stored in etcd and can only be unencrypted using the root key from the KMS provider. For more information about how key encryption works, see Envelope encryption.

Review the following notes about cluster secret encryption.

  • Cluster secrets are encrypted by using your KMS.
  • Cluster secrets are automatically updated after rotating root keys.
  • Clusters that use the root key are viewable from the KMS provider interface.
  • Clusters automatically respond if you disable, enable, or restore root keys.
  • Disabling a root key restricts cluster functionality until you reenable the key.
  • Deleting a root key makes the cluster unusable and unrecoverable.
  • Root keys can't be deleted if the key is used by a cluster.
  • You can't add more than one KMS provider to the cluster.
  • You can have only one KMS provider enabled in the cluster at a time.
  • You can switch the KMS provider, but you can't disable KMS provider encryption after it is enabled.
  • You can't disable KMS provider encryption.

To set up cluster secret encryption, see [Setting up worker node disk encryption for VPC clusters.]

Persistent storage

Depending on the type of persistent storage you use, you can encrypt the data written to the storage volumes by enabling a KMS provider. For more information about the types of persistent storage and encryption available, see Understanding your storage options.

Next steps

To get started with encryption, you must first create a KMS instance and root key.