Pelajari cara mengelola konfigurasi aplikasi di Kubernetes dengan ConfigMap dan Secret, lengkap contoh manifest, mounting Pod, dan best practice.

Bayangkan Anda harus mengganti alamat database sebuah aplikasi yang berjalan di puluhan Pod sekaligus. Tanpa strategi konfigurasi yang tepat, Anda mungkin terpaksa membangun ulang image Docker, mendorongnya ke registry, lalu men-deploy ulang seluruh aplikasi hanya karena satu baris konfigurasi berubah. Proses ini lambat, berisiko, dan jauh dari efisien.

Di sinilah ConfigMap dan Secret hadir sebagai solusi native Kubernetes. Keduanya memungkinkan pemisahan yang tegas antara kode aplikasi dan data konfigurasi — sebuah prinsip inti dari filosofi Twelve-Factor App yang menjadi standar aplikasi cloud native modern.

Bagi Anda yang mengelola cluster Kubernetes, baik untuk keperluan produksi maupun pembelajaran, memahami cara kerja ConfigMap dan Secret bukan lagi opsional. Ini adalah kemampuan dasar yang wajib dikuasai setiap sysadmin, DevOps engineer, maupun mahasiswa yang sedang mendalami infrastruktur container.

Artikel ini akan membahas tuntas konsep, contoh manifest, cara mounting ke Pod, kesalahan umum, hingga best practice yang digunakan di lingkungan produksi.

Pembahasan Utama

Apa Itu ConfigMap?

ConfigMap adalah objek API Kubernetes yang digunakan untuk menyimpan data konfigurasi non-sensitif dalam bentuk pasangan key-value. Data ini bisa berupa variabel lingkungan sederhana, file konfigurasi utuh, argumen command-line, atau parameter aplikasi lainnya.

Analoginya sederhana: bayangkan ConfigMap sebagai “lemari arsip” yang menyimpan catatan pengaturan aplikasi Anda — seperti nama environment, port server, atau URL endpoint API publik. Siapa pun yang punya akses ke cluster bisa membaca isinya tanpa risiko keamanan besar, karena memang tidak berisi data rahasia.

Apa Itu Secret?

Secret memiliki struktur mirip ConfigMap, tetapi dirancang khusus untuk data yang bersifat sensitif: password database, token API, kunci SSH, sertifikat TLS, dan kredensial lainnya. Secara default, nilai dalam Secret disimpan dalam format base64-encoded, bukan terenkripsi — penting untuk dipahami agar tidak salah kaprah menganggap base64 sebagai bentuk enkripsi.

Untuk keamanan produksi yang lebih serius, Kubernetes menyarankan mengaktifkan encryption at rest pada etcd serta membatasi akses Secret melalui RBAC.

Mengapa Harus Dipisahkan?

Memisahkan konfigurasi dari kode aplikasi memberikan beberapa keuntungan nyata:

Portabilitas — image aplikasi yang sama bisa dipakai di environment development, staging, maupun production hanya dengan mengganti ConfigMap/Secret yang digunakan.
Keamanan — kredensial tidak ikut ter-bake ke dalam image, sehingga tidak bocor lewat registry publik atau riwayat Git.
Efisiensi operasional — perubahan konfigurasi tidak memerlukan proses build ulang image, cukup update objek Kubernetes.
Kolaborasi tim lebih rapi — tim development tidak perlu tahu kredensial produksi, cukup tim operasi yang mengelolanya.

Contoh Manifest ConfigMap

Berikut contoh ConfigMap sederhana untuk menyimpan konfigurasi aplikasi web:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: production
data:
  APP_ENV: "production"
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"
  app.properties: |
    server.port=8080
    cache.ttl=3600

Perhatikan bahwa ConfigMap mendukung dua gaya data: property-like (key sederhana seperti APP_ENV) dan file-like (blok multi-baris seperti app.properties).

Contoh Manifest Secret

Untuk data sensitif seperti kredensial database, gunakan field stringData agar tidak perlu meng-encode base64 secara manual:

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  namespace: production
type: Opaque
stringData:
  DB_USERNAME: "admin_user"
  DB_PASSWORD: "P4ssw0rd_Sangat_Rahasia"

Kubernetes akan otomatis meng-encode nilai stringData menjadi base64 saat objek dibuat.

Cara Mounting ke Pod

ConfigMap dan Secret bisa dikonsumsi Pod dengan dua cara utama: sebagai environment variable atau sebagai volume mount.

