Encryption overview
Virtual Private Cloud Classic infrastructure
Protect sensitive information in your IBM Cloud® Kubernetes Service cluster to ensure data integrity and to prevent your data from being exposed to unauthorized users by setting up a key management service (KMS) provider.
IBM Cloud Kubernetes Service offers encryption at several layers in your cluster. Encryption for some components is managed by IBM while, for other components, you have the option to bring your own KMS provider credentials to manage encryption yourself.
When you're done with this page, try out the quiz.
The following table outlines the encryption options for IBM Cloud Kubernetes Service clusters.
| Component | Encrypted by default? | Bring your own key support? | Enablement time | Supported KMS providers | Cross account support? |
|---|---|---|---|---|---|
| Control plane | Yes | No | During cluster creation. | IBM managed Key Protect | N/A |
| Worker node disks | Yes | Yes | During cluster creation or worker pool creation. |
|
Yes |
| Cluster secrets | No | Yes | After cluster creation by using kms enable. |
|
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. |
|
Depends on the storage provider. |
| Worker-to-worker traffic | No | No | After cluster creation. | N/A | No |
Control plane
Control plane encryption is managed by IBM.
- Components in the Kubernetes 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.
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 have only one KMS provider and key enabled in the cluster at a time.
- You can switch the KMS provider and key.
- You can't disable KMS provider encryption.
To set up cluster secret encryption, see Setting up cluster secret encryption.
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.
Worker-to-worker traffic
You can set up encryption for the data flowing between the worker nodes in your cluster by using WireGuard. For more information, see Encrypting worker-to-worker traffic with WireGuard.
Next steps
Test your knowledge with a quiz.
To continue the planning process, choose a storage option. If you're ready to get started with encryption, move on to creating a KMS instance and root key.