Cum funcționează ConfigMaps și Secrets pentru injectarea configurației în workload-uri?

Question

IT Interview Practice · Accepted Answer

**ConfigMaps** și **Secrets** decuplează configurația de imaginile de container, astfel încât aceeași imagine rulează în dev, staging și producție cu setări diferite. ConfigMaps dețin configurație **nesensibilă**; Secrets dețin date **sensibile** (parole, token-uri, chei) și sunt tratate mai atent.

## Ideea: configurația în afara imaginii

```text
Imagine = cod (imutabilă, construită o dată).  Config = valori per mediu.
Introducerea configurației în imagine este un anti-pattern (rebuild per mediu, secretele se scurg).
→ Stochează configurația în ConfigMaps/Secrets, injecteaz-o la runtime ca env vars sau fișiere.
```

## ConfigMap: setări nesensibile

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

## Secret: valori sensibile

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # text în clar aici; stocat codificat base64 în etcd
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# De obicei creat imperativ pentru a evita comiterea secretelor în git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Injectarea într-un Pod: ca env vars sau ca fișiere

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # o singură cheie dintr-un ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # o singură cheie dintr-un Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # importă TOATE cheile ca env vars
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # montează configurația ca fișiere
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Avertismente importante despre Secrets

```text
⚠ Datele din Secret sunt CODIFICATE base64, nu criptate, în mod implicit.
  → Activează CRIPTAREA LA REPAUS (encryption at rest) pentru etcd (EncryptionConfiguration).
  → Restricționează accesul cu RBAC (cine poate 'get secrets').
  → Preferă managere externe (Vault, cloud Secrets Manager) sau sealed secrets.
  → Nu comite niciodată manifeste Secret reale în git.
Config-ul din env vars este citit O DATĂ la pornirea containerului; fișierele montate se pot actualiza live.
```

## De ce contează

Separarea configurației de cod este o practică operațională de bază, iar ConfigMaps și Secrets sunt modul în care Kubernetes o implementează, așa că înțelegerea lor este cunoaștere esențială de nivel middle. Introducerea setărilor specifice mediului într-o imagine este un anti-pattern — forțează un rebuild per mediu și riscă scurgerea secretelor — așa că Kubernetes îți permite să păstrezi o singură imagine imutabilă și să injectezi configurație la runtime: **ConfigMaps** pentru valori nesensibile (nivele de log, feature flags, fișiere de config) și **Secrets** pentru date sensibile (parole, token-uri, chei). Cunoașterea celor două moduri de a le consuma — ca **variabile de mediu** (chei individuale prin `configMapKeyRef`/`secretKeyRef`, sau toate cheile prin `envFrom`) și ca **fișiere montate** (cu nuanța că env vars sunt citite o dată la pornire, în timp ce fișierele montate se pot actualiza live) — este cunoaștere practică de zi cu zi pentru deployarea aplicațiilor reale. La fel de importantă este înțelegerea avertismentelor de securitate care încurcă mulți ingineri: datele din Secret sunt doar **codificate base64, nu criptate**, în mod implicit, deci protejarea lor reală necesită activarea **criptării la repaus** pentru etcd, restricționarea accesului cu **RBAC**, evitarea comiterii manifestelor Secret în controlul versiunilor și adesea integrarea unui manager extern de secrete. Deoarece practic orice workload are nevoie de configurație și credențiale per mediu, și deoarece gestionarea greșită a Secrets este o breșă de securitate comună și serioasă, o stăpânire solidă a ConfigMaps și Secrets este fundamentală pentru a rula aplicații în siguranță și corect pe Kubernetes.

Ideea: configurația în afara imaginii

ConfigMap: setări nesensibile

Secret: valori sensibile

Injectarea într-un Pod: ca env vars sau ca fișiere

Avertismente importante despre Secrets

De ce contează

Întrebări conexe