Kaip ConfigMap'ai ir Secret'ai veikia įterpiant konfigūraciją į workload'us?

Question

IT Interview Practice · Accepted Answer

**ConfigMap'ai** ir **Secret'ai** atsieja konfigūraciją nuo konteinerių image'ų, tad tas pats image veikia dev, staging ir production aplinkose su skirtingais nustatymais. ConfigMap'ai laiko **nejautrią** konfigūraciją; Secret'ai laiko **jautrius** duomenis (slaptažodžius, token'us, raktus) ir tvarkomi atsargiau.

## Idėja: konfigūracija už image ribų

```text
Image = kodas (nekintamas, sukurtas kartą).  Config = kiekvienos aplinkos reikšmės.
Config'o įkepimas į image yra anti-pattern (perkūrimas kiekvienai aplinkai, secret'ai nuteka).
→ Laikykite config'ą ConfigMap'uose/Secret'uose, įterpkite vykdymo metu kaip env kintamuosius ar failus.
```

## ConfigMap: nejautrūs nustatymai

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

## Secret: jautrios reikšmės

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # čia grynas tekstas; etcd saugoma base64 užkoduota
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Paprastai kuriama imperatyviai, kad secret'ai nepatektų į git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Įterpimas į Pod'ą: kaip env kintamieji arba failai

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # vienas raktas iš ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # vienas raktas iš Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # importuoti VISUS raktus kaip env kintamuosius
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # prijungti config'ą kaip failus
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Svarbios pastabos apie Secret'us

```text
⚠ Secret duomenys pagal numatymą yra base64 UŽKODUOTI, o ne šifruoti.
  → Įjunkite ENCRYPTION AT REST etcd'ui (EncryptionConfiguration).
  → Ribokite priėjimą su RBAC (kas gali 'get secrets').
  → Rinkitės išorinius valdiklius (Vault, cloud Secrets Manager) arba sealed secrets.
  → Niekada nekelkite tikrų Secret manifest'ų į git.
Env-kintamųjų config skaitomas VIENĄ kartą konteinerio starte; prijungti failai gali atsinaujinti gyvai.
```

## Kodėl tai svarbu

Konfigūracijos atskyrimas nuo kodo yra esminė eksploatacinė praktika, o ConfigMap'ai ir Secret'ai yra tai, kaip Kubernetes ją įgyvendina, tad juos suprasti yra esminė middle-lygio žinia. Nuo aplinkos priklausančių nustatymų įkepimas į image yra anti-pattern — jis verčia perkurti image kiekvienai aplinkai ir kelia riziką nutekinti secret'us — tad Kubernetes leidžia laikyti vieną nekintamą image ir įterpti konfigūraciją vykdymo metu: **ConfigMap'ai** nejautrioms reikšmėms (log lygiai, feature flag'ai, config failai) ir **Secret'ai** jautriems duomenims (slaptažodžiai, token'ai, raktai). Žinojimas dviejų būdų juos naudoti — kaip **aplinkos kintamuosius** (atskiri raktai per `configMapKeyRef`/`secretKeyRef` arba visi raktai per `envFrom`) ir kaip **prijungtus failus** (su niuansu, kad env kintamieji skaitomi kartą starte, o prijungti failai gali atsinaujinti gyvai) — yra kasdienė praktinė žinia diegiant realias aplikacijas. Ne mažiau svarbu suprasti saugumo pastabas, ant kurių užkliūva daugelis inžinierių: Secret duomenys pagal numatymą tik **base64 užkoduoti, o ne šifruoti**, tad tikram jų apsaugojimui reikia įjungti **encryption at rest** etcd'ui, riboti priėjimą su **RBAC**, vengti kelti Secret manifest'us į versijų kontrolę ir dažnai integruoti išorinį secret valdiklį. Kadangi praktiškai kiekvienam workload'ui reikia nuo aplinkos priklausančios konfigūracijos ir prisijungimo duomenų, o netinkamas Secret'ų tvarkymas yra dažna ir rimta saugumo spraga, tvirtas ConfigMap'ų ir Secret'ų suvokimas yra pamatinis saugiai ir teisingai paleisti aplikacijas Kubernetes'e.

Idėja: konfigūracija už image ribų

ConfigMap: nejautrūs nustatymai

Secret: jautrios reikšmės

Įterpimas į Pod'ą: kaip env kintamieji arba failai

Svarbios pastabos apie Secret'us

Kodėl tai svarbu

Susiję klausimai