Belajar PKI - cert-manager: Kubernetes Certificate Automation

#Pendahuluan

Di episode 9 sebelumnya kalian membangun step-ca sebagai private CA modern dengan dukungan ACME, provisioner, dan SSH. Satu hal yang mungkin terasa kurang: semua itu masih dikelola per mesin. Di Kubernetes, mengurus sertifikat per pod atau per service secara manual adalah mimpi buruk — pod berganti, nama berubah, dan volume sertifikat terus bertambah. Episode 10 menjawabnya dengan cert-manager, komponen yang menjadi standar de facto untuk otomatisasi sertifikat di ekosistem Kubernetes.

Ia berbicara dengan banyak sumber CA, dari Let's Encrypt hingga step-ca, lalu menerbitkan, memperbarui, dan mengelola sertifikat sebagai resource Kubernetes biasa. Versi 1.21 yang rilis Juli 2026 adalah fokus kita: arsitektur dan CRD, instalasi via Helm dengan plugin kubectl, Certificate untuk Ingress dan mTLS, fitur unggulan seperti ACME profiles dan ExternalIssuer, hingga trust-manager.

#Apa itu cert-manager 1.21

cert-manager adalah controller yang berjalan di dalam cluster dan mengotomatiskan lifecycle sertifikat X.509. Ia memperlakukan sertifikat sebagai deklaratif: kalian menulis resource yang menyatakan sertifikat apa yang diinginkan, dan controller mewujudkannya — termasuk memperbarui sebelum kedaluwarsa. Versi 1.21 membawa penyempurnaan pada integrasi ACME, ExternalIssuer, dan dukungan Gateway API.

#Arsitektur Dasar

cert-manager terdiri dari controller utama dan webhook yang memvalidasi resource sebelum disimpan ke etcd. Controller terus mengamati state cluster dan membandingkannya dengan keinginan kalian. Perbedaan antara keduanya memicu aksi: menerbitkan, memperbarui, atau memperbaiki sertifikat.

#CRD yang Digunakan

• Issuer dan ClusterIssuer: mendefinisikan sumber CA — misalnya Let's Encrypt atau step-ca — beserta kredensialnya.
• Certificate: resource inti yang menyatakan keinginan, termasuk nama secret tujuan dan durasi.
• CertificateRequest: hasil terjemahan Certificate menjadi permintaan penerbitan yang menunggu disetujui Issuer.
• Order dan Challenge: resource internal yang dipakai alur ACME.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: internal-ca
  namespace: default
spec:
  ca:
    secretName: root-ca-secret

Contoh di atas adalah Issuer tipe ca yang menerbitkan sertifikat memakai root CA yang disimpan di sebuah Secret. Perbedaan Issuer dan ClusterIssuer hanya cakupan: Issuer terbatas pada satu namespace, sedangkan ClusterIssuer berlaku di seluruh cluster.

#Instalasi via Helm

Cara paling umum menginstal cert-manager adalah lewat Helm chart resmi dari Jetstack. Sejak versi tertentu, CRD diinstal sekaligus bersama chart sehingga tidak perlu langkah terpisah.

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true

#Plugin kubectl cert-manager

Untuk debugging dan operasi sehari-hari, cert-manager menyediakan plugin kubectl yang menyingkat banyak perintah. Plugin ini membantu memeriksa status sertifikat, memperbarui paksa, dan mengecek penyebab kegagalan penerbitan.

kubectl cert-manager status certificate web01-tls
kubectl cert-manager renew web01-tls

#Resource Certificate untuk Skenario Nyata

#Sertifikat untuk Ingress

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: web01-tls
  namespace: default
spec:
  secretName: web01-tls
  duration: 2160h
  renewBefore: 720h
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - web01.internal
    - api.internal

Perhatikan duration dan renewBefore: sertifikat diminta berlaku 90 hari dan diperbarui 30 hari sebelum kedaluwarsa. Ketika Secret web01-tls dipakai oleh Ingress, kontennya diperbarui otomatis setiap siklus renewal tanpa intervensi manusia. Kegagalan renewal yang berkepanjangan akan terlihat dari kondisi Certificate.

#mTLS antar Service

cert-manager juga andal untuk mTLS internal. Setiap service bisa mendapat client certificate dengan usages khusus, misalnya client auth, sehingga komunikasi antar service bisa diverifikasi dua arah — persis seperti mTLS yang kita bangun manual di episode 7.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: billing-client
  namespace: billing
spec:
  secretName: billing-client
  usages:
    - client auth
  issuerRef:
    name: internal-ca
    kind: ClusterIssuer
  commonName: billing-client

Bagian usages membatasi pemakaian sertifikat menjadi autentikasi klien saja, sehingga sertifikat tidak bisa disalahgunakan untuk keperluan lain. Dengan pola ini, kalian mendapatkan identitas per service yang otomatis dirotasi — fondasi zero trust di level jaringan.

#Fitur Unggulan cert-manager 1.21

#ACME Cert Profiles

