ConfigMap, Secret & Manajemen Rahasia — Belajar Kubernetes

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: konfigurasi-pesanan
data:
  LOG_LEVEL: "info"
  MAKS_KONEKSI: "50"
  aplikasi.yaml: |
    server:
      port: 8080
      timeout: 30s
    fitur:
      checkout_baru: true

Dua Cara Memakainya

# 1. Sebagai variabel lingkungan
env:
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: konfigurasi-pesanan
        key: LOG_LEVEL

# Atau seluruhnya sekaligus
envFrom:
  - configMapRef:
      name: konfigurasi-pesanan

# 2. Sebagai berkas di dalam volume
volumeMounts:
  - name: konfigurasi
    mountPath: /etc/aplikasi
    readOnly: true
volumes:
  - name: konfigurasi
    configMap:
      name: konfigurasi-pesanan

⚠️ Perbedaan penting antara env dan volume

ConfigMap yang di-mount sebagai volume akan diperbarui otomatis ketika ConfigMap-nya berubah (dengan jeda sekitar satu menit). ConfigMap yang dipakai sebagai variabel lingkungan tidak pernah berubah setelah pod menyala — variabel lingkungan ditetapkan sekali saat proses dibuat.

Karena itu, mengubah ConfigMap yang dipakai lewat env tidak berdampak apa-apa sampai pod dibuat ulang: kubectl rollout restart deploy/nama.

Secret

apiVersion: v1
kind: Secret
metadata:
  name: kredensial-basisdata
type: Opaque
stringData:                 # stringData lebih nyaman: tidak perlu base64 manual
  DB_PASSWORD: rahasia-yang-sangat-kuat
  DB_USER: aplikasi

🚫 Secret TIDAK dienkripsi secara bawaan

Secret hanya di-encode base64, dan base64 bukan enkripsi — siapa pun bisa membalikkannya dalam satu detik:

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

Secret disimpan apa adanya di etcd. Agar benar-benar aman, Anda harus: (1) mengaktifkan enkripsi at-rest pada etcd, (2) membatasi akses lewat RBAC — perhatikan bahwa siapa pun yang boleh membuat pod pada dasarnya bisa membaca Secret di namespace itu, dan (3) mengambil rahasia dari manajer rahasia eksternal.

Jangan Menaruh Rahasia di Git

Manifest Kubernetes seharusnya berada di Git, tetapi Secret mentah jelas tidak boleh. Ada tiga pendekatan yang lazim:

1. External Secrets Operator

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: kredensial-basisdata
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-belakang
    kind: ClusterSecretStore
  target:
    name: kredensial-basisdata
  data:
    - secretKey: DB_PASSWORD
      remoteRef:
        key: produksi/basisdata
        property: password

Rahasia yang sebenarnya tinggal di Vault, AWS Secrets Manager, atau sejenisnya. Yang masuk Git hanyalah petunjuk ke mana mengambilnya. Ini pendekatan yang paling dianjurkan untuk produksi.

2. Sealed Secrets

kubeseal --format yaml < secret.yaml > sealed-secret.yaml

Secret dienkripsi dengan kunci publik controller. Hasilnya aman disimpan di Git, dan hanya controller di kluster itu yang bisa membukanya. Cocok bila Anda belum punya manajer rahasia terpusat.

3. SOPS

sops --encrypt --age $KUNCI_AGE secret.yaml > secret.enc.yaml

Mengenkripsi hanya bagian nilai, sehingga struktur YAML tetap terbaca dan diff di Git tetap bermakna.

Memuat Ulang Konfigurasi Saat Berubah

📌 Trik checksum anotasi

metadata:
  annotations:
    checksum/konfigurasi: "{{ sha256sum .Values.konfigurasi }}"

Dengan menaruh hash isi ConfigMap sebagai anotasi pada template pod, setiap perubahan konfigurasi mengubah spesifikasi pod — sehingga Kubernetes otomatis melakukan rolling update. Tanpa trik ini, Anda harus ingat menjalankan restart manual setiap kali mengubah konfigurasi, dan orang pasti lupa.

Praktik yang Baik

Satu ConfigMap per aplikasi, bukan satu raksasa untuk seluruh kluster.
Jangan pernah menaruh rahasia di ConfigMap. ConfigMap sering terbaca luas dan ikut tercetak di log debug.
Tandai volume Secret sebagai readOnly: true dan atur defaultMode: 0400.
Batasi RBAC untuk Secret — jangan berikan get secrets secara luas.
Rotasi rahasia secara berkala, dan pastikan aplikasi bisa memuat ulang tanpa restart bila memungkinkan.