Secrets and configuration

Configuration lives in ConfigMap objects, credentials in Secret objects. Both are plain Kubernetes with nothing platform-specific about them, so anything you already know applies.

Creating them

kubectl create secret generic app-secrets \
  --from-literal=DATABASE_PASSWORD='...' \
  --from-literal=API_TOKEN='...'

kubectl create configmap app-config \
  --from-literal=LOG_LEVEL=info \
  --from-file=config.yaml

A Secret is encoded, not encrypted

Base64 is not protection. Anyone who can read secrets in your namespace can read the values, and that is anyone holding your kubeconfig. Keep secrets out of Git, and out of any repository you sync with Deploying from Git, which has to be publicly readable.

Getting them into a container

Individual values as environment variables, which is the most common shape:

env:
  - name: DATABASE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: DATABASE_PASSWORD
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: LOG_LEVEL

Everything at once, where each key becomes a variable of the same name:

envFrom:
  - secretRef:
      name: app-secrets
  - configMapRef:
      name: app-config

As a file, when your application wants a config file rather than variables:

volumeMounts:
  - name: config
    mountPath: /etc/myapp/config.yaml
    subPath: config.yaml
volumes:
  - name: config
    configMap:
      name: app-config

subPath mounts the single key as a file. Without it you get a directory containing one file per key, which is usually not what you want.

Changes are not picked up automatically

Editing a ConfigMap does not restart anything. Values injected as environment variables are read once at startup, so the running container keeps the old ones until it is replaced:

kubectl rollout restart deployment/myapp

Values mounted as files do get updated in place, eventually, but only if your application watches the file.

Object storage credentials

Buckets and access keys are created in the portal. Nothing is injected into your namespace, so put the key into a secret yourself:

kubectl create secret generic s3-credentials \
  --from-literal=AWS_ACCESS_KEY_ID='<access-key>' \
  --from-literal=AWS_SECRET_ACCESS_KEY='<secret-key>'

Then reference it like any other secret, with the endpoint as plain configuration:

env:
  - name: S3_ENDPOINT
    value: "https://storage.itsh.dev"
  - name: S3_BUCKET
    value: "my-bucket"
envFrom:
  - secretRef:
      name: s3-credentials

Any S3-compatible SDK works against that endpoint.

What's next

• Your first deployment for where these fit in a manifest
• Images and pull secrets for the registry case