Kubernetes ConfigMap und Secret in Pods laden

Konfiguration gehoert nicht ins Container Image. Das ist einer der wichtigsten Grundsaetze fuer containerisierte Anwendungen. Kubernetes bietet dafuer ConfigMaps (fuer nicht-sensible Daten) und Secrets (fuer Passwoerter, Tokens, Zertifikate). Aber wie kommen die Daten in den Pod? Es gibt vier Methoden -- jede mit eigenen Vor- und Nachteilen.

TL;DR

• env valueFrom: Einzelne Werte als Umgebungsvariablen. Gut fuer wenige, gezielte Werte.
• envFrom: Alle Key-Value-Paare einer ConfigMap/Secret als Umgebungsvariablen. Schnell, aber unuebersichtlich bei vielen Keys.
• Volume Mount: ConfigMap/Secret als Dateien im Container. Ideal fuer Konfigurationsdateien. Unterstuetzt Hot-Reload.
• Projected Volume: Mehrere Quellen in einem Mount-Pfad kombinieren.

ConfigMap und Secret erstellen

Zuerst brauchen Sie die Objekte im Cluster. Es gibt mehrere Wege:

# ConfigMap aus Literalen
kubectl create configmap app-config \
  --from-literal=DATABASE_HOST=postgres.default.svc \
  --from-literal=LOG_LEVEL=info \
  --from-literal=MAX_CONNECTIONS=100

# ConfigMap aus einer Datei
kubectl create configmap nginx-config --from-file=nginx.conf

# Secret aus Literalen (werden automatisch base64-kodiert)
kubectl create secret generic db-credentials \
  --from-literal=DB_USER=admin \
  --from-literal=DB_PASSWORD='s3cur3-p4ss!'

# Secret fuer Docker Registry
kubectl create secret docker-registry regcred \
  --docker-server=registry.example.com \
  --docker-username=deploy \
  --docker-password=token123

Pruefen Sie den Inhalt:

# ConfigMap anzeigen
kubectl get configmap app-config -o yaml

# Secret entschluesseln
kubectl get secret db-credentials -o jsonpath='{.data.DB_PASSWORD}' | base64 -d

Methode 1: env mit valueFrom

Sie referenzieren einzelne Keys aus einer ConfigMap oder einem Secret als Umgebungsvariablen:

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: myapp:2.0
    env:
    - name: DATABASE_HOST           # Name der Env-Variable im Container
      valueFrom:
        configMapKeyRef:
          name: app-config           # Name der ConfigMap
          key: DATABASE_HOST         # Key in der ConfigMap
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: DB_PASSWORD
    - name: LOG_LEVEL
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: LOG_LEVEL
          optional: true             # Pod startet auch ohne diesen Key

Vorteile: Volle Kontrolle ueber Variablennamen. Sie koennen den Key in der ConfigMap anders benennen als die Env-Variable im Container.

Nachteile: Viel YAML bei vielen Variablen. Jeder neue Key erfordert eine Deployment-Aenderung.

Methode 2: envFrom

Alle Key-Value-Paare einer ConfigMap oder eines Secrets werden auf einmal als Umgebungsvariablen geladen:

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: myapp:2.0
    envFrom:
    - configMapRef:
        name: app-config
      prefix: APP_                   # Optional: Prefix fuer alle Keys
    - secretRef:
        name: db-credentials

Mit dem prefix werden aus DATABASE_HOST und LOG_LEVEL die Variablen APP_DATABASE_HOST und APP_LOG_LEVEL. Das verhindert Namenskollisionen, wenn Sie mehrere ConfigMaps laden.

Vorteile: Wenig YAML. Neue Keys in der ConfigMap sind automatisch verfuegbar (nach Pod-Neustart).

Nachteile: Sie sehen in der Deployment-YAML nicht, welche Variablen gesetzt werden. Keys, die keine gueltigen Env-Variablen-Namen sind (z.B. mit Bindestrich), werden uebersprungen.

Methode 3: Volume Mount

ConfigMaps und Secrets koennen als Dateien in den Container gemountet werden. Jeder Key wird zu einer Datei, der Value zum Dateiinhalt.

Erstellen Sie zuerst eine ConfigMap mit einer kompletten Konfigurationsdatei:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:
  nginx.conf: |
    server {
      listen 80;
      server_name example.com;
      location / {
        proxy_pass http://backend:8080;
        proxy_set_header Host $host;
      }
    }
  custom-errors.conf: |
    error_page 404 /404.html;

