Jak fungují ConfigMapy a Secrety pro vkládání konfigurace do workloadů?

Question

IT Interview Practice · Accepted Answer

**ConfigMapy** a **Secrety** oddělují konfiguraci od imagů kontejnerů, takže stejný image běží v dev, staging i produkci s různým nastavením. ConfigMapy drží **necitlivou** konfiguraci; Secrety drží **citlivá** data (hesla, tokeny, klíče) a zachází se s nimi opatrněji.

## Myšlenka: konfigurace mimo image

```text
Image = kód (neměnný, sestavený jednou).  Config = hodnoty pro dané prostředí.
Zapéct konfiguraci do imagu je anti-pattern (přestavba na každé prostředí, únik secretů).
→ Ukládejte konfiguraci do ConfigMap/Secret, vkládejte za běhu jako env proměnné nebo soubory.
```

## ConfigMap: necitlivé nastavení

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

## Secret: citlivé hodnoty

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # zde plaintext; v etcd uloženo v base64
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Obvykle se vytváří imperativně, aby se secrety nekomitovaly do gitu:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Vkládání do Podu: jako env proměnné nebo soubory

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # jeden klíč z ConfigMapy
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # jeden klíč ze Secretu
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # import VŠECH klíčů jako env proměnných
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # připojí konfiguraci jako soubory
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Důležité výhrady k Secretům

```text
⚠ Data Secretu jsou ve výchozím stavu jen v base64 (ENCODED), ne šifrovaná.
  → Zapněte ŠIFROVÁNÍ V KLIDU (encryption at rest) pro etcd (EncryptionConfiguration).
  → Omezte přístup pomocí RBAC (kdo smí 'get secrets').
  → Preferujte externí správce (Vault, cloud Secrets Manager) nebo sealed secrets.
  → Nikdy nekomitujte skutečné manifesty Secretů do gitu.
Env-var konfigurace se čte JEDNOU při startu kontejneru; připojené soubory se mohou aktualizovat za běhu.
```

## Proč je to důležité

Oddělení konfigurace od kódu je základní provozní praxe a ConfigMapy a Secrety jsou způsob, jak to Kubernetes realizuje, takže jejich pochopení je nezbytná znalost na střední úrovni. Zapéct nastavení specifická pro prostředí do imagu je anti-pattern — vynucuje přestavbu na každé prostředí a hrozí únikem secretů — proto vám Kubernetes umožňuje ponechat jediný neměnný image a vkládat konfiguraci za běhu: **ConfigMapy** pro necitlivé hodnoty (úrovně logování, feature flags, konfigurační soubory) a **Secrety** pro citlivá data (hesla, tokeny, klíče). Znát dva způsoby jejich konzumace — jako **proměnné prostředí** (jednotlivé klíče přes `configMapKeyRef`/`secretKeyRef` nebo všechny klíče přes `envFrom`) a jako **připojené soubory** (s nuancí, že env proměnné se čtou jednou při startu, zatímco připojené soubory se mohou aktualizovat za běhu) — je každodenní praktická znalost pro nasazování reálných aplikací. Stejně důležité je pochopit bezpečnostní výhrady, o které mnoho inženýrů zakopne: data Secretu jsou ve výchozím stavu jen **v base64, ne šifrovaná**, takže jejich skutečná ochrana vyžaduje zapnout **šifrování v klidu (encryption at rest)** pro etcd, omezit přístup pomocí **RBAC**, nekomitovat manifesty Secretů do verzovacího systému a často integrovat externího správce secretů. Protože prakticky každý workload potřebuje konfiguraci a přihlašovací údaje pro dané prostředí a protože špatné zacházení se Secrety je běžná a vážná bezpečnostní mezera, solidní pochopení ConfigMap a Secretů je základem pro bezpečný a správný provoz aplikací na Kubernetes.

Myšlenka: konfigurace mimo image

ConfigMap: necitlivé nastavení

Secret: citlivé hodnoty

Vkládání do Podu: jako env proměnné nebo soubory

Důležité výhrady k Secretům

Proč je to důležité

Související otázky