workloads में configuration inject करने के लिए ConfigMaps और Secrets कैसे काम करते हैं?

Question

IT Interview Practice · Accepted Answer

**ConfigMaps** और **Secrets** configuration को container images से अलग करते हैं, ताकि वही image dev, staging और production में अलग-अलग settings के साथ चले। ConfigMaps **गैर-संवेदनशील** config रखते हैं; Secrets **संवेदनशील** data (passwords, tokens, keys) रखते हैं और उन्हें अधिक सावधानी से संभाला जाता है।

## विचार: config को image से बाहर रखना

```text
Image = code (अपरिवर्तनीय, एक बार बनाया गया)।  Config = प्रति-environment मान।
config को image में पकाना एक anti-pattern है (प्रति env rebuild, secrets लीक)।
→ config को ConfigMaps/Secrets में रखें, runtime पर env vars या files के रूप में inject करें।
```

## ConfigMap: गैर-संवेदनशील settings

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

## Secret: संवेदनशील मान

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # यहाँ plaintext; etcd में base64-encoded संग्रहीत
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# आमतौर पर imperatively बनाया जाता है ताकि secrets git में commit न हों:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## एक Pod में inject करना: env vars या files के रूप में

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # ConfigMap से एकल key
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # Secret से एकल key
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # सभी keys को env vars के रूप में import करें
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # config को files के रूप में mount करें
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Secrets के बारे में ज़रूरी चेतावनियाँ

```text
⚠ Secret data default रूप से base64-ENCODED होता है, encrypted नहीं।
  → etcd के लिए ENCRYPTION AT REST सक्षम करें (EncryptionConfiguration)।
  → RBAC से पहुँच सीमित करें (कौन 'get secrets' कर सकता है)।
  → बाहरी managers (Vault, cloud Secrets Manager) या sealed secrets को प्राथमिकता दें।
  → असली Secret manifests कभी git में commit न करें।
Env-var config container शुरू होने पर एक बार पढ़ा जाता है; mounted files live अपडेट हो सकती हैं।
```

## यह क्यों महत्वपूर्ण है

configuration को code से अलग करना एक मूल operational अभ्यास है, और ConfigMaps तथा Secrets ही वह तरीका हैं जिससे Kubernetes इसे लागू करता है, इसलिए उन्हें समझना आवश्यक मध्य-स्तरीय ज्ञान है। environment-विशिष्ट settings को image में पकाना एक anti-pattern है — यह प्रति environment rebuild को मजबूर करता है और secrets लीक होने का जोखिम रखता है — इसलिए Kubernetes आपको एक अकेला अपरिवर्तनीय image रखने और runtime पर configuration inject करने देता है: गैर-संवेदनशील मानों (log levels, feature flags, config files) के लिए **ConfigMaps** और संवेदनशील data (passwords, tokens, keys) के लिए **Secrets**। इन्हें उपभोग करने के दो तरीके जानना — **environment variables** के रूप में (`configMapKeyRef`/`secretKeyRef` के ज़रिए एकल keys, या `envFrom` के ज़रिए सभी keys) और **mounted files** के रूप में (इस बारीकी के साथ कि env vars शुरुआत में एक बार पढ़े जाते हैं जबकि mounted files live अपडेट हो सकती हैं) — असली applications को deploy करने के लिए रोज़मर्रा का व्यावहारिक ज्ञान है। उतना ही महत्वपूर्ण है उन security चेतावनियों को समझना जो कई इंजीनियरों को फँसाती हैं: Secret data default रूप से केवल **base64-encoded होता है, encrypted नहीं**, इसलिए इसे वास्तव में सुरक्षित रखने के लिए etcd हेतु **encryption at rest** सक्षम करना, **RBAC** से पहुँच सीमित करना, Secret manifests को version control में commit करने से बचना, और अक्सर एक बाहरी secret manager को integrate करना पड़ता है। चूँकि व्यावहारिक रूप से हर workload को प्रति-environment configuration और credentials चाहिए, और चूँकि Secrets को ग़लत तरीके से संभालना एक आम और गंभीर security खाई है, ConfigMaps और Secrets की ठोस समझ Kubernetes पर applications को सुरक्षित और सही ढंग से चलाने की नींव है।

विचार: config को image से बाहर रखना

ConfigMap: गैर-संवेदनशील settings

Secret: संवेदनशील मान

एक Pod में inject करना: env vars या files के रूप में

Secrets के बारे में ज़रूरी चेतावनियाँ

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न