Mounten Sie die ConfigMap als Volume:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    volumeMounts:
    - name: config-volume
      mountPath: /etc/nginx/conf.d    # Verzeichnis im Container
      readOnly: true
  volumes:
  - name: config-volume
    configMap:
      name: nginx-config

Das Ergebnis im Container:

/etc/nginx/conf.d/
  nginx.conf          -> Inhalt aus data.nginx.conf
  custom-errors.conf  -> Inhalt aus data.custom-errors.conf

Einzelne Keys mounten

Wenn Sie nur bestimmte Keys als Dateien brauchen:

  volumes:
  - name: config-volume
    configMap:
      name: nginx-config
      items:
      - key: nginx.conf
        path: default.conf          # Dateiname im Container

Hot-Reload: Aenderungen ohne Neustart

Volume-gemountete ConfigMaps werden automatisch aktualisiert, wenn Sie die ConfigMap aendern -- typischerweise innerhalb von 30-60 Sekunden. Ihre Anwendung muss die Dateien allerdings selbst neu laden (z.B. nginx mit nginx -s reload).

Umgebungsvariablen (Methode 1 und 2) werden nicht aktualisiert. Der Pod muss neugestartet werden.

Methode 4: Projected Volume

Projected Volumes kombinieren mehrere Quellen in einem Mount-Pfad:

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: myapp:2.0
    volumeMounts:
    - name: all-config
      mountPath: /etc/app-config
      readOnly: true
  volumes:
  - name: all-config
    projected:
      sources:
      - configMap:
          name: app-config
          items:
          - key: DATABASE_HOST
            path: database-host
      - secret:
          name: db-credentials
          items:
          - key: DB_PASSWORD
            path: database-password
      - serviceAccountToken:
          path: token
          expirationSeconds: 3600
          audience: vault

Projected Volumes sind besonders nuetzlich, wenn Sie ServiceAccount-Tokens mit Konfigurationsdaten kombinieren muessen -- etwa fuer Vault-Integration oder Workload Identity.

Secrets: Sicherheitshinweise

Kubernetes Secrets sind base64-kodiert, nicht verschluesselt. Jeder mit RBAC-Zugriff auf Secrets im Namespace kann sie lesen. Fuer echte Sicherheit:

# Encryption at Rest aktivieren (in der API-Server-Konfiguration)
# Oder: External Secrets Operator nutzen
# Oder: Sealed Secrets von Bitnami

# Pruefen, ob Encryption at Rest aktiv ist
kubectl get apiservices | grep encryption

Mounten Sie Secrets als Volume mit readOnly: true und setzen Sie restriktive Dateiberechtigungen:

  volumes:
  - name: secret-volume
    secret:
      secretName: db-credentials
      defaultMode: 0400    # Nur Lesen, nur Owner

FAQ

Wann envFrom, wann einzelne env-Eintraege?

Nutzen Sie envFrom, wenn alle Keys einer ConfigMap im Container verfuegbar sein sollen und die Benamung passt. Nutzen Sie env mit valueFrom, wenn Sie Keys umbenennen muessen oder nur bestimmte Werte brauchen.

Aendert sich die Umgebungsvariable, wenn ich die ConfigMap update?

Nein. Umgebungsvariablen werden beim Pod-Start gesetzt und aendern sich nicht. Sie muessen den Pod neustarten (z.B. per kubectl rollout restart deployment). Volume Mounts hingegen werden automatisch aktualisiert.

Kann ich eine ConfigMap in mehreren Namespaces nutzen?

Nein, ConfigMaps und Secrets sind namespace-scoped. Sie muessen sie in jedem Namespace erstellen. Tools wie Replicator oder der ClusterSecret-Controller koennen das automatisieren.

Was passiert, wenn die referenzierte ConfigMap nicht existiert?

Der Pod startet nicht und bleibt im Status CreateContainerConfigError. Es sei denn, Sie setzen optional: true bei der Referenz -- dann startet der Pod ohne die Variable.

Wie gross darf eine ConfigMap sein?

Maximal 1 MiB. Fuer groessere Konfigurationsdateien muessen Sie andere Loesungen finden (z.B. Init Container, der die Datei herunterlaed).

Praxis-Tipp: Starten Sie mit envFrom fuer einfache Key-Value-Konfiguration und Volume Mounts fuer komplette Konfigurationsdateien. Vermeiden Sie es, Secrets als Umgebungsvariablen zu setzen -- sie tauchen in kubectl describe pod und in Crash Dumps auf. Volume Mounts sind sicherer.

Weiterführende Artikel:

• Kubernetes Secrets mit HashiCorp Vault verwalten
• Sealed Secrets Anleitung: Kubernetes Secrets in Git