Secrets Encryption

Kubernetes provides robust mechanisms for managing secrets and ensuring data security, but requires deliberate configuration to protect sensitive information. Secrets are used to store credentials, API keys, and other sensitive data, but they must be handled carefully to avoid exposure. This section covers best practices for secrets management, encryption, and integration with security controls.

Secrets Management¶

Creating and Storing Secrets¶

Kubernetes secrets are base64-encoded objects that store sensitive data. They can be created using kubectl or directly via the API. For example:

kubectl create secret generic db-creds \
  --from-literal=USER=admin \
  --from-literal=PASSWORD=securePass123

This creates a secret named db-creds with two key-value pairs. Secrets are stored in etcd, which requires explicit configuration (e.g., --encryption-provider flag or KMS integration) for encryption at rest. Do not assume etcd is encrypted by default; this must be manually enabled in production clusters. Sensitive data should never be stored in plaintext.

Using Secrets in Pods¶

Secrets can be mounted as volumes or injected as environment variables. For example, to mount a secret as a volume:

volumeMounts:
- name: db-secrets
  mountPath: /etc/db
  readOnly: true
volumes:
- name: db-secrets
  secret:
    secretName: db-creds

This makes the secret available as files in /etc/db within the container. For environment variables:

env:
- name: DB_USER
  valueFrom:
    secretKeyRef:
      name: db-creds
      key: USER

Avoid exposing secrets via environment variables unless absolutely necessary, as they can be logged or leaked.

Init Containers for Secret Injection¶

Init containers are used to perform setup tasks before the main container starts. They can be used to inject secrets into shared volumes or perform validation:

initContainers:
- name: init-db
  image: busybox
  command:
  - sh
  - -c
  - echo "DB_USER=$(cat /etc/db/USER)" > /etc/db/validated
  volumeMounts:
  - name: db-secrets
    mountPath: /etc/db

This init container reads the secret and writes a validated file, ensuring the secret exists before the main container starts. Add error handling for missing secrets or failed reads, such as checking exit codes or logging fallback mechanisms.

Encryption at Rest and in Transit¶

Encryption at Rest¶

Kubernetes does not encrypt secrets at rest by default. To protect data, enable node-level disk encryption using OS-level tools like LUKS, not kubelet-specific features. Ensure etcd (the Kubernetes API store) is encrypted with TLS and configured with a secure key management system (KMS) via explicit flags or integration.

In-Transit Encryption¶

All communication between Kubernetes components (e.g., API server, etcd, kubelet) must use TLS. Verify that: - The API server uses a valid certificate. - kubelet communicates with the API server over HTTPS. - etcd is configured with TLS and a dedicated certificate authority.

Compliance and Best Practices¶

Least Privilege: Restrict access to secrets using Role-Based Access Control (RBAC) and label-based policies.
Secret Rotation: Automate secret rotation using tools like HashiCorp Vault or Kubernetes Secrets Manager.
Audit Logs: Enable audit logging to track access to secrets and detect unauthorized activity.
Avoid Hardcoding: Never embed secrets in YAML files. Use external secret managers or CI/CD pipelines to inject them at runtime.

Key takeaways¶

Use Kubernetes secrets for sensitive data but never store them in plaintext.
Mount secrets as volumes or inject them via environment variables with caution.
Init containers can validate or process secrets before application startup. Handle secret absence or errors explicitly.
Encrypt data at rest using node-level disk encryption (e.g., LUKS) and etcd TLS.
Combine Kubernetes security features with external tools (e.g., Vault) for full compliance.