Secrets encryption at rest in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary purpose of enabling secrets encryption at rest in Kubernetes?

Why do Kubernetes clusters use encryption at rest for secrets?

A To automatically rotate secrets without user intervention

B To speed up the retrieval of secrets from the API server

C To allow secrets to be shared publicly without risk

D To protect secret data stored on disk from unauthorized access if the storage medium is compromised

💡 Hint

Think about what happens if someone gets physical access to the storage where secrets are saved.

Encryption at rest protects secret data stored on disk by making it unreadable without the encryption key. This prevents unauthorized users from accessing secrets even if they get access to the storage.

💻 Command Output

intermediate

What is the output of enabling encryption providers in Kubernetes API server config?

Given the following snippet in the EncryptionConfiguration file, what will be the effect on stored secrets?

apiVersion: apiserver.config.k8s.io/v1
encryptionConfig:
  resources:
  - resources:
    - secrets
    providers:
    - aescbc:
        keys:
        - name: key1
          secret: c2VjcmV0a2V5MTIzNDU2Nzg5MA==
    - identity: {}

A Secrets will be deleted automatically after encryption

B Secrets will be stored unencrypted because identity provider is last

C Secrets will be encrypted using AES-CBC with the provided key before storage

D Secrets will be encrypted using a random key each time

💡 Hint

The order of providers matters. The first provider that can encrypt is used.

The AES-CBC provider is listed first, so secrets are encrypted using AES-CBC with the given key. The identity provider is fallback and stores data unencrypted only if encryption fails.

❓ Troubleshoot

advanced

Why might secrets appear unencrypted in etcd after enabling encryption at rest?

You enabled encryption at rest for secrets in Kubernetes, but when you check etcd data, secrets appear in plain text. What could be the cause?

A The API server was not restarted after updating the encryption config

B The encryption key is too short and was rejected silently

C Secrets are always stored unencrypted in etcd regardless of config

D The kubelet is caching old secrets and showing unencrypted data

💡 Hint

Think about what is required for the API server to apply new config changes.

The API server must be restarted to load the new encryption configuration. Without restart, it continues to store secrets unencrypted.

🔀 Workflow

advanced

What is the correct order of steps to enable secrets encryption at rest in Kubernetes?

Arrange the following steps in the correct order to enable encryption at rest for secrets in a Kubernetes cluster.

A 4,1,2,3

B 1,4,2,3

C 4,2,1,3

D 1,2,4,3

💡 Hint

Think about safety first, then config, then restart, then verify.

Backing up secrets first prevents data loss. Then create the config, restart API server to apply, and finally verify encryption.

✅ Best Practice

expert

Which practice improves security when rotating encryption keys for Kubernetes secrets at rest?

You need to rotate the encryption keys used for secrets at rest. Which practice ensures minimal downtime and data safety?

A Rotate keys by changing the key name but keeping the same secret value

B Add the new key as the first provider in the EncryptionConfiguration, keep the old key as second, then restart API server

C Rotate keys by deleting all secrets and recreating them with new keys

D Remove the old key immediately and add the new key only, then restart API server

💡 Hint

Consider how Kubernetes decrypts and re-encrypts secrets during key rotation.

Adding the new key first allows the API server to encrypt new secrets with it, while still decrypting old secrets with the old key. This enables smooth rotation without data loss.