Si funksionojnë ConfigMap-et dhe Secret-et për të injektuar konfigurim në workload-e?

Question

IT Interview Practice · Accepted Answer

**ConfigMap-et** dhe **Secret-et** e shkëpusin konfigurimin nga image-t e container-ave, kështu që i njëjti image funksionon në dev, staging dhe production me setting-e të ndryshme. ConfigMap-et mbajnë config **jo-sensitive**; Secret-et mbajnë të dhëna **sensitive** (fjalëkalime, token, çelësa) dhe trajtohen më me kujdes.

## Ideja: config jashtë image-t

```text
Image = kodi (i pandryshueshëm, ndërtuar një herë).  Config = vlera për çdo mjedis.
Të pjekësh config-un brenda image-t është një anti-pattern (rindërtim për çdo mjedis, rrjedhje secret-esh).
→ Ruaj config-un në ConfigMap/Secret, injektoje në runtime si env var ose skedarë.
```

## ConfigMap: setting-e jo-sensitive

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

## Secret: vlera sensitive

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # plaintext këtu; ruhet i enkoduar base64 në etcd
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Zakonisht krijohet në mënyrë imperative për të shmangur commit-imin e secret-eve në git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Injektimi në një Pod: si env var ose si skedarë

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # një key nga një ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # një key nga një Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # importo TË GJITHA key-t si env var
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # mount config-un si skedarë
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Paralajmërime të rëndësishme rreth Secret-eve

```text
⚠ Të dhënat e Secret-it janë të ENKODUARA base64, jo të enkriptuara, si default.
  → Aktivizo ENCRYPTION AT REST për etcd (EncryptionConfiguration).
  → Kufizo aksesin me RBAC (kush mund të bëjë 'get secrets').
  → Preferoji menaxherë të jashtëm (Vault, cloud Secrets Manager) ose sealed secrets.
  → Kurrë mos bëj commit të manifest-eve reale Secret në git.
Config-u me env var lexohet NJË HERË në nisje të container-it; skedarët e mount-uar mund të përditësohen live.
```

## Pse ka rëndësi

Ndarja e konfigurimit nga kodi është një praktikë operacionale thelbësore, dhe ConfigMap-et e Secret-et janë mënyra si Kubernetes e implementon atë, kështu që t'i kuptosh është njohuri thelbësore e nivelit middle. Të pjekësh setting-e specifike për mjedisin brenda një image-i është një anti-pattern — detyron një rindërtim për çdo mjedis dhe rrezikon rrjedhjen e secret-eve — kështu që Kubernetes të lejon të mbash një image të vetme të pandryshueshme dhe të injektosh konfigurimin në runtime: **ConfigMap-e** për vlera jo-sensitive (log level, feature flag, skedarë config-u) dhe **Secret-e** për të dhëna sensitive (fjalëkalime, token, çelësa). Të dish dy mënyrat për t'i konsumuar ato — si **variabla mjedisi** (key individuale nëpërmjet `configMapKeyRef`/`secretKeyRef`, ose të gjitha key-t nëpërmjet `envFrom`) dhe si **skedarë të mount-uar** (me hollësinë që env var-et lexohen një herë në nisje ndërsa skedarët e mount-uar mund të përditësohen live) — është njohuri e përditshme praktike për të bërë deploy aplikacione reale. Po aq e rëndësishme është të kuptosh paralajmërimet e sigurisë që pengojnë shumë inxhinierë: të dhënat e Secret-it janë vetëm të **enkoduara base64, jo të enkriptuara**, si default, kështu që për ta mbrojtur vërtet nevojitet aktivizimi i **encryption at rest** për etcd, kufizimi i aksesit me **RBAC**, shmangia e commit-imit të manifest-eve Secret në version control, dhe shpesh integrimi i një menaxheri të jashtëm secret-esh. Meqë thuajse çdo workload ka nevojë për konfigurim për çdo mjedis dhe kredenciale, dhe meqë trajtimi i keq i Secret-eve është një boshllëk sigurie i zakonshëm dhe serioz, kapja solide e ConfigMap-eve dhe Secret-eve është themelore për të drejtuar aplikacione në mënyrë të sigurt dhe të saktë në Kubernetes.

Ideja: config jashtë image-t

ConfigMap: setting-e jo-sensitive

Secret: vlera sensitive

Injektimi në një Pod: si env var ose si skedarë

Paralajmërime të rëndësishme rreth Secret-eve

Pse ka rëndësi

Pyetje të ngjashme