1. Sebagai Environment Variable

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: myregistry/web-app:1.0
          envFrom:
            - configMapRef:
                name: app-config
            - secretRef:
                name: db-credentials

2. Sebagai Volume Mount

      volumes:
        - name: config-volume
          configMap:
            name: app-config
        - name: secret-volume
          secret:
            secretName: db-credentials
      containers:
        - name: web-app
          image: myregistry/web-app:1.0
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
            - name: secret-volume
              mountPath: /etc/secret
              readOnly: true

Metode volume mount lebih cocok untuk file konfigurasi berukuran besar atau multi-baris, sedangkan environment variable lebih praktis untuk parameter sederhana.

Studi Kasus Sederhana

Sebuah tim mengelola aplikasi e-commerce dengan tiga environment: development, staging, dan production. Alih-alih membuat tiga image berbeda, tim cukup membuat tiga ConfigMap dan Secret dengan nama yang sama namun isi berbeda di masing-masing namespace. Deployment YAML tetap identik, hanya namespace target yang berubah saat deploy. Hasilnya, proses CI/CD menjadi jauh lebih sederhana dan konsisten.

Tutorial Step-by-Step: Update Konfigurasi Tanpa Membangun Ulang Image

Buat ConfigMap dari file konfigurasi yang sudah ada kubectl create configmap app-config --from-file=app.properties
Mount ConfigMap tersebut ke Pod melalui volumeMounts seperti contoh di atas.
Ubah nilai ConfigMap menggunakan kubectl edit configmap app-config atau kubectl apply -f dengan manifest baru.
Tunggu propagasi otomatis. Untuk ConfigMap yang di-mount sebagai volume, kubelet akan menyinkronkan perubahan secara berkala (umumnya dalam rentang 30–90 detik, tergantung kubelet sync period dan cache TTL).
Pastikan aplikasi Anda mendeteksi perubahan file, misalnya dengan mekanisme file watcher (inotify) atau polling berkala, karena Kubernetes hanya memperbarui file di volume — aplikasi tetap perlu memuat ulang konfigurasinya sendiri.
Untuk konfigurasi berbentuk environment variable, perubahan ConfigMap tidak akan otomatis terbaca oleh Pod yang sedang berjalan. Anda perlu melakukan rolling restart, misalnya dengan: kubectl rollout restart deployment web-app

Kesalahan yang Sering Terjadi

1. Menyimpan data sensitif di ConfigMap

Penyebab: kurang memahami perbedaan fungsi ConfigMap dan Secret.
Dampak: kredensial mudah terekspos karena ConfigMap tidak memiliki perlindungan tambahan.
Solusi: selalu gunakan Secret untuk password, token, dan kunci API, lalu batasi akses lewat RBAC.

2. Mengira base64 sebagai enkripsi

Penyebab: asumsi keliru terhadap format encoding Secret.
Dampak: tim merasa aman padahal siapa pun dengan akses kubectl get secret -o yaml bisa membaca isinya.
Solusi: aktifkan encryption at rest pada etcd atau gunakan external secret manager seperti HashiCorp Vault.

3. Menggunakan subPath lalu berharap update otomatis

Penyebab: kurang memahami keterbatasan mekanisme mounting Kubernetes.
Dampak: file konfigurasi yang di-mount dengan subPath tidak pernah diperbarui otomatis, meskipun ConfigMap sumbernya berubah.
Solusi: gunakan mount direktori penuh atau projected volume jika membutuhkan pembaruan otomatis.

4. Lupa bahwa environment variable tidak auto-reload

Penyebab: menyamakan perilaku volume mount dengan environment variable.
Dampak: aplikasi tetap memakai nilai lama meski ConfigMap sudah diperbarui.
Solusi: lakukan rolling restart Deployment, atau tambahkan anotasi hash konfigurasi agar perubahan otomatis memicu rollout baru.

5. ConfigMap/Secret terlalu besar

Penyebab: menjejalkan file konfigurasi besar ke satu objek.
Dampak: Kubernetes membatasi ukuran maksimal ConfigMap dan Secret hingga 1 MiB, sehingga bisa gagal dibuat.
Solusi: gunakan penyimpanan eksternal (misalnya object storage) untuk data besar, dan simpan hanya referensinya di ConfigMap.

Tips dan Rekomendasi

