ConfigMap ve Secret, workload'lara konfigürasyon enjekte etmek için nasıl çalışır?

Question

IT Interview Practice · Accepted Answer

**ConfigMap** ve **Secret**, konfigürasyonu container image'larından ayırır; böylece aynı image dev, staging ve production'da farklı ayarlarla çalışır. ConfigMap'ler **hassas olmayan** konfigürasyonu tutar; Secret'lar **hassas** verileri (parolalar, token'lar, anahtarlar) tutar ve daha dikkatli işlenir.

## Fikir: konfigürasyonu image'ın dışına çıkar

```text
Image = kod (değişmez, bir kez build edilir).  Config = ortama özgü değerler.
Config'i image'a gömmek bir anti-pattern'dir (ortam başına yeniden build, secret sızıntısı).
→ Config'i ConfigMap/Secret'larda sakla, runtime'da env var veya dosya olarak enjekte et.
```

## ConfigMap: hassas olmayan ayarlar

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

## Secret: hassas değerler

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # burada düz metin; etcd'de base64 kodlanmış saklanır
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Secret'ları git'e commit etmemek için genellikle imperatif oluşturulur:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Bir Pod'a enjekte etme: env var veya dosya olarak

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # bir ConfigMap'ten tek anahtar
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # bir Secret'tan tek anahtar
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # TÜM anahtarları env var olarak içe aktar
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # config'i dosya olarak mount et
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Secret'lar hakkında önemli uyarılar

```text
⚠ Secret verisi varsayılan olarak base64-KODLANMIŞTIR, şifrelenmiş DEĞİLDİR.
  → etcd için REST HALİNDE ŞİFRELEMEYİ etkinleştir (EncryptionConfiguration).
  → Erişimi RBAC ile kısıtla (kim 'get secrets' yapabilir).
  → Harici yöneticileri (Vault, cloud Secrets Manager) veya sealed secret'ları tercih et.
  → Gerçek Secret manifest'lerini asla git'e commit etme.
Env-var config container başlangıcında BİR KEZ okunur; mount edilen dosyalar canlı güncellenebilir.
```

## Neden önemli

Konfigürasyonu koddan ayırmak çekirdek bir operasyonel pratiktir ve ConfigMap ile Secret, Kubernetes'in bunu uygulama biçimidir; bu yüzden onları anlamak elzem, orta seviye bir bilgidir. Ortama özgü ayarları bir image'a gömmek bir anti-pattern'dir — ortam başına yeniden build'i zorunlu kılar ve secret sızma riski taşır — bu yüzden Kubernetes, tek bir değişmez image tutup konfigürasyonu runtime'da enjekte etmenize olanak tanır: hassas olmayan değerler (log seviyeleri, feature flag'ler, config dosyaları) için **ConfigMap**'ler ve hassas veriler (parolalar, token'lar, anahtarlar) için **Secret**'lar. Onları tüketmenin iki yolunu bilmek — **environment variable** olarak (`configMapKeyRef`/`secretKeyRef` yoluyla tekil anahtarlar veya `envFrom` yoluyla tüm anahtarlar) ve **mount edilen dosyalar** olarak (env var'ların başlangıçta bir kez okunması, mount edilen dosyaların canlı güncellenebilmesi nüansıyla) — gerçek uygulamaları deploy etmek için günlük, pratik bir bilgidir. Aynı derecede önemli olan, birçok mühendisin tökezlediği güvenlik uyarılarını anlamaktır: Secret verisi varsayılan olarak yalnızca **base64 kodlanmıştır, şifrelenmemiştir**; bu yüzden onu gerçekten korumak, etcd için **rest halinde şifrelemeyi** etkinleştirmeyi, erişimi **RBAC** ile kısıtlamayı, Secret manifest'lerini sürüm kontrolüne commit etmekten kaçınmayı ve çoğu zaman harici bir secret yöneticisi entegre etmeyi gerektirir. Neredeyse her workload ortama özgü konfigürasyona ve kimlik bilgilerine ihtiyaç duyduğundan ve Secret'ları yanlış işlemek yaygın ve ciddi bir güvenlik açığı olduğundan, ConfigMap ve Secret'ları sağlam kavramak, Kubernetes'te uygulamaları güvenli ve doğru çalıştırmanın temelidir.

Fikir: konfigürasyonu image'ın dışına çıkar

ConfigMap: hassas olmayan ayarlar

Secret: hassas değerler

Bir Pod'a enjekte etme: env var veya dosya olarak

Secret'lar hakkında önemli uyarılar

Neden önemli

İlgili sorular