More Info:
Verifies that the encryption provider config uses a strong provider such as aescbc, kms or secretbox so secrets at rest are properly encrypted.Risk Level
HighAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify the encryption provider config file (control plane node)
If this prints nothing, check
/etc/kubernetes/manifests/kube-apiserver.yamlfor an--encryption-provider-configflag and its path. -
Back up the existing encryption config and manifest (control plane node)
-
Edit the encryption configuration to use a strong provider (control plane node)
Open the file in an editor:Replace or add a resources section using a strong provider (example usingaescbc):Generate a 32‑byte key and base64‑encode it (run in another shell on the same node) and paste it intosecret: -
Confirm kube-apiserver is using the encryption config (control plane node)
Ensure/etc/kubernetes/manifests/kube-apiserver.yamlcontains the flag and correct path; edit if needed:Underspec.containers[].command, ensure a line like:Save the file; the kube-apiserver static pod will restart automatically when you edit this manifest. -
Optionally re-encrypt existing secrets (any machine with kubectl access)
This is not enforced by the benchmark but is typically required to ensure all stored secrets use the new provider. Run: -
Verification (control plane node)
After the kube-apiserver pod has restarted and is Ready, re-run the audit logic:Confirm the output showsprovider=aescbc,provider=kms, orprovider=secretboxas the first provider.
Using kubectl
Using kubectl
kubectl cannot modify the API server’s
--encryption-provider-config or the file it points to, because those are host-level settings controlled by /etc/kubernetes/manifests/kube-apiserver.yaml on each control plane node. To configure strong encryption providers (aescbc, kms, or secretbox), follow the guidance in the Manual Steps section on the control plane nodes themselves.Automation
Automation

