Kubernetes ConfigMap & Secret einfach erklärt – Konfiguration und Zugangsdaten sicher verwalten

Von /

Moderne Anwendungen benötigen Konfiguration: Datenbank-URLs, Feature-Flags, API-Endpunkte oder Zugangsdaten. In Kubernetes sollte diese Konfiguration nicht im Container-Image oder direkt im Code liegen.

Genau dafür gibt es ConfigMaps und Secrets. Sie trennen Konfiguration von Anwendungscode und machen Deployments flexibel, sicher und wartbar.

In diesem Artikel lernst du:

  • was ConfigMaps und Secrets sind
  • den Unterschied zwischen ConfigMap und Secret
  • wie sie in Pods eingebunden werden
  • YAML-Beispiele aus der Praxis
  • Best Practices und Sicherheitsaspekte

1) Was ist eine Kubernetes ConfigMap?

Eine ConfigMap ist ein Kubernetes-Objekt zur Speicherung von nicht-sensiblen Konfigurationsdaten.

Typische Inhalte einer ConfigMap:

  • Konfigurationswerte (z. B. LOG_LEVEL)
  • URLs und Endpunkte
  • Feature-Flags
  • Konfigurationsdateien

Merksatz: ConfigMap = Konfiguration ohne Geheimnisse

2) Beispiel: Einfache ConfigMap

Diese ConfigMap speichert Konfigurationswerte für eine Anwendung.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  LOG_LEVEL: info
  API_URL: https://api.example.com

kubectl apply -f configmap.yaml
kubectl get configmap app-config

3) ConfigMap in einem Pod verwenden

3.1 Als Umgebungsvariablen

envFrom:
- configMapRef:
    name: app-config

Alle Schlüssel der ConfigMap werden automatisch als Environment-Variablen verfügbar.

3.2 Als Datei (Volume)

volumes:
- name: config-volume
  configMap:
    name: app-config

volumeMounts:
- name: config-volume
  mountPath: /etc/config

Jeder Key wird dabei zu einer Datei im angegebenen Verzeichnis.

4) Was ist ein Kubernetes Secret?

Ein Secret speichert sensible Daten, die nicht im Klartext in ConfigMaps oder Code stehen sollten.

Typische Inhalte von Secrets:

  • Passwörter
  • API-Tokens
  • Datenbank-Zugangsdaten
  • Zertifikate und Schlüssel

Wichtig: Kubernetes Secrets sind standardmäßig Base64-kodiert, aber nicht automatisch verschlüsselt.

Merksatz: Secret = sensible Konfiguration

5) Beispiel: Kubernetes Secret

Dieses Secret speichert Benutzername und Passwort.

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  DB_USER: YWRtaW4=
  DB_PASSWORD: c2VjcmV0

Die Werte sind Base64-kodiert:

echo -n "admin" | base64
echo -n "secret" | base64

6) Secret im Pod verwenden

6.1 Als Umgebungsvariablen

envFrom:
- secretRef:
    name: db-secret

6.2 Als Datei

volumes:
- name: secret-volume
  secret:
    secretName: db-secret

volumeMounts:
- name: secret-volume
  mountPath: /etc/secrets
  readOnly: true

7) ConfigMap vs Secret – der direkte Vergleich

KriteriumConfigMapSecret
Typische DatenKonfigurationZugangsdaten
SensibelNeinJa
VerschlüsselungNeinOptional (at rest)
NutzungEnv / VolumeEnv / Volume

8) Best Practices für ConfigMaps & Secrets

  • Keine Passwörter in ConfigMaps speichern
  • Secrets niemals ins Git-Repository committen
  • RBAC-Zugriffe auf Secrets einschränken
  • Secrets bevorzugt als Volumes mounten
  • Verschlüsselung von Secrets im etcd aktivieren

9) Häufige Fehler & Troubleshooting

  • Pod startet nicht → ConfigMap/Secret existiert nicht
  • Falsche Werte → Base64-Encoding prüfen
  • Änderungen greifen nicht → Pod neu starten
kubectl get configmap
kubectl get secret
kubectl describe pod <pod-name>

10) Fazit

Kubernetes ConfigMaps und Secrets sind essenziell, um Anwendungen sauber, sicher und flexibel zu konfigurieren. Sie ermöglichen es, Konfiguration vom Code zu trennen und sensible Daten kontrolliert bereitzustellen.

Faustregel: ConfigMap für Konfiguration – Secret für Geheimnisse.

Nach oben scrollen