cert-manager mengikuti perkembangan ACME Profiles yang kita bahas di episode 8. Ketika CA mendukung profil bernama, cert-manager bisa meminta sertifikat dengan profil tertentu lewat konfigurasi pada resource Certificate, sehingga kebijakan seperti masa berlaku dikendalikan oleh CA, bukan hanya klien.

#ExternalIssuer: step-ca dan Venafi

Salah satu kekuatan besar cert-manager adalah API ExternalIssuer yang membuka pintu ke sistem CA apa pun. Melalui kontrak ini, proyek seperti step-ca dan Venafi menyediakan controller masing-masing yang berkomunikasi dengan cert-manager. Hasilnya: cert-manager tidak terikat pada satu vendor.

Untuk step-ca, integrasi ini dinamai step-issuer. Kalian mendefinisikan resource StepIssuer yang menunjuk ke instance step-ca dan provisioner yang dipakai, lalu semua Certificate bisa memakainya sebagai sumber penerbitan.

apiVersion: certmanager.step.sm/v1beta1
kind: StepIssuer
metadata:
  name: step-issuer
  namespace: cert-manager
spec:
  caURL: https://ca.internal
  provisionerRef:
    name: admin

Dengan step-issuer, seluruh otomatisasi cert-manager memanfaatkan kemampuan step-ca dari episode 9 — termasuk template, kebijakan provisioner, dan renewal dengan kredensial khusus — tanpa meninggalkan alur kerja Kubernetes. Selain itu, cert-manager terus memperluas dukungan terhadap Gateway API, standar baru untuk traffic yang menggantikan peran Ingress dengan objek Gateway dan HTTPRoute; sertifikatnya tetap dikelola lewat resource Certificate biasa.

#Auto-Renewal dan Revision History

Salah satu nilai jual terbesar cert-manager adalah auto-renewal. Controller memantau setiap Certificate dan memperbarui sebelum kedaluwarsa sesuai renewBefore. Setiap pembaruan menghasilkan revisi baru pada Secret tujuan, sehingga rollback ke versi sebelumnya bisa dilakukan bila terjadi masalah.

kubectl describe certificate web01-tls

kubectl describe certificate menampilkan riwayat kondisi, termasuk kapan renewal terakhir terjadi dan apakah ada kegagalan. Riwayat revisi di Secret memudahkan inspeksi ketika perubahan tak terduga terjadi.

#trust-manager untuk Trust Store

Menerbitkan sertifikat saja tidak cukup — aplikasi juga perlu mempercayai CA yang menerbitkannya. Di sinilah trust-manager masuk. Komponen dari proyek cert-manager ini mengemas bundle CA dari berbagai sumber ke dalam satu ConfigMap atau Secret yang bisa di-mount ke aplikasi.

apiVersion: trust.cert-manager.io/v1alpha1
kind: Bundle
metadata:
  name: root-ca-bundle
spec:
  sources:
    - useDefaultCAs: true
    - secret:
        name: root-ca
        key: ca.crt
  target:
    configMap:
      key: ca-bundle.crt

useDefaultCAs memasukkan CA sistem, sementara sumber secret menambahkan root CA internal. Hasilnya, kalian mendapatkan satu file trust store yang konsisten di semua workload. Kombinasikan dengan episode 5 tentang distribusi root certificate — trust-manager mengotomatiskan bagian yang dulu dilakukan manual. Ingat, cert-manager tidak mengubah trust store aplikasi secara langsung, jadi pasangkan trust-manager agar bundle CA selalu didistribusikan dan diperbarui otomatis ke seluruh workload.

#Penutup

Episode 10 menutup celah otomatisasi di Kubernetes. Kalian mengenali arsitektur cert-manager dan CRD-nya, menginstal via Helm dengan plugin kubectl, membuat Certificate untuk Ingress dan mTLS, memanfaatkan fitur ACME profiles dan ExternalIssuer untuk integrasi step-ca, sampai melengkapi alur dengan trust-manager.

Inti yang harus dibawa pulang:

• cert-manager mengotomatiskan issuance dan renewal sertifikat di Kubernetes lewat CRD deklaratif.
• Issuer dan ClusterIssuer mendefinisikan sumber CA, sedangkan Certificate mendefinisikan keinginan sertifikat.
• Helm adalah cara standar instalasi, dilengkapi plugin kubectl cert-manager untuk debugging.
• Certificate resource bisa dipakai untuk TLS Ingress sekaligus mTLS antar service dengan usages yang tepat.
• ExternalIssuer membuka integrasi dengan step-ca, Venafi, dan sistem CA lainnya tanpa vendor lock-in.
• trust-manager melengkapi alur dengan mendistribusikan bundle CA ke seluruh workload.

Di episode 11, kita melihat pendekatan yang berbeda. Kalian akan belajar CFSSL, toolkit PKI dari Cloudflare yang populer di masanya: gencert, genkey, certinfo, scan, hingga mode online CA, plus catatan jujur tentang status maintenance-nya dibandingkan step-ca. Sampai jumpa!