Hvordan fungerer ConfigMaps og Secrets til at indsprøjte konfiguration i workloads?

Question

IT Interview Practice · Accepted Answer

**ConfigMaps** og **Secrets** afkobler konfiguration fra container-images, så det samme image kører i dev, staging og production med forskellige indstillinger. ConfigMaps rummer **ikke-følsom** config; Secrets rummer **følsomme** data (passwords, tokens, nøgler) og håndteres mere omhyggeligt.

## Idéen: config ud af image'et

```text
Image = kode (uforanderlig, bygget én gang).  Config = værdier pr. miljø.
At bage config ind i image'et er et anti-pattern (genbyg pr. miljø, secrets lækker).
→ Gem config i ConfigMaps/Secrets, indsprøjt ved runtime som env-vars eller filer.
```

## ConfigMap: ikke-følsomme indstillinger

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

## Secret: følsomme værdier

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # klartekst her; gemmes base64-kodet i etcd
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Oprettes normalt imperativt for at undgå at committe secrets til git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Indsprøjtning i en Pod: som env-vars eller som filer

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # enkelt nøgle fra en ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # enkelt nøgle fra en Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # importér ALLE nøgler som env-vars
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # mount config som filer
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Vigtige forbehold om Secrets

```text
⚠ Secret-data er base64-KODET, ikke krypteret, som standard.
  → Aktivér ENCRYPTION AT REST for etcd (EncryptionConfiguration).
  → Begræns adgang med RBAC (hvem kan 'get secrets').
  → Foretræk eksterne managers (Vault, cloud Secrets Manager) eller sealed secrets.
  → Committ aldrig rigtige Secret-manifester til git.
Env-var-config læses ÉN gang ved container-start; mountede filer kan opdatere live.
```

## Hvorfor det betyder noget

At adskille konfiguration fra kode er en central driftspraksis, og ConfigMaps og Secrets er måden, Kubernetes implementerer det på, så det er essentiel viden på mellemniveau at forstå dem. At bage miljøspecifikke indstillinger ind i et image er et anti-pattern — det tvinger en genbygning pr. miljø og risikerer at lække secrets — så Kubernetes lader dig beholde ét enkelt uforanderligt image og indsprøjte konfiguration ved runtime: **ConfigMaps** til ikke-følsomme værdier (log levels, feature flags, config-filer) og **Secrets** til følsomme data (passwords, tokens, nøgler). At kende de to måder at forbruge dem på — som **miljøvariabler** (enkelte nøgler via `configMapKeyRef`/`secretKeyRef`, eller alle nøgler via `envFrom`) og som **mountede filer** (med den nuance, at env-vars læses én gang ved opstart, mens mountede filer kan opdatere live) — er hverdagens praktiske viden ved deployment af rigtige applikationer. Lige så vigtigt er det at forstå de sikkerhedsforbehold, der spænder ben for mange ingeniører: Secret-data er som standard kun **base64-kodet, ikke krypteret**, så at beskytte det reelt kræver, at man aktiverer **encryption at rest** for etcd, begrænser adgang med **RBAC**, undgår at committe Secret-manifester til versionsstyring og ofte integrerer en ekstern secret manager. Fordi stort set enhver workload har brug for konfiguration og credentials pr. miljø, og fordi fejlhåndtering af Secrets er et almindeligt og alvorligt sikkerhedshul, er et solidt greb om ConfigMaps og Secrets fundamentalt for at køre applikationer sikkert og korrekt på Kubernetes.

Idéen: config ud af image'et

ConfigMap: ikke-følsomme indstillinger

Secret: følsomme værdier

Indsprøjtning i en Pod: som env-vars eller som filer

Vigtige forbehold om Secrets

Hvorfor det betyder noget

Relaterede spørgsmål