Bagaimana ConfigMap dan Secret berfungsi untuk menyuntik konfigurasi ke dalam workload?

Question

IT Interview Practice · Accepted Answer

**ConfigMap** dan **Secret** memisahkan konfigurasi daripada imej kontena, jadi imej yang sama berjalan di dev, staging, dan production dengan tetapan berbeza. ConfigMap menyimpan config **tidak sensitif**; Secret menyimpan data **sensitif** (kata laluan, token, kunci) dan dikendalikan dengan lebih berhati-hati.

## Ideanya: config di luar imej

```text
Imej = kod (tak berubah, dibina sekali).  Config = nilai setiap persekitaran.
Membakar config ke dalam imej ialah anti-pattern (bina semula setiap persekitaran, secret bocor).
→ Simpan config dalam ConfigMap/Secret, suntik pada masa runtime sebagai env var atau fail.
```

## ConfigMap: tetapan tidak sensitif

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

## Secret: nilai sensitif

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # plaintext di sini; disimpan berenkod base64 dalam etcd
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Biasanya dicipta secara imperatif untuk elak commit secret ke git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Menyuntik ke dalam Pod: sebagai env var atau sebagai fail

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # satu key daripada ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # satu key daripada Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # import SEMUA key sebagai env var
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # lekapkan config sebagai fail
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Amaran penting tentang Secret

```text
⚠ Data Secret secara default DIENKOD base64, bukan disulitkan (encrypted).
  → Dayakan ENCRYPTION AT REST untuk etcd (EncryptionConfiguration).
  → Hadkan akses dengan RBAC (siapa boleh 'get secrets').
  → Utamakan pengurus luaran (Vault, cloud Secrets Manager) atau sealed secrets.
  → Jangan sekali-kali commit manifest Secret sebenar ke git.
Config env var dibaca SEKALI pada permulaan kontena; fail yang dilekapkan boleh dikemas kini secara langsung.
```

## Mengapa ia penting

Memisahkan konfigurasi daripada kod ialah amalan operasi teras, dan ConfigMap serta Secret ialah cara Kubernetes melaksanakannya, jadi memahaminya ialah pengetahuan peringkat pertengahan yang penting. Membakar tetapan khusus persekitaran ke dalam imej ialah anti-pattern — ia memaksa binaan semula setiap persekitaran dan berisiko membocorkan secret — jadi Kubernetes membenarkan anda mengekalkan satu imej tak berubah tunggal dan menyuntik konfigurasi pada masa runtime: **ConfigMap** untuk nilai tidak sensitif (log level, feature flag, fail config) dan **Secret** untuk data sensitif (kata laluan, token, kunci). Mengetahui dua cara menggunakannya — sebagai **pemboleh ubah persekitaran** (key individu melalui `configMapKeyRef`/`secretKeyRef`, atau semua key melalui `envFrom`) dan sebagai **fail yang dilekapkan** (dengan nuansa bahawa env var dibaca sekali pada permulaan manakala fail yang dilekapkan boleh dikemas kini secara langsung) — ialah pengetahuan praktikal harian untuk menerap aplikasi sebenar. Sama penting ialah memahami amaran keselamatan yang menjatuhkan ramai jurutera: data Secret secara default hanya **dienkod base64, bukan disulitkan**, jadi melindunginya dengan sebenar-benarnya memerlukan pendayaan **encryption at rest** untuk etcd, menghadkan akses dengan **RBAC**, mengelakkan commit manifest Secret ke kawalan versi, dan selalunya menyepadukan pengurus secret luaran. Kerana hampir setiap workload memerlukan konfigurasi dan kelayakan setiap persekitaran, dan kerana salah mengendali Secret ialah jurang keselamatan yang biasa dan serius, kefahaman yang kukuh tentang ConfigMap dan Secret adalah asas untuk menjalankan aplikasi dengan selamat dan betul pada Kubernetes.

Ideanya: config di luar imej

ConfigMap: tetapan tidak sensitif

Secret: nilai sensitif

Menyuntik ke dalam Pod: sebagai env var atau sebagai fail

Amaran penting tentang Secret

Mengapa ia penting

Soalan berkaitan