Kubernetes and Cloud Native Associate (KCNA)Cloud Native SecurityMedium
A developer needs to configure a custom application running in a Pod to access an external Key Management System (KMS) for cryptographic operations. The application requires credentials to authenticate with the KMS. Following secure practices, how should these credentials be securely provided to the Pod without embedding them directly in the container image or configuration files?
- ABy hardcoding them into the Dockerfile for the container image.
- BBy mounting a Kubernetes Secret as a volume into the Pod.
- CAs environment variables directly within the Pod definition.
- DVia a Kubernetes ConfigMap, base64 encoded.
Show answer & explanationAnswer & explanation
Correct answer: B. By mounting a Kubernetes Secret as a volume into the Pod.
Mounting a Kubernetes Secret as a volume provides credentials as files within the Pod's filesystem, which is a more secure method than environment variables (which can be easily exposed) or hardcoding. Secrets are also encrypted at rest in etcd by default (if configured) and managed by Kubernetes.
Why the other options are wrong
- A. Hardcoding credentials into a Dockerfile is a major security risk, making them permanently part of the image and difficult to rotate.
- C. Environment variables are generally discouraged for secrets as they can be easily exposed (e.g., via `kubectl describe pod` or `exec` into a container).
- D. ConfigMaps are for non-sensitive configuration data; while base64 encoding obscures data, it does not provide encryption at rest or protection against access similar to Secrets.
Kubernetes Secrets
A Kubernetes object used to store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys. Secrets are designed to be more secure than plain text in ConfigMaps or Pod definitions.
- Stores sensitive data.
- Can be mounted as files or exposed as environment variables.
- Encrypted at rest in etcd (if configured).
Memory trick: ConfigMaps are for maps, Secrets are for keys.