Jak działają ConfigMapy i Secrety przy wstrzykiwaniu konfiguracji do workloadów?

Question

IT Interview Practice · Accepted Answer

**ConfigMapy** i **Secrety** oddzielają konfigurację od obrazów kontenerów, dzięki czemu ten sam obraz działa w dev, staging i produkcji z różnymi ustawieniami. ConfigMapy trzymają konfigurację **niewrażliwą**; Secrety trzymają dane **wrażliwe** (hasła, tokeny, klucze) i są traktowane ostrożniej.

## Idea: konfiguracja poza obrazem

```text
Obraz = kod (niezmienny, zbudowany raz).  Konfiguracja = wartości per środowisko.
Wpiekanie konfiguracji w obraz to antywzorzec (przebudowa per środowisko, wyciek sekretów).
→ Trzymaj konfigurację w ConfigMapach/Secretach, wstrzykuj w czasie działania jako zmienne env lub pliki.
```

## ConfigMap: ustawienia niewrażliwe

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

## Secret: wartości wrażliwe

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # tutaj tekst jawny; przechowywany zakodowany base64 w etcd
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Zwykle tworzony imperatywnie, aby nie commitować sekretów do gita:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Wstrzykiwanie do Poda: jako zmienne env lub jako pliki

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # pojedynczy klucz z ConfigMapy
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # pojedynczy klucz z Secretu
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # zaimportuj WSZYSTKIE klucze jako zmienne env
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # zamontuj konfigurację jako pliki
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Ważne zastrzeżenia dotyczące Secretów

```text
⚠ Dane Secretu są domyślnie zakodowane w base64, a NIE zaszyfrowane.
  → Włącz SZYFROWANIE W SPOCZYNKU dla etcd (EncryptionConfiguration).
  → Ogranicz dostęp za pomocą RBAC (kto może 'get secrets').
  → Preferuj zewnętrzne menedżery (Vault, chmurowy Secrets Manager) lub sealed secrets.
  → Nigdy nie commituj prawdziwych manifestów Secret do gita.
Konfiguracja przez env jest czytana RAZ przy starcie kontenera; zamontowane pliki mogą aktualizować się na żywo.
```

## Dlaczego to ważne

Oddzielenie konfiguracji od kodu to kluczowa praktyka operacyjna, a ConfigMapy i Secrety to sposób, w jaki Kubernetes ją realizuje, więc ich zrozumienie to niezbędna wiedza na poziomie middle. Wpiekanie ustawień specyficznych dla środowiska w obraz to antywzorzec — wymusza przebudowę per środowisko i grozi wyciekiem sekretów — więc Kubernetes pozwala trzymać jeden niezmienny obraz i wstrzykiwać konfigurację w czasie działania: **ConfigMapy** dla wartości niewrażliwych (poziomy logów, feature flagi, pliki konfiguracyjne) i **Secrety** dla danych wrażliwych (hasła, tokeny, klucze). Znajomość dwóch sposobów ich konsumpcji — jako **zmienne środowiskowe** (pojedyncze klucze przez `configMapKeyRef`/`secretKeyRef` lub wszystkie klucze przez `envFrom`) i jako **zamontowane pliki** (z niuansem, że zmienne env są czytane raz przy starcie, podczas gdy zamontowane pliki mogą aktualizować się na żywo) — to codzienna praktyczna wiedza przy wdrażaniu prawdziwych aplikacji. Równie ważne jest zrozumienie zastrzeżeń bezpieczeństwa, które podkładają nogę wielu inżynierom: dane Secretu są domyślnie jedynie **zakodowane w base64, a nie zaszyfrowane**, więc realna ich ochrona wymaga włączenia **szyfrowania w spoczynku** dla etcd, ograniczenia dostępu za pomocą **RBAC**, unikania commitowania manifestów Secret do systemu kontroli wersji i często integracji z zewnętrznym menedżerem sekretów. Ponieważ praktycznie każdy workload potrzebuje konfiguracji per środowisko i poświadczeń, a ponieważ złe obchodzenie się z Secretami to powszechna i poważna luka bezpieczeństwa, solidne opanowanie ConfigMap i Secretów jest fundamentalne dla bezpiecznego i poprawnego uruchamiania aplikacji na Kubernetes.

Idea: konfiguracja poza obrazem

ConfigMap: ustawienia niewrażliwe

Secret: wartości wrażliwe

Wstrzykiwanie do Poda: jako zmienne env lub jako pliki

Ważne zastrzeżenia dotyczące Secretów

Dlaczego to ważne

Powiązane pytania