Skip to main content

More Info:

Verifies that —encryption-provider-config is set so secrets are encrypted at rest in etcd rather than stored in plaintext.

Risk Level

High

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. On every control plane node, create a secure directory and EncryptionConfig file (adjust key value if you generate your own):
  1. On every control plane node, edit the API server static pod manifest to add the encryption-provider-config flag:
(If the flag already exists with a different path, edit that line instead to set it to /etc/kubernetes/encryption/encryption-config.yaml.)
  1. On every control plane node, ensure the EncryptionConfig file is mounted into the kube-apiserver pod by adding a volume and volumeMount if they are not present. Edit /etc/kubernetes/manifests/kube-apiserver.yaml with a root editor:
Under spec.containers[0].volumeMounts add:
Under spec.volumes add:
Save and exit; kubelet will automatically restart the kube-apiserver static pod when the manifest changes.
  1. On any machine with kubectl access, after the apiserver pods are running again, re-encrypt existing Secret resources so they are stored encrypted in etcd. First label all namespaces that should be processed (example: all non-system namespaces):
  1. On every control plane node, verify that the kube-apiserver process is now using the encryption-provider-config flag:
A matching line in the output confirms the setting is active.
kubectl cannot modify the API server’s host-level static pod manifest or its process flags. This finding must be remediated directly on every control plane node by editing /etc/kubernetes/manifests/kube-apiserver.yaml and configuring the encryption provider config there; see the Manual Steps section for the full procedure.