Gunakan immutable: true untuk ConfigMap dan Secret yang datanya jarang berubah. Selain mencegah perubahan tak sengaja, fitur ini juga mengurangi beban watch pada kubelet dan meningkatkan performa cluster, khususnya pada skala besar.
Terapkan strategi versioning nama, misalnya app-config-v1, app-config-v2, lalu ubah referensi di Deployment saat rilis baru — pola ini memudahkan rollback tanpa proses edit langsung pada objek immutable.
Batasi akses Secret dengan RBAC melalui Role dan RoleBinding, sehingga hanya ServiceAccount tertentu yang boleh membaca Secret produksi.
Gunakan stringData saat membuat Secret, agar tidak perlu meng-encode base64 secara manual dan mengurangi risiko kesalahan input.
Pertimbangkan external secret manager seperti Vault, AWS Secrets Manager, atau External Secrets Operator untuk kebutuhan audit log dan rotasi otomatis di lingkungan enterprise.
Tambahkan config hash annotation pada Deployment agar perubahan ConfigMap memicu rolling update otomatis, bukan hanya menunggu propagasi manual.

Kesimpulan

ConfigMap dan Secret adalah dua pilar penting dalam mengelola konfigurasi aplikasi di Kubernetes secara aman, fleksibel, dan efisien. ConfigMap cocok untuk data non-sensitif seperti pengaturan aplikasi umum, sementara Secret dirancang khusus untuk kredensial dan data rahasia — meski perlu diingat bahwa base64 bukan enkripsi sejati.

Poin penting yang perlu diingat:

Pisahkan konfigurasi dari image aplikasi untuk portabilitas dan keamanan.
Volume mount mendukung pembaruan otomatis (dengan jeda beberapa puluh detik), sedangkan environment variable memerlukan restart Pod.
Hindari subPath jika Anda membutuhkan pembaruan konfigurasi otomatis.
Gunakan immutable: true dan strategi versioning untuk lingkungan produksi berskala besar.
Untuk keamanan maksimal, kombinasikan Secret dengan RBAC dan encryption at rest.

Dengan memahami dan menerapkan praktik-praktik ini, tim Anda dapat mengelola konfigurasi aplikasi secara lebih tertata, aman, dan siap untuk skala produksi.

Frequently Asked Questions (FAQ)

Pertanyaan: Apa perbedaan utama antara ConfigMap dan Secret di Kubernetes? Jawaban: ConfigMap digunakan untuk data konfigurasi non-sensitif, sedangkan Secret dirancang untuk data sensitif seperti password dan token, dengan penanganan akses yang lebih terbatas.

Pertanyaan: Apakah data di dalam Secret sudah terenkripsi secara otomatis? Jawaban: Tidak. Secara default nilai Secret hanya di-encode base64, bukan dienkripsi. Enkripsi sesungguhnya perlu diaktifkan lewat encryption at rest pada etcd.

Pertanyaan: Apakah perubahan pada ConfigMap langsung terlihat di Pod yang sedang berjalan? Jawaban: Untuk volume mount, perubahan akan terpropagasi otomatis dalam waktu singkat. Untuk environment variable, Pod perlu di-restart agar nilai baru terbaca.

Pertanyaan: Kapan sebaiknya menggunakan ConfigMap sebagai environment variable dibanding volume mount? Jawaban: Environment variable cocok untuk parameter sederhana, sementara volume mount lebih ideal untuk file konfigurasi kompleks atau berukuran besar.

Pertanyaan: Apa manfaat menandai ConfigMap atau Secret sebagai immutable? Jawaban: Menandai objek sebagai immutable mencegah perubahan data yang tidak disengaja dan mengurangi beban watch pada kubelet, sehingga meningkatkan performa cluster skala besar.

Sudah lebih paham cara mengelola konfigurasi aplikasi di Kubernetes dengan ConfigMap dan Secret? Yuk, bagikan pengalaman Anda di kolom komentar — apakah Anda pernah mengalami masalah konfigurasi yang tidak ter-update otomatis?

Jangan ragu berdiskusi jika masih ada bagian yang membingungkan. Jika artikel ini bermanfaat, bagikan ke rekan tim DevOps Anda, dan jangan lupa jelajahi artikel terkait lainnya seputar Kubernetes, cloud computing, dan infrastruktur IT di website ini. Ikuti terus konten terbaru agar tidak ketinggalan update seputar dunia Sysadmin, DevOps, dan Cybersecurity!

Terkait

You may have missed

Kontribusi & Donasi...