IT 3300 : Virtualization

Kubernetes — ConfigMaps & Secrets

Keep config out of the image

  • The same image should run in dev, test, and prod
  • Baking config into the image breaks that
  • Kubernetes injects config at runtime via ConfigMaps and Secrets

ConfigMap

  • Non-sensitive configuration: URLs, feature flags, settings

    apiVersion: v1
    kind: ConfigMap
    metadata:
    name: app-config
    data:
    GREETING: "hello"
    LOG_LEVEL: "info"

Using a ConfigMap

  • As environment variables:

      envFrom:
    - configMapRef:
        name: app-config

  • Or mounted as files in a volume

  • Same image, different config per environment

Secret

  • Same idea, for sensitive values (passwords, tokens, keys)

    apiVersion: v1
    kind: Secret
    metadata:
    name: db-secret
    type: Opaque
    stringData:
    DB_PASSWORD: "s3cr3t"

Secrets are base64, not encrypted

  • By default Secrets are only base64-encoded in etcd
  • Anyone with cluster/etcd access can read them
  • Harden with: encryption-at-rest, RBAC, and external secret stores
    (Vault, cloud secret managers, Sealed Secrets)

Using a Secret

  • Mount as env vars or files, just like a ConfigMap:

      envFrom:
    - secretRef:
        name: db-secret

  • Never commit real secrets to git

Lab goals

  • Move an app's settings into a ConfigMap and its password into a Secret
  • Change config without rebuilding the image
  • Show that a Secret's value is trivially base64-decoded