Secrets are not encrypted by default in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the default state of Kubernetes Secrets?

In Kubernetes, what is the default way Secrets are stored in etcd?

A Secrets are stored as plain base64-encoded strings without encryption.

B Secrets are encrypted using AES-256 by default.

C Secrets are hashed with SHA-256 before storage.

D Secrets are stored in an external vault by default.

💡 Hint

Think about how base64 encoding works and if it is a form of encryption.

Kubernetes stores Secrets as base64-encoded strings in etcd by default. Base64 encoding is not encryption; it only changes the format but does not protect the data.

💻 Command Output

intermediate

Output of viewing a Kubernetes Secret

What is the output of the command kubectl get secret mysecret -o yaml if the secret contains a password 'mypassword'?

Kubernetes

kubectl get secret mysecret -o yaml

A

data:
  password: mypassword
metadata:
  name: mysecret

B

data:
  password: encrypted:mypassword
metadata:
  name: mysecret

C

data:
  password: bXlwYXNzd29yZA==
metadata:
  name: mysecret

D

data:
  password: SHA256:mypassword
metadata:
  name: mysecret

💡 Hint

Remember how base64 encoding looks for the string 'mypassword'.

The password is stored as base64-encoded string 'bXlwYXNzd29yZA==' which decodes to 'mypassword'. Kubernetes does not encrypt it by default.

❓ Configuration

advanced

Enable encryption of Secrets at rest in Kubernetes

Which configuration snippet correctly enables encryption of Secrets at rest in Kubernetes using AES-CBC with a key named 'mykey'?

A

apiVersion: v1
kind: EncryptionConfig
resources:
- secrets
providers:
- aescbc:
    keys:
    - name: mykey
      secret: c2VjcmV0a2V5MTIzNDU2Nzg5MA==

B

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

C

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- secrets
providers:
- aescbc:
    keys:
    - name: mykey
      secret: c2VjcmV0a2V5MTIzNDU2Nzg5MA==

D

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: mykey
        secret: c2VjcmV0a2V5MTIzNDU2Nzg5MA==

💡 Hint

Check the indentation and structure carefully; 'resources' is nested under the first list item.

The correct config uses apiVersion 'apiserver.config.k8s.io/v1', kind 'EncryptionConfiguration', and properly nests 'resources' and 'providers' lists. The key secret is base64 encoded.

❓ Troubleshoot

advanced

Why are Secrets still visible in plain text after enabling encryption?

After configuring encryption at rest for Secrets, you still see base64-encoded Secrets in plain text when running kubectl get secret. Why?

A Encryption only works for ConfigMaps, not Secrets.

B Encryption configuration was not applied to the API server; it needs a restart.

C Secrets are cached in the client and not refreshed after encryption enabled.

D kubectl shows Secrets decoded from etcd; encryption is only for storage, not for kubectl output.

💡 Hint

Think about where encryption applies and what kubectl displays.

Encryption at rest protects data in etcd storage. kubectl decodes Secrets from the API server and shows base64-encoded data, which is normal and expected.

✅ Best Practice

expert

Best practice to secure Kubernetes Secrets beyond encryption at rest

Which approach is the best practice to enhance Kubernetes Secrets security beyond enabling encryption at rest?

A Integrate an external secrets management system like HashiCorp Vault and use Kubernetes External Secrets.

B Store Secrets as plain text in ConfigMaps for easier access.

C Disable RBAC to allow all users to access Secrets freely.

D Use base64 encoding with longer keys for Secrets.

💡 Hint

Think about centralized secret management and access control.

Using an external secrets manager like Vault provides strong access control, auditing, and dynamic secrets, which is better than relying only on Kubernetes encryption at rest.