Kubernetes Secrets: Configure & Manage Sensitive Data

Kubernetes Secrets Management: A Deep Dive into `Secret` Object Configuration

Kubernetes `Secret` objects provide a mechanism for storing and managing sensitive information, such as passwords, OAuth tokens, and TLS private keys. This document examines the structure and configuration of `Secret` objects, focusing on practical application for engineers.

Understanding the `Secret` Object Structure

A Kubernetes `Secret` object is a key-value pair store. The data field within a `Secret` object is used to store sensitive data. Values in the data field are base64 encoded. The type field specifies the intended use of the secret. Common types include:

• kubernetes.io/basic-auth: For basic authentication credentials.
• kubernetes.io/dockerconfigjson: For Docker registry credentials.
• kubernetes.io/tls: For TLS certificates and keys.
• kubernetes.io/opaque: A generic, un-typed secret.

Example `Secret` YAML:

apiVersion: v1
kind: Secret
metadata:
  name: my-api-credentials
type: kubernetes.io/basic-auth
data:
  username: dmVyeXNlY3JldHVzZXI= # base64 encoded "verysecretuser"
  password: cGFzc3dvcmQxMjM=   # base64 encoded "password123"

In this example, username and password are base64 encoded strings. The type is set to kubernetes.io/basic-auth, indicating these are credentials for basic authentication.

Managing TLS Secrets

TLS secrets are crucial for securing network communication. They typically contain a certificate (tls.crt) and a private key (tls.key).

Example TLS `Secret` YAML:

apiVersion: v1
kind: Secret
metadata:
  name: my-tls-secret
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC... # base64 encoded certificate
  tls.key: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQo... # base64 encoded private key

When creating a TLS secret from existing certificate and key files, the kubectl create secret tls command is used.

Command Example:

kubectl create secret tls my-tls-secret --cert=path/to/tls.crt --key=path/to/tls.key

This command will generate a `Secret` object with the type: kubernetes.io/tls and the data field populated with base64 encoded tls.crt and tls.key.

Consuming Secrets in Pods

Secrets can be consumed by Pods in several ways:

• Environment Variables: Injecting secret values directly into container environment variables.
• Volume Mounts: Mounting secrets as files within a container’s filesystem.

Environment Variables

This method is suitable for small amounts of sensitive data.

Pod Definition Example (Environment Variable):

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    env:
    - name: API_USERNAME
      valueFrom:
        secretKeyRef:
          name: my-api-credentials
          key: username
    - name: API_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-api-credentials
          key: password

Volume Mounts

Mounting secrets as volumes is generally preferred for larger amounts of data or when the application expects configuration files. This approach can be beneficial for applications that need to build scalable software by externalizing configuration.

Pod Definition Example (Volume Mount):

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    volumeMounts:
    - name: api-credentials-volume
      mountPath: "/etc/secrets/api"
      readOnly: true
  volumes:
  - name: api-credentials-volume
    secret:
      secretName: my-api-credentials

When mounted as a volume, each key in the `Secret` object becomes a file within the specified mountPath. For the my-api-credentials secret, the files /etc/secrets/api/username and /etc/secrets/api/password would be created.

Security Considerations

• RBAC: Restrict access to `Secret` objects through Role-Based Access Control (RBAC).
• Encryption at Rest: Implement encryption for etcd to protect secrets stored in the cluster database.
• Rotation: Regularly rotate secrets to mitigate the impact of compromised credentials.
• Avoid Hardcoding: Never hardcode secrets in container images or application code.