Hoe werken ConfigMaps en Secrets voor het injecteren van configuratie in workloads?

Question

IT Interview Practice · Accepted Answer

**ConfigMaps** en **Secrets** ontkoppelen configuratie van container images, zodat dezelfde image in dev, staging en productie draait met verschillende instellingen. ConfigMaps bevatten **niet-gevoelige** config; Secrets bevatten **gevoelige** data (wachtwoorden, tokens, keys) en worden zorgvuldiger behandeld.

## Het idee: config buiten de image

```text
Image = code (immutable, één keer gebouwd).  Config = waarden per omgeving.
Config in de image bakken is een anti-pattern (herbouw per omgeving, secrets lekken).
→ Bewaar config in ConfigMaps/Secrets, injecteer at runtime als env vars of bestanden.
```

## ConfigMap: niet-gevoelige instellingen

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

## Secret: gevoelige waarden

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

```bash
# Meestal imperatief aangemaakt om te voorkomen dat secrets in git worden gecommit:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Injecteren in een Pod: als env vars of als bestanden

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # één key uit een ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # één key uit een Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # importeer ALLE keys als env vars
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # mount config als bestanden
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Belangrijke kanttekeningen bij Secrets

```text
⚠ Secret-data is standaard base64-ENCODED, niet encrypted.
  → Zet ENCRYPTION AT REST aan voor etcd (EncryptionConfiguration).
  → Beperk toegang met RBAC (wie mag 'get secrets').
  → Geef de voorkeur aan externe managers (Vault, cloud Secrets Manager) of sealed secrets.
  → Commit nooit echte Secret-manifests naar git.
Env-var-config wordt ÉÉN keer gelezen bij het starten van de container; gemounte bestanden kunnen live updaten.
```

## Waarom het belangrijk is

Configuratie scheiden van code is een operationele kernpraktijk, en ConfigMaps en Secrets zijn hoe Kubernetes dat implementeert, dus ze begrijpen is essentiële kennis op medior-niveau. Omgevingsspecifieke instellingen in een image bakken is een anti-pattern — het dwingt tot een herbouw per omgeving en riskeert het lekken van secrets — dus met Kubernetes kun je één immutable image behouden en configuratie at runtime injecteren: **ConfigMaps** voor niet-gevoelige waarden (log levels, feature flags, config-bestanden) en **Secrets** voor gevoelige data (wachtwoorden, tokens, keys). De twee manieren om ze te consumeren kennen — als **environment variables** (losse keys via `configMapKeyRef`/`secretKeyRef`, of alle keys via `envFrom`) en als **gemounte bestanden** (met de nuance dat env vars één keer bij het opstarten worden gelezen terwijl gemounte bestanden live kunnen updaten) — is alledaagse praktische kennis voor het deployen van echte applicaties. Even belangrijk is het begrijpen van de beveiligingskanttekeningen waar veel engineers over struikelen: Secret-data is standaard alleen **base64-encoded, niet encrypted**, dus om het echt te beschermen is het nodig om **encryption at rest** voor etcd aan te zetten, toegang te beperken met **RBAC**, te vermijden dat Secret-manifests in versiebeheer worden gecommit, en vaak een externe secret manager te integreren. Omdat vrijwel elke workload configuratie en credentials per omgeving nodig heeft, en omdat het verkeerd omgaan met Secrets een veelvoorkomend en ernstig beveiligingsgat is, is een gedegen begrip van ConfigMaps en Secrets fundamenteel om applicaties veilig en correct op Kubernetes te draaien.

Het idee: config buiten de image

ConfigMap: niet-gevoelige instellingen

Secret: gevoelige waarden

Injecteren in een Pod: als env vars of als bestanden

Belangrijke kanttekeningen bij Secrets

Waarom het belangrijk is

Gerelateerde vragen