როგორ მუშაობს ConfigMap-ები და Secret-ები workload-ებში კონფიგურაციის ინექციისთვის?

Question

IT Interview Practice · Accepted Answer

**ConfigMap-ები** და **Secret-ები** კონფიგურაციას კონტეინერის image-ებისგან განაცალკევებენ, ასე რომ ერთი და იგივე image dev-ში, staging-სა და production-ში სხვადასხვა პარამეტრებით მუშაობს. ConfigMap-ები ინახავენ **არასენსიტიურ** კონფიგურაციას; Secret-ები ინახავენ **სენსიტიურ** მონაცემებს (პაროლები, token-ები, გასაღებები) და უფრო ფრთხილად მუშავდებიან.

## იდეა: კონფიგურაცია image-ის გარეთ

```text
Image = code (immutable, built once).  Config = per-environment values.
Baking config into the image is an anti-pattern (rebuild per env, secrets leak).
→ Store config in ConfigMaps/Secrets, inject at runtime as env vars or files.
```

## ConfigMap: არასენსიტიური პარამეტრები

```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:            # აქ ღია ტექსტი; etcd-ში base64-ით დაშიფრულად ინახება
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# ჩვეულებრივ იმპერატიულად იქმნება, რომ secret-ები git-ში არ ჩაიდოს:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Pod-ში ინექცია: env ცვლადებად ან ფაილებად

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # ერთი გასაღები ConfigMap-იდან
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # ერთი გასაღები Secret-იდან
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # ყველა გასაღების იმპორტი env ცვლადებად
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # კონფიგურაციის მიმაგრება ფაილებად
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## მნიშვნელოვანი გაფრთხილებები Secret-ების შესახებ

```text
⚠ Secret data is base64-ENCODED, not encrypted, by default.
  → Enable ENCRYPTION AT REST for etcd (EncryptionConfiguration).
  → Restrict access with RBAC (who can 'get secrets').
  → Prefer external managers (Vault, cloud Secrets Manager) or sealed secrets.
  → Never commit real Secret manifests to git.
Env-var config is read ONCE at container start; mounted files can update live.
```

## რატომ არის ეს მნიშვნელოვანი

კონფიგურაციის კოდისგან განცალკევება ძირითადი საოპერაციო პრაქტიკაა, ხოლო ConfigMap-ები და Secret-ები არის ის, თუ როგორ ახორციელებს ამას Kubernetes, ამიტომ მათი გაგება არსებითი middle-დონის ცოდნაა. გარემოს-სპეციფიკური პარამეტრების image-ში ჩაშენება ანტი-პატერნია — ის აიძულებს გარემოზე თითო ხელახალ აგებას (rebuild) და secret-ების გაჟონვის რისკს ქმნის — ამიტომ Kubernetes გაძლევთ საშუალებას შეინახოთ ერთი უცვლელი image და კონფიგურაცია runtime-ზე ჩააინექციოთ: **ConfigMap-ები** არასენსიტიური მნიშვნელობებისთვის (log level-ები, feature flag-ები, კონფიგ ფაილები) და **Secret-ები** სენსიტიური მონაცემებისთვის (პაროლები, token-ები, გასაღებები). მათი მოხმარების ორი გზის ცოდნა — **გარემოს ცვლადებად** (ცალკეული გასაღებები `configMapKeyRef`/`secretKeyRef`-ით ან ყველა გასაღები `envFrom`-ით) და **მიმაგრებულ ფაილებად** (იმ ნიუანსით, რომ env ცვლადები ერთხელ იკითხება გაშვებისას, ხოლო მიმაგრებული ფაილები შეიძლება ცოცხლად განახლდეს) — ყოველდღიური პრაქტიკული ცოდნაა რეალური აპლიკაციების გასაშვებად. თანაბრად მნიშვნელოვანია იმ უსაფრთხოების გაფრთხილებების გაგება, რომლებზეც ბევრი ინჟინერი ცდება: Secret-ის მონაცემები ნაგულისხმევად მხოლოდ **base64-ით არის დაშიფრული (encoded), და არა encrypted**, ამიტომ მისი ნამდვილი დაცვა მოითხოვს etcd-სთვის **encryption at rest**-ის ჩართვას, წვდომის შეზღუდვას **RBAC**-ით, Secret manifest-ების ვერსიების კონტროლში ჩადების თავიდან აცილებას და ხშირად გარე secret manager-ის ინტეგრაციას. რადგან პრაქტიკულად ყველა workload-ს სჭირდება გარემოზე-სპეციფიკური კონფიგურაცია და მოწმობები, და რადგან Secret-ების არასწორად მართვა გავრცელებული და სერიოზული უსაფრთხოების ხარვეზია, ConfigMap-ებისა და Secret-ების მყარი ცოდნა ფუნდამენტურია აპლიკაციების Kubernetes-ზე უსაფრთხოდ და სწორად გასაშვებად.

იდეა: კონფიგურაცია image-ის გარეთ

ConfigMap: არასენსიტიური პარამეტრები

Secret: სენსიტიური მნიშვნელობები

Pod-ში ინექცია: env ცვლადებად ან ფაილებად

მნიშვნელოვანი გაფრთხილებები Secret-ების შესახებ

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები