Handling Sensitive Data with Kubernetes Secrets

Applications often require sensitive information such as passwords, API keys, or TLS certificates. Storing these values directly in Pod specifications or ConfigMaps is insecure. Kubernetes provides Secrets to manage sensitive data safely. Secrets ensure that confidential information is stored securely and injected into Pods only when needed.

What are Kubernetes Secrets?

A Secret is a Kubernetes object designed to store sensitive data in key-value pairs. Unlike ConfigMaps, Secrets are intended for confidential information and are base64-encoded by default. They can be consumed by Pods as environment variables or mounted as files.

Key Features

• Secure Storage: Secrets are stored in etcd, which should be encrypted at rest.
• Controlled Access: Access to Secrets is managed via Kubernetes RBAC policies.
• Flexible Usage: Secrets can be injected as environment variables or mounted as volumes.
• Decoupling: Sensitive data is separated from application code and Pod specs.

Creating Secrets

Command-Line Example

# Create a Secret from literal values
kubectl create secret generic db-secret --from-literal=username=admin --from-literal=password=Pa$$w0rd

# Create a Secret from a file
kubectl create secret generic tls-secret --from-file=cert.pem --from-file=key.pem

YAML Example: Secret

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: YWRtaW4=
  password: UGEkJHcwcmQ=

Explanation: The values are base64-encoded. For example, admin becomes YWRtaW4=.

Using Secrets in Pods

Injecting as Environment Variables

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-demo
spec:
  containers:
  - name: demo-container
    image: nginx
    env:
    - name: DB_USER
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: username
    - name: DB_PASS
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password

Explanation: The Pod injects username and password from the Secret as environment variables.

Mounting as Volumes

apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-demo
spec:
  containers:
  - name: demo-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secret
  volumes:
  - name: secret-volume
    secret:
      secretName: db-secret

Explanation: The Secret is mounted as files inside /etc/secret, allowing applications to read sensitive data securely.

Flowchart: Secret Lifecycle

   Developer creates Secret ---> API Server validates ---> etcd stores securely
          |
          v
   Pod references Secret ---> Injected as env variables or mounted files
          |
          v
   Application consumes sensitive data securely
  

Real-Time Example

In a banking application:

• Secrets: Store database credentials and TLS certificates.
• Pods: Inject credentials as environment variables for secure database connections.
• Volumes: Mount TLS certificates for encrypted communication.

Common Mistakes

• Storing sensitive data in ConfigMaps instead of Secrets.
• Not encrypting etcd at rest, exposing Secrets to potential attacks.
• Hardcoding credentials inside Pod specifications.
• Granting broad RBAC permissions, allowing unauthorized access to Secrets.

Interview Notes

Q1: Difference between ConfigMap and Secret?

Answer: ConfigMap stores non-sensitive configuration data, while Secret stores sensitive data like passwords and certificates.

Q2: How do you use Secrets in Pods?

Answer: Secrets can be injected as environment variables or mounted as volumes.

Q3: How are Secrets stored in Kubernetes?

Answer: Secrets are stored in etcd, base64-encoded, and should be encrypted at rest for security.

Q4: Example Interview Task

apiVersion: v1
kind: Pod
metadata:
  name: secret-task
spec:
  containers:
  - name: demo-container
    image: nginx
    env:
    - name: API_KEY
      valueFrom:
        secretKeyRef:
          name: api-secret
          key: api-key

Explanation: This Pod injects an API key from the Secret api-secret into the container as an environment variable.

Advanced Notes

• Encryption at Rest: Always enable etcd encryption for Secrets.
• RBAC Policies: Restrict access to Secrets to authorized users and service accounts.
• External Secret Managers: Integrate with tools like HashiCorp Vault or AWS Secrets Manager for enhanced security.
• Best Practices: Rotate Secrets regularly and avoid exposing them in logs.

Summary

Kubernetes Secrets provide a secure way to manage sensitive data such as passwords, API keys, and certificates. They can be injected into Pods as environment variables or mounted as files. Proper use of Secrets, combined with encryption and RBAC, ensures applications remain secure. Avoiding common mistakes and mastering Secret management prepares developers for production-ready deployments and interviews.