Kubernetes’da ConfigMap va Secret: ilova konfiguratsiyasini boshqarish

Qisqa javob

Kubernetes konfiguratsiyani konteyner obrazidan ikki obyekt orqali ajratadi:

• ConfigMap — maxfiy bo‘lmagan sozlamalar: feature-flaglar, boshqa servislar manzillari, log darajasi, konfiguratsiya fayllari.
• Secret — maxfiy ma’lumotlar: parollar, API tokenlari, TLS sertifikatlari.

Ikkalasi ham podga ikki usulda uzatiladi: muhit o‘zgaruvchilari sifatida yoki ulangan volume ichidagi fayllar sifatida. Shu tufayli bitta obraz dev, staging va production’da turli konfiguratsiya bilan ishlaydi.

Asosiy ogohlantirish: Secret qiymatlari faqat base64 bilan kodlangan. Obyektni o‘qiy oladigan har kim uni bitta buyruq bilan ochadi. Haqiqiy himoya — kirish huquqlari, saqlashda shifrlash va Git’da ochiq sirlar bo‘lmasligi.

ConfigMap va Secret yaratish

Tezkor tekshiruvlar uchun buyruqlar yetarli:

kubectl create configmap app-config --from-literal=LOG_LEVEL=info --from-file=app.yaml
kubectl create secret generic db-credentials --from-literal=DB_PASSWORD=change-me

Haqiqiy loyihalarda deklarativ manifestlar afzal. Secret’dagi stringData maydoni qiymatlarni ochiq yozish imkonini beradi — Kubernetes ularni saqlashda o‘zi kodlaydi:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  API_BASE_URL: "https://api.internal"
---
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  DB_PASSWORD: "change-me"

Bunday Secret manifestini Git’ga commit qilmang — bu haqda quyida.

Muhit o‘zgaruvchilari yoki fayllar

containers:
  - name: app
    image: registry.example.com/app:1.4.0
    envFrom:
      - configMapRef:
          name: app-config
    env:
      - name: DB_PASSWORD
        valueFrom:
          secretKeyRef:
            name: db-credentials
            key: DB_PASSWORD
    volumeMounts:
      - name: config
        mountPath: /etc/app
        readOnly: true
volumes:
  - name: config
    configMap:
      name: app-config

Amaliy qoida: kichik sozlamalar — env orqali, fayllar va sertifikatlar — volume orqali, sirlarni esa imkon bo‘lsa fayl bilan uzating.

Konfiguratsiyani yangilash

ConfigMap o‘zgarishi hech narsani qayta ishga tushirmaydi. Natija ulash usuliga bog‘liq:

• Muhit o‘zgaruvchilari ishlayotgan konteyner ichida o‘zgarmaydi. Yangi rollout kerak.
• Volume’dagi fayllarni kubelet vaqt o‘tib yangilaydi, ammo ilova faylni qayta o‘qishi kerak. Ko‘p ilovalar konfiguratsiyani faqat ishga tushishda o‘qiydi.

Ishchi yondashuvlar:

1. O‘zgarishdan keyin deploymentni qayta ishga tushiring: kubectl rollout restart deployment/app.
2. Pod shabloniga konfiguratsiya xeshi bilan annotatsiya qo‘shing (Helm va Kustomize’da qulay). Konfiguratsiya o‘zgardi — xesh o‘zgardi — podlar avtomatik yangilanadi.
3. O‘zgarmas, versiyalangan ConfigMap’lardan foydalaning (app-config-v7, immutable: true) va deploymentni yangi nomga o‘tkazing. Orqaga qaytish juda oson bo‘ladi.
4. O‘zgarishlarni qayta ishga tushirmasdan olish kerak bo‘lsa, ilovada faylni kuzating.

Nega base64 shifrlash emas

Base64 faqat ikkilik ma’lumotni matn sifatida saqlash imkonini beradi. Ochish uchun kalit kerak emas:

kubectl get secret db-credentials -o jsonpath='{.data.DB_PASSWORD}' | base64 -d

Shuning uchun haqiqiy himoya quyidagicha quriladi:

• RBAC: Secret’lar uchun get, list va watch huquqlarini cheklang. list ham qiymatlarni qaytarishini hisobga oling.
• etcd’da saqlashda shifrlash (API serverda sozlanadi yoki managed provayderda yoqiladi).
• Git’da ochiq Secret yo‘q, obrazga tikilgan sirlar ham yo‘q.
• Namespace’da kim pod yarata olishini cheklang: u yerda pod ishga tushira oladigan har kim uning sirlarini ulay oladi.

Sirlarni Git’da xavfsiz saqlash

Ko‘p uchraydigan xatolar

• Parolni ConfigMap’ga «vaqtincha» qo‘yish.
• base64’dagi Secret’ni commit qilib, uni yashirin deb hisoblash.
• ConfigMap tahrirlangach env yangilanishini kutish.
• subPath orqali ulash va fayllar nega yangilanmayotganiga hayron bo‘lish.
• CI yoki dasturchilarga klasterdagi barcha Secret’larni o‘qish huquqini berish.