ConfigMaps and Secrets

Applications often require configuration data and sensitive information like passwords or API keys. Kubernetes provides two distinct resources for this purpose: ConfigMaps for non-sensitive configuration data and Secrets for sensitive information.

Using ConfigMaps for Configuration Management

ConfigMaps allow you to decouple configuration artifacts from container images, making applications portable across environments. ConfigMaps store configuration data as key-value pairs.

Creating ConfigMaps

ConfigMaps can be created in several ways:

From literal values:

kubectl create configmap app-config \
  --from-literal=APP_COLOR=blue \
  --from-literal=APP_MOD=prod
    

From a file:

kubectl create configmap app-config --from-file=config.properties
    

Using YAML definition:

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-config
data:
  game.properties: |
    enemy.types=aliens,monsters
    player.maximum-lives=5
  ui.properties: |
    color.good=purple
    color.bad=yellow
    

Using ConfigMaps in Pods

ConfigMaps can be consumed in pods in several ways:

As environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: configmap-demo-pod
spec:
  containers:
    - name: demo-container
      image: alpine
      command: ["sh", "-c", "echo $(APP_COLOR) && sleep 3600"]
      env:
        - name: APP_COLOR
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: APP_COLOR
    

As a volume mount:

apiVersion: v1
kind: Pod
metadata:
  name: configmap-volume-pod
spec:
  containers:
    - name: demo-container
      image: alpine
      command: ["sh", "-c", "cat /etc/config/app-config && sleep 3600"]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config
    

Managing Sensitive Data with Secrets

Secrets are similar to ConfigMaps but specifically designed to hold sensitive data like passwords, OAuth tokens, or SSH keys. Kubernetes takes extra precautions to protect Secrets, such as:

• Storing them in temporary file storage on nodes
• Restricting access to users and service accounts
• Optionally encrypting them at rest

Creating Secrets

From literal values:

kubectl create secret generic db-secret \
  --from-literal=DB_HOST=mysql.example.com \
  --from-literal=DB_USER=root \
  --from-literal=DB_PASSWORD=password123
    

From a file:

# First, create files with the secret data
echo -n 'admin' > ./username.txt
echo -n 'password123' > ./password.txt

# Then create the secret from these files
kubectl create secret generic db-user-pass \
  --from-file=./username.txt \
  --from-file=./password.txt
    

Using YAML definition (base64 encoded):

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=  # base64 encoded "admin"
  password: cGFzc3dvcmQxMjM=  # base64 encoded "password123"
    

Using Secrets in Pods

As environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: mycontainer
    image: redis
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
  restartPolicy: Never
    

As a volume mount:

apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-pod
spec:
  containers:
  - name: mycontainer
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
    

Best Practices

For ConfigMaps:

• Use ConfigMaps for non-sensitive configuration data
• Break configurations into multiple ConfigMaps based on logical grouping
• Use immutable ConfigMaps for configurations that don't change (Kubernetes 1.19+)

For Secrets:

• Never commit Secrets to version control, even when base64 encoded
• Use Kubernetes RBAC to restrict access to Secrets
• Consider using external secret management systems (HashiCorp Vault, AWS Secrets Manager, etc.)
• Enable encryption at rest for Secrets in production environments
• Regularly rotate Secrets

Security Considerations

While Secrets are more secure than ConfigMaps, they're not entirely encrypted by default. For additional security:

• Enable encryption at rest for etcd (where Secrets are stored)
• Use tools like Sealed Secrets or External Secret Operators for more advanced secret management
• Limit access using Kubernetes RBAC policies
• Consider using service accounts with minimal required permissions

By properly using ConfigMaps and Secrets, you can securely manage your application configuration while maintaining the portability and flexibility that Kubernetes provides.