Configuring Pods

Configuration for pods can provided as environment variables or files by creating config maps and secrets. Both are documents containing key/value data. Config maps are for non-sensitive data. Secrets are for sensitive data.

Config Maps

Config maps are key/value pairs of string data which can be mounted in a pod as environment variables or as a file.

Environment Variables

You can define environment variables as key/value pairs in a config map:

apiVersion: v1
kind: ConfigMap
metadata:
  name: example
  namespace: default
data:
  APPLICATION_HOST: example.com
  LANG: en_US.UTF-8
  PIDFILE: /tmp/server.pid
  PORT: "3000"
  RACK_ENV: production
  RAILS_ENV: production
  RAILS_LOG_TO_STDOUT: "true"
  RAILS_SERVE_STATIC_FILES: "true"

You can then mount them in pods by modifying your deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-web
  namespace: default
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: example
  template:
    metadata:
      labels:
        app.kubernetes.io/name: example
    spec:
      containers:
      - name: main
        envFrom:
        - configMapRef:
            name: example

Files

You can also store a file in a config map and mount it:

apiVersion: v1
kind: ConfigMap
metadata:
  name: sidekiq
  namespace: default
data:
  sidekiq.yml: |
    :verbose: false
    :concurrency: 10
    :timeout: 25

You can then mount them in pods by modifying your deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-web
  namespace: default
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: example
  template:
    metadata:
      labels:
        app.kubernetes.io/name: example
    spec:

      # Define your config map as a volume
      volumes:
      - name: sidekiq
        configMap:
          name: sidekiq

      # Mount the volume in your container
      containers:
      - name: main
        volumeMounts:
        - name: sidekiq
          mountPath: /app/config/sidekiq.yml
          subPath: sidekiq.yml

Secrets

Secrets are functionally identical to config maps, but they can be configured with stricter permissions due to their sensitive nature. Secret manifests are not committed to Git.

The best way to manage secrets on AWS is to store the secret value using AWS Secrets Manager and synchronize the secret to your cluster using the Kubernetes Secret Storage provider.

On AWS, you can synchronize a secret to your cluster by creating a secret provider class:

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
   name: example
spec:
  provider: aws
  secretObjects:
  - secretName: example
    type: Opaque
    data:
    - key: SECRET_KEY_BASE
      objectName: SECRET_KEY_BASE
  parameters:
    objects: |
      - objectName: my-secrets-manager-secret
        objectType: secretsmanager
        jmesPath:
        - path: SECRET_KEY_BASE
          objectAlias: SECRET_KEY_BASE

Once a secret provider class is created, you can mount them similarly to config maps:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-web
  namespace: default
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: example
  template:
    metadata:
      labels:
        app.kubernetes.io/name: example
    spec:

      # Define your secret as a volume using the secrets storage provider
      volumes:
      - name: example
        csi:
          driver: secrets-store.csi.k8s.io
          readOnly: true
          volumeAttributes:
            secretProviderClass: example

      containers:
      - name: main

        # Mount a secret as environment variables
        envFrom:
        - secretRef:
            name: example

        # Or mount the volume in your container
        volumeMounts:
        - name: application
          mountPath: /app/config/application.yml
          subPath: application.yml