CKS Practice Question: Encrypt Kubernetes secrets at rest using aescbc

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: MDEyMzQ1Njc4OWFiY2RlZjAxMjM0NTY3ODlhYmNkZWY= - identity: {} [CORRECT]

  Why this is correct

  This is correct because it uses the proper apiVersion `apiserver.config.k8s.io/v1` and kind `EncryptionConfiguration`, which matches what kube-apiserver expects. The `aescbc` provider is specified as required, and the key `c2VjcmV0LWtleS0zMi1ieXRlcw==` is a valid base64-encoded string that decodes to a 32-byte key, which is the required length for AES-256-CBC. Including `identity: {}` as the last provider is essential because it allows the API server to read existing unencrypted secrets during the migration process, avoiding data lockout, and it also serves as a fallback if decryption fails.

• ✗

  apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: my-plain-text-key

  Why it's wrong here

  The `secret` field must contain a base64-encoded key, not a plain-text key. Kubernetes decodes the base64 string to obtain the raw key bytes for encryption; a value like `my-plain-text-key` is not valid base64 and will cause the API server to fail when parsing the configuration or when attempting to encrypt/decrypt secrets. Additionally, the plain-text string may not decode to the required 32-byte key length, further breaking AES-CBC encryption. To fix it, one must base64-encode a 32-byte random key (e.g., `c2VjcmV0LWtleS0zMi1ieXRlcw==`) and place that in the `secret` field.

• ✗

  apiVersion: v1 kind: EncryptionConfig resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: c2VjcmV0LWtleS0zMi1ieXRlcw==

  Why it's wrong here

  It uses the wrong `apiVersion` and `kind`. The correct API group is `apiserver.config.k8s.io/v1` and the kind must be `EncryptionConfiguration`, not the generic `v1` with `EncryptionConfig`. The kube-apiserver will reject an unrecognized configuration type, so this file would never be loaded, and secrets encryption would not be enabled. Furthermore, it lacks the `identity: {}` provider, which is recommended as a fallback to allow the API server to read existing unencrypted secrets during rollout; without it, upgrading an existing cluster would leave unencrypted secrets unreadable.

• ✗

  apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - secretbox: keys: - name: key1 secret: c2VjcmV0LWtleS0zMi1ieXRlcw==

  Why it's wrong here

  It specifies the `secretbox` provider instead of the `aescbc` provider that was explicitly required. While `secretbox` is a valid encryption provider using the modern ChaCha20-Poly1305/NACL secretbox construction, it is not what the task requested, so the configuration would not meet the requirement. Additionally, `secretbox` expects a nonce and key handling that differs from `aescbc`; the key format and length requirements are different. Since the task specifically says "using aescbc," the provider must be `aescbc`; using `secretbox` would fail the objective even though it might be syntactically valid.

Go deeper

Related to this question