Come funzionano ConfigMap e Secret per iniettare la configurazione nei workload?

Question

IT Interview Practice · Accepted Answer

**ConfigMap** e **Secret** disaccoppiano la configurazione dalle immagini dei container, così la stessa immagine gira in dev, staging e produzione con impostazioni diverse. Le ConfigMap contengono configurazione **non sensibile**; i Secret contengono dati **sensibili** (password, token, chiavi) e vengono gestiti con maggiore cura.

## L'idea: la config fuori dall'immagine

```text
Image = code (immutable, built once).  Config = per-environment values.
Baking config into the image is an anti-pattern (rebuild per env, secrets leak).
→ Store config in ConfigMaps/Secrets, inject at runtime as env vars or files.
```

## ConfigMap: impostazioni non sensibili

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

## Secret: valori sensibili

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

```bash
# Usually created imperatively to avoid committing secrets to git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Iniezione in un Pod: come env var o come file

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # single key from a ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # single key from a Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # import ALL keys as env vars
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # mount config as files
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Avvertenze importanti sui Secret

```text
⚠ Secret data is base64-ENCODED, not encrypted, by default.
  → Enable ENCRYPTION AT REST for etcd (EncryptionConfiguration).
  → Restrict access with RBAC (who can 'get secrets').
  → Prefer external managers (Vault, cloud Secrets Manager) or sealed secrets.
  → Never commit real Secret manifests to git.
Env-var config is read ONCE at container start; mounted files can update live.
```

## Perché è importante

Separare la configurazione dal codice è una pratica operativa fondamentale, e le ConfigMap e i Secret sono il modo in cui Kubernetes la implementa, quindi capirli è una conoscenza essenziale di livello middle. Inserire nell'immagine impostazioni specifiche dell'ambiente è un anti-pattern — costringe a una ricompilazione per ogni ambiente e rischia di far trapelare i secret — perciò Kubernetes ti permette di mantenere una singola immagine immutabile e iniettare la configurazione a runtime: **ConfigMap** per valori non sensibili (livelli di log, feature flag, file di configurazione) e **Secret** per dati sensibili (password, token, chiavi). Conoscere i due modi di consumarli — come **variabili d'ambiente** (chiavi singole tramite `configMapKeyRef`/`secretKeyRef`, o tutte le chiavi tramite `envFrom`) e come **file montati** (con la sfumatura che le env var vengono lette una sola volta all'avvio mentre i file montati possono aggiornarsi a caldo) — è una conoscenza pratica quotidiana per distribuire applicazioni reali. Altrettanto importante è capire le avvertenze di sicurezza che fanno inciampare molti ingegneri: per default i dati dei Secret sono solo **codificati in base64, non cifrati**, quindi proteggerli davvero richiede di abilitare l'**encryption at rest** per etcd, restringere l'accesso con **RBAC**, evitare di committare i manifest dei Secret nel version control e spesso integrare un secret manager esterno. Poiché praticamente ogni workload ha bisogno di configurazione e credenziali specifiche per ambiente, e poiché gestire male i Secret è una lacuna di sicurezza comune e grave, una solida padronanza di ConfigMap e Secret è fondamentale per far girare le applicazioni in modo sicuro e corretto su Kubernetes.

L'idea: la config fuori dall'immagine

ConfigMap: impostazioni non sensibili

Secret: valori sensibili

Iniezione in un Pod: come env var o come file

Avvertenze importanti sui Secret

Perché è importante

Domande correlate