CKS Practice Question 6: Secrets Encryption at Rest
Certified Kubernetes Security Specialist (CKS) · Test 1 · question 6 of 10
You add an EncryptionConfiguration that lists aescbc first and identity second for the secrets resource, point the API server at it with --encryption-provider-config, and restart the static Pod. A Secret you create afterwards appears in etcd prefixed with k8s:enc:aescbc:v1:, but etcdctl get on a Secret created last month still shows its value in clear text.
What must you do so that the older Secrets are stored encrypted as well?
Show answer and explanation
Answer:
Encryption at rest is applied on write. Enabling it changes how the API server serializes objects from that moment on, and nothing re-encrypts data already sitting in etcd. The documented remedy is to read every affected object and write it straight back, which makes the API server re-serialize it through the first provider in the list. Because identity is still configured as a later provider, the old plain-text values remain readable during the migration.
Option A is wrong: the API server performs no migration sweep at startup, and restarting it again changes nothing about existing keys.
Option C makes the situation worse. The first provider in the list is the one used for encryption, so promoting identity, which stores resources as plain text, would disable encryption for all newly written objects.
Option D operates on etcd's storage layer. Defragmentation and compaction reclaim space and drop superseded revisions; they do not transform the current value of a key, so the current plain-text Secret stays exactly as it is.
Reference: Encrypting Confidential Data at Rest