Wie funktionieren ConfigMaps und Secrets zum Injizieren von Konfiguration in Workloads?

Question

IT Interview Practice · Accepted Answer

**ConfigMaps** und **Secrets** entkoppeln die Konfiguration von Container-Images, sodass dasselbe Image in dev, staging und production mit unterschiedlichen Einstellungen läuft. ConfigMaps enthalten **nicht-sensible** Konfiguration; Secrets enthalten **sensible** Daten (Passwörter, Tokens, Keys) und werden sorgfältiger behandelt.

## Die Idee: Config aus dem Image heraus

```text
Image = Code (immutable, einmal gebaut).  Config = umgebungsspezifische Werte.
Config ins Image einzubacken ist ein Anti-Pattern (Rebuild pro Umgebung, Secrets lecken).
→ Config in ConfigMaps/Secrets speichern, zur Laufzeit als env vars oder Dateien injizieren.
```

## ConfigMap: nicht-sensible Einstellungen

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  FEATURE_X: "true"
  app.properties: |
    timeout=30
    retries=3
```

## Secret: sensible Werte

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # hier Klartext; base64-kodiert in etcd gespeichert
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Meist imperativ erstellt, um Secrets nicht in git zu committen:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Injizieren in einen Pod: als env vars oder als Dateien

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # einzelner Key aus einer ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # einzelner Key aus einem Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # ALLE Keys als env vars importieren
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # Config als Dateien mounten
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Wichtige Vorbehalte zu Secrets

```text
⚠ Secret-Daten sind standardmäßig base64-KODIERT, nicht verschlüsselt.
  → ENCRYPTION AT REST für etcd aktivieren (EncryptionConfiguration).
  → Zugriff mit RBAC einschränken (wer darf 'get secrets').
  → Externe Manager bevorzugen (Vault, cloud Secrets Manager) oder sealed secrets.
  → Niemals echte Secret-Manifeste in git committen.
Env-var-Config wird EINMAL beim Container-Start gelesen; gemountete Dateien können sich live aktualisieren.
```

## Warum es wichtig ist

Die Trennung von Konfiguration und Code ist eine zentrale betriebliche Praxis, und ConfigMaps und Secrets sind die Art, wie Kubernetes sie umsetzt, daher ist ihr Verständnis essenzielles Wissen auf mittlerem Level. Umgebungsspezifische Einstellungen in ein Image einzubacken ist ein Anti-Pattern — es erzwingt einen Rebuild pro Umgebung und riskiert das Lecken von Secrets —, deshalb erlaubt dir Kubernetes, ein einziges immutable Image zu behalten und Konfiguration zur Laufzeit zu injizieren: **ConfigMaps** für nicht-sensible Werte (Log-Level, Feature-Flags, Konfigurationsdateien) und **Secrets** für sensible Daten (Passwörter, Tokens, Keys). Die zwei Wege, sie zu konsumieren, zu kennen — als **Umgebungsvariablen** (einzelne Keys über `configMapKeyRef`/`secretKeyRef` oder alle Keys über `envFrom`) und als **gemountete Dateien** (mit der Feinheit, dass env vars einmal beim Start gelesen werden, während gemountete Dateien sich live aktualisieren können) — ist alltägliches praktisches Wissen für das Deployen echter Anwendungen. Ebenso wichtig ist das Verständnis der Sicherheitsvorbehalte, die viele Ingenieure stolpern lassen: Secret-Daten sind standardmäßig nur **base64-kodiert, nicht verschlüsselt**, sodass echter Schutz das Aktivieren von **encryption at rest** für etcd, das Einschränken des Zugriffs mit **RBAC**, das Vermeiden des Committens von Secret-Manifesten in die Versionskontrolle und oft die Integration eines externen Secret-Managers erfordert. Weil praktisch jeder Workload umgebungsspezifische Konfiguration und Credentials braucht und weil ein Fehlumgang mit Secrets eine häufige und ernste Sicherheitslücke ist, ist ein solides Verständnis von ConfigMaps und Secrets grundlegend, um Anwendungen sicher und korrekt auf Kubernetes zu betreiben.

Die Idee: Config aus dem Image heraus

ConfigMap: nicht-sensible Einstellungen

Secret: sensible Werte

Injizieren in einen Pod: als env vars oder als Dateien

Wichtige Vorbehalte zu Secrets

Warum es wichtig ist

Ähnliche Fragen