Kako ConfigMaps in Secrets delujejo za vbrizgavanje konfiguracije v delovne obremenitve?

Question

IT Interview Practice · Accepted Answer

**ConfigMaps** in **Secrets** ločijo konfiguracijo od slik vsebnikov (container images), tako da ista slika teče v dev, staging in produkciji z različnimi nastavitvami. ConfigMaps hranijo **neobčutljivo** konfiguracijo; Secrets hranijo **občutljive** podatke (gesla, žetone, ključe) in se obravnavajo bolj previdno.

## Ideja: konfiguracija zunaj slike

```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: neobčutljive nastavitve

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

## Secret: občutljive vrednosti

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # tu odprto besedilo; v etcd shranjeno kot base64
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Običajno ustvarjeno imperativno, da se skrivnosti ne commitajo v git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Vbrizgavanje v Pod: kot env spremenljivke ali kot datoteke

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # en ključ iz ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # en ključ iz Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # uvozi VSE ključe kot env spremenljivke
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # priklopi konfiguracijo kot datoteke
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Pomembna opozorila glede Secrets

```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.
```

## Zakaj je to pomembno

Ločevanje konfiguracije od kode je jedrna operativna praksa, ConfigMaps in Secrets pa sta način, kako jo Kubernetes uresničuje, zato je njuno razumevanje bistveno znanje srednje ravni. Vpeka nastavitev, specifičnih za okolje, v sliko je anti-vzorec — sili v ponovno gradnjo za vsako okolje in tvega uhajanje skrivnosti — zato vam Kubernetes omogoča, da obdržite eno samo nespremenljivo sliko in vbrizgate konfiguracijo med izvajanjem: **ConfigMaps** za neobčutljive vrednosti (ravni dnevnika, zastavice funkcij, konfiguracijske datoteke) in **Secrets** za občutljive podatke (gesla, žetoni, ključi). Poznavanje obeh načinov uporabe — kot **spremenljivke okolja** (posamezni ključi prek `configMapKeyRef`/`secretKeyRef` ali vsi ključi prek `envFrom`) in kot **priklopljene datoteke** (z niansom, da se env spremenljivke preberejo enkrat ob zagonu, priklopljene datoteke pa se lahko posodabljajo v živo) — je vsakdanje praktično znanje za nameščanje resničnih aplikacij. Enako pomembno je razumevanje varnostnih opozoril, ob katera se spotakne veliko inženirjev: podatki Secret so privzeto le **base64-kodirani, ne šifrirani**, zato njihova resnična zaščita zahteva omogočanje **šifriranja v mirovanju (encryption at rest)** za etcd, omejevanje dostopa z **RBAC**, izogibanje commitanju manifestov Secret v verzioniranje in pogosto integracijo zunanjega upravitelja skrivnosti. Ker skoraj vsaka delovna obremenitev potrebuje konfiguracijo in poverilnice po okoljih in ker je napačno ravnanje s Secrets pogosta in resna varnostna vrzel, je trdno razumevanje ConfigMaps in Secrets temeljno za varno in pravilno poganjanje aplikacij na Kubernetesu.

Ideja: konfiguracija zunaj slike

ConfigMap: neobčutljive nastavitve

Secret: občutljive vrednosti

Vbrizgavanje v Pod: kot env spremenljivke ali kot datoteke

Pomembna opozorila glede Secrets

Zakaj je to pomembno

Povezana vprašanja