Cert-Manager di Kubernetes: Panduan Pengaturan Lengkap untuk Manajemen Sertifikat TLS Otomatis

Cert-Manager adalah kontroler Kubernetes open-source yang sepenuhnya mengotomatiskan siklus hidup sertifikat TLS — mulai dari penerbitan awal melalui validasi dan pembaruan — dengan mengintegrasikan langsung dengan otoritas sertifikat seperti Let's Encrypt, HashiCorp Vault, dan sistem PKI pribadi. Ini menghilangkan alur kerja sertifikat manual dengan memperlakukan sertifikat sebagai sumber daya Kubernetes asli, dikelola secara deklaratif melalui Custom Resource Definitions (CRDs).

Untuk setiap kluster Kubernetes produksi, sertifikat TLS yang kedaluwarsa atau salah konfigurasi adalah salah satu penyebab paling umum dari downtime yang tidak direncanakan. Cert-Manager mengatasi hal ini dengan terus merekonsiliasi status sertifikat, secara otomatis memperbarui kredensial sebelum kedaluwarsa, dan menyimpan materi kunci yang dihasilkan dalam Kubernetes Secrets yang dapat segera dikonsumsi oleh kontroler Ingress dan beban kerja.

Mengapa Cert-Manager Adalah Standar untuk Otomatisasi TLS Kubernetes

Sebelum Cert-Manager menjadi solusi de facto, tim-tim baik membuat skrip pembaruan certbot pada node individual, merotasi sertifikat secara manual di seluruh namespace, atau mengandalkan integrasi khusus penyedia cloud yang menciptakan ketergantungan vendor. Cert-Manager menyatukan semua pendekatan ini di bawah satu control plane yang native Kubernetes.

Keunggulan utama dibandingkan pendekatan ad-hoc:

• Manajemen deklaratif: Maksud sertifikat dinyatakan sebagai manifes YAML, dikontrol versinya bersama kode aplikasi.
• Rekonsiliasi otomatis: Loop kontroler mendeteksi penyimpangan antara status sertifikat yang diinginkan dan aktual serta memperbaikinya tanpa masukan manusia.
• Dukungan multi-issuer: Satu kluster dapat secara bersamaan menggunakan Let's Encrypt untuk layanan yang menghadap publik, CA internal untuk mTLS service-mesh, dan HashiCorp Vault untuk beban kerja yang sensitif terhadap rahasia.
• Jejak audit: Setiap objek CertificateRequest disimpan di API Kubernetes, memberi Anda riwayat penerbitan yang lengkap.

Menjalankan Kubernetes pada platform VPS Hosting dengan penyimpanan berbasis NVMe dan akses root penuh memberi Anda kontrol yang diperlukan untuk mengonfigurasi resolver DNS kustom, mengelola aturan firewall untuk tantangan ACME HTTP-01, dan menginstal CRD tingkat kluster tanpa batasan — semua prasyarat untuk deployment Cert-Manager tingkat produksi.

Arsitektur Inti: Cara Kerja Cert-Manager Secara Internal

Memahami arsitektur internal Cert-Manager mencegah kesalahan konfigurasi dan membantu Anda men-debug kegagalan penerbitan dengan cepat.

Mesin Status Siklus Hidup Sertifikat

Cert-Manager mengelola sertifikat melalui mesin status yang deterministik. Setiap sumber daya Certificate bertransisi melalui status berikut:

1. Pending — Objek Certificate ada tetapi tidak ada CertificateRequest yang valid telah dipenuhi.
2. Issuing — Sebuah CertificateRequest telah dibuat dan dikirimkan ke issuer yang dikonfigurasi.
3. Ready — Sertifikat yang valid dan belum kedaluwarsa disimpan dalam Secret Kubernetes yang direferensikan.
4. Renewal Pending — Sertifikat berada dalam jendela renewBefore (default: 30 hari sebelum kedaluwarsa) dan CertificateRequest baru sedang diproses.

Kontroler memantau semua objek Certificate di seluruh kluster dan terus merekonsiliasi statusnya. Jika Secret dihapus secara manual, Cert-Manager mendeteksi sumber daya yang hilang dan segera memicu penerbitan ulang — perilaku penyembuhan diri yang kritis yang mencegah pemadaman yang tidak disengaja.

Komponen CRD Inti

Sumber daya Order dan Challenge dibuat secara otomatis oleh issuer ACME — Anda jarang berinteraksi langsung dengannya, tetapi memeriksanya adalah jalur debugging utama ketika penerbitan terhenti.

Penyimpanan Sertifikat dan Format Secret

Setelah diterbitkan, Cert-Manager menulis tiga kunci data ke dalam Secret Kubernetes target:

• tls.crt — Rantai sertifikat lengkap (leaf + intermediates), dikodekan PEM.
• tls.key — Kunci privat, dikodekan PEM.
• ca.crt — Sertifikat CA penerbit (diisi untuk CA internal; mungkin kosong untuk issuer ACME).

Kontroler Ingress, service mesh, dan pod aplikasi memasang Secret ini secara langsung. Formatnya kompatibel dengan NGINX, Traefik, Istio, Linkerd, dan sebagian besar konsumen TLS native Kubernetes lainnya.

Issuer yang Didukung dan Kapan Menggunakan Masing-masing

ACME (Let's Encrypt dan Alternatif)

Protokol ACME adalah jalur penerbitan yang paling umum. Cert-Manager mengimplementasikan klien ACME RFC 8555 penuh, mendukung endpoint staging dan produksi.

Tantangan HTTP-01: Cert-Manager sementara menyajikan token di http://<domain>/.well-known/acme-challenge/<token>. Ini mengharuskan domain untuk menyelesaikan ke IP yang dapat dijangkau secara publik pada port 80. Ini berfungsi untuk sertifikat domain tunggal dan SAN tetapi tidak dapat menerbitkan sertifikat wildcard.

Tantangan DNS-01: Cert-Manager membuat catatan TXT _acme-challenge.<domain> melalui API penyedia DNS. Ini berfungsi di balik firewall, mendukung sertifikat wildcard (*.example.com), dan diperlukan untuk kluster mana pun yang tidak langsung terekspos ke internet. Penyedia DNS yang didukung meliputi Cloudflare, Route53, Google Cloud DNS, Azure DNS, dan banyak lainnya melalui webhook solver.

HashiCorp Vault

Issuer Vault terintegrasi dengan mesin rahasia PKI Vault. Ini adalah pilihan yang disukai untuk:

• mTLS layanan mikro internal di mana sertifikat harus berumur pendek (jam, bukan bulan).
• Lingkungan dengan persyaratan penjagaan kunci yang ketat di mana kunci privat tidak boleh meninggalkan Vault.
• Rotasi sertifikat otomatis yang terikat dengan sistem pembaruan lease Vault.

Issuer Self-Signed dan CA

Issuer SelfSigned menghasilkan sertifikat yang ditandatangani oleh kunci privat sertifikat itu sendiri — berguna untuk mem-bootstrap CA root dalam kluster. Issuer CA menggunakan Secret Kubernetes yang berisi pasangan kunci CA untuk menandatangani sertifikat, menjadikannya cocok untuk lingkungan pengembangan internal dan PKI service mesh.

Venafi

Integrasi Venafi menargetkan lingkungan enterprise dengan penegakan kebijakan sertifikat terpusat, audit kepatuhan, dan integrasi dengan modul keamanan perangkat keras (HSM).

Cert-Manager vs. Pendekatan Otomatisasi TLS Alternatif

Untuk tim yang menjalankan Kubernetes pada Server Dedicated atau VPS, Cert-Manager adalah satu-satunya pendekatan yang sekaligus native Kubernetes, mendukung semua CA utama, dan tidak memerlukan intervensi manual berkelanjutan.

Menginstal Cert-Manager: Pengaturan Siap Produksi

Prasyarat

• Kubernetes 1.22+ (1.26+ direkomendasikan untuk stabilitas CRD penuh)
• kubectl dikonfigurasi dengan hak istimewa cluster-admin
• Helm 3.x terinstal
• Domain terdaftar dengan akses manajemen DNS (untuk DNS-01) atau IP ingress yang dapat dijangkau secara publik (untuk HTTP-01)

Jika Anda mengelola domain sendiri, Registrasi Domain melalui penyedia yang mengekspos API sangat direkomendasikan — ini memungkinkan pemecahan tantangan DNS-01 yang sepenuhnya otomatis tanpa intervensi manual.

Langkah 1: Instal CRD dan Kontroler Cert-Manager

Metode instalasi produksi yang direkomendasikan menggunakan Helm dengan CRD yang dikelola secara terpisah untuk menghindari konflik upgrade Helm:

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io
helm repo update

# Install Cert-Manager with CRDs included
helm install cert-manager jetstack/cert-manager 
  --namespace cert-manager 
  --create-namespace 
  --version v1.14.5 
  --set installCRDs=true 
  --set global.leaderElection.namespace=cert-manager

Verifikasi semua tiga pod inti berjalan sebelum melanjutkan:

kubectl get pods --namespace cert-manager

Output yang diharapkan:

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-xxxxxxxxx-xxxxx              1/1     Running   0          60s
cert-manager-cainjector-xxxxxxxxx-xxxxx   1/1     Running   0          60s
cert-manager-webhook-xxxxxxxxx-xxxxx      1/1     Running   0          60s

cainjector menyuntikkan data bundle CA ke dalam konfigurasi webhook. webhook memvalidasi dan memutasi objek CRD Cert-Manager — jika tidak berjalan, semua operasi kubectl apply pada sumber daya Cert-Manager akan gagal.

Langkah 2: Konfigurasikan ClusterIssuer untuk Let's Encrypt

Selalu mulai dengan lingkungan staging Let's Encrypt untuk menghindari batas rate produksi (50 sertifikat per domain terdaftar per minggu):

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-staging-account-key
    solvers:
      - http01:
          ingress:
            class: nginx

Setelah sertifikat staging berhasil diterbitkan, buat issuer produksi:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
      - http01:
          ingress:
            class: nginx

Terapkan kedua manifes:

kubectl apply -f clusterissuer-staging.yaml
kubectl apply -f clusterissuer-prod.yaml

Verifikasi kesiapan issuer:

kubectl describe clusterissuer letsencrypt-prod

Kolom Status.Conditions harus menampilkan Ready: True. Jika menampilkan False, pendaftaran akun ACME gagal — periksa alamat email dan konektivitas jaringan dari pod cert-manager.

Langkah 3: Minta Sertifikat Secara Eksplisit

Anda dapat meminta sertifikat baik dengan membuat sumber daya Certificate secara langsung atau dengan memberi anotasi pada sumber daya Ingress. Pendekatan Certificate eksplisit memberi Anda lebih banyak kontrol:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
  namespace: production
spec:
  secretName: example-com-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: example.com
  dnsNames:
    - example.com
    - www.example.com
  duration: 2160h    # 90 days (Let's Encrypt default)
  renewBefore: 720h  # Renew 30 days before expiry

Terapkan dan pantau penerbitan:

kubectl apply -f certificate.yaml
kubectl describe certificate example-com-tls -n production

Pantau objek CertificateRequest dan Order untuk status terperinci:

kubectl get certificaterequest -n production
kubectl describe order -n production

Langkah 4: Metode Anotasi Ingress (Disederhanakan)

Untuk tim yang menggunakan NGINX Ingress Controller, Cert-Manager dapat dipicu secara otomatis melalui anotasi — tidak diperlukan manifes Certificate terpisah:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: production
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - example.com
        - www.example.com
      secretName: example-com-tls-secret
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: example-service
                port:
                  number: 80

Cert-Manager mendeteksi anotasi dan secara otomatis membuat sumber daya Certificate yang sesuai. Ini adalah pola paling umum dalam alur kerja GitOps.

Pola Konfigurasi Lanjutan

Sertifikat Wildcard dengan DNS-01 (Contoh Cloudflare)

Sertifikat wildcard memerlukan validasi DNS-01. Pertama, buat Secret yang berisi token API Cloudflare Anda:

kubectl create secret generic cloudflare-api-token 
  --from-literal=api-token=<YOUR_CLOUDFLARE_API_TOKEN> 
  --namespace cert-manager

Konfigurasikan ClusterIssuer dengan solver DNS-01:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod-dns
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-dns-account-key
    solvers:
      - dns01:
          cloudflare:
            apiTokenSecretRef:
              name: cloudflare-api-token
              key: api-token

Minta sertifikat wildcard:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-example-com
  namespace: production
spec:
  secretName: wildcard-example-com-tls
  issuerRef:
    name: letsencrypt-prod-dns
    kind: ClusterIssuer
  dnsNames:
    - "*.example.com"
    - example.com

Jebakan kritis: Secret yang berisi kredensial penyedia DNS harus berada di namespace cert-manager saat direferensikan oleh ClusterIssuer. Jika Anda menempatkannya di namespace lain, kontroler tidak dapat membacanya dan penerbitan akan gagal secara diam-diam. Periksa log kontroler cert-manager dengan kubectl logs -n cert-manager deploy/cert-manager jika tantangan terhenti.

PKI Internal dengan CA Issuer

Untuk mTLS layanan-ke-layanan dalam kluster, issuer CA yang didukung oleh root self-signed lebih tepat daripada ACME:

# Step 1: Create a self-signed root CA certificate
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-root
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: internal-root-ca
  namespace: cert-manager
spec:
  isCA: true
  commonName: internal-root-ca
  secretName: internal-root-ca-secret
  issuerRef:
    name: selfsigned-root
    kind: ClusterIssuer
---
# Step 2: Create a CA issuer backed by the root certificate
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: internal-ca-issuer
spec:
  ca:
    secretName: internal-root-ca-secret

Layanan sekarang dapat meminta sertifikat berumur pendek dari internal-ca-issuer untuk mTLS tanpa ketergantungan CA eksternal apa pun.

Mengonfigurasi renewBefore untuk Lingkungan Keamanan Tinggi

renewBefore default 30 hari sesuai untuk sertifikat Let's Encrypt 90 hari. Untuk sertifikat internal berumur pendek (mis., validitas 24 jam), atur renewBefore ke sebagian kecil dari total durasi:

spec:
  duration: 24h
  renewBefore: 8h

Cert-Manager akan mulai memperbarui 8 jam sebelum kedaluwarsa, memberi kontroler tiga jendela pembaruan dalam masa hidup sertifikat 24 jam — margin keamanan kritis jika kluster mengalami ketidaktersediaan server API yang sementara.

Men-debug Kegagalan Cert-Manager yang Umum

Sertifikat Terhenti dalam Status “Issuing”

# Check the Certificate status
kubectl describe certificate <name> -n <namespace>

# Check the associated CertificateRequest
kubectl describe certificaterequest -n <namespace>

# Check the ACME Order
kubectl describe order -n <namespace>

# Check the Challenge
kubectl describe challenge -n <namespace>

# Check controller logs
kubectl logs -n cert-manager deploy/cert-manager --tail=100

Penyebab utama yang umum:

• Kegagalan HTTP-01: Kontroler Ingress tidak merutekan lalu lintas /.well-known/acme-challenge/ dengan benar. Verifikasi objek Ingress tantangan dibuat dan port 80 dapat dijangkau dari internet. Firewall pada host harus mengizinkan TCP/80 masuk.
• Kegagalan DNS-01: Token API penyedia DNS memiliki izin yang tidak memadai, atau propagasi DNS belum selesai. Server validasi Let's Encrypt mungkin mengkueri resolver yang berbeda dari DNS lokal Anda — penundaan propagasi 60–120 detik adalah normal.
• Batas rate terlampaui: Let's Encrypt memberlakukan 5 percobaan validasi yang gagal per domain per jam. Setelah mencapai batas ini, Anda harus menunggu sebelum mencoba lagi. Selalu uji dengan endpoint staging terlebih dahulu.
• Webhook tidak siap: Jika pod webhook cert-manager tidak berjalan, semua operasi CRD akan gagal dengan kesalahan koneksi ditolak. Pastikan layanan webhook memiliki endpoint yang valid.

Memverifikasi Sertifikat yang Diterapkan

# Check the Secret contents
kubectl get secret example-com-tls-secret -n production -o jsonpath='{.data.tls.crt}' | base64 -d | openssl x509 -noout -text

# Check expiry date specifically
kubectl get secret example-com-tls-secret -n production -o jsonpath='{.data.tls.crt}' | base64 -d | openssl x509 -noout -enddate

Daftar Periksa Penguatan Produksi

Menerapkan Cert-Manager di lingkungan produksi memerlukan lebih dari sekadar instalasi Helm default. Terapkan langkah-langkah penguatan ini sebelum go live:

• Batas sumber daya: Atur requests dan limits CPU dan memori pada semua tiga pod Cert-Manager untuk mencegah persaingan sumber daya pada node bersama.
• Audit RBAC: Cert-Manager memerlukan izin RBAC yang luas. Tinjau objek ClusterRole yang terinstal dan batasi ke minimum yang diperlukan untuk jenis issuer Anda.
• Namespace terpisah: Selalu deploy Cert-Manager ke dalam namespace cert-manager sendiri, terisolasi dari beban kerja aplikasi.
• Pemantauan: Ekspos endpoint metrik Prometheus Cert-Manager (--metrics-listen-address) dan beri peringatan pada certmanager_certificate_expiration_timestamp_seconds untuk menangkap kegagalan pembaruan sebelum berdampak pada layanan.
• Cadangkan status CRD: Sertakan objek Certificate, ClusterIssuer, dan Issuer dalam strategi pencadangan kluster Anda. Kehilangan manifes ini setelah peristiwa pemulihan bencana berarti membuat ulang semua konfigurasi sertifikat secara manual.
• Validasi staging: Jangan pernah menerbitkan sertifikat pertama Anda terhadap endpoint ACME produksi. Pelanggaran batas rate dapat memblokir domain Anda hingga satu minggu.

Jika Anda menjalankan beberapa kluster Kubernetes — misalnya, memisahkan beban kerja staging dan produksi — Panel Kontrol VPS dapat menyederhanakan manajemen siklus hidup kluster dan memberi Anda antarmuka terpadu untuk menyediakan infrastruktur dasar yang dijalankan setiap kluster.

Untuk beban kerja yang memerlukan inferensi yang dipercepat GPU atau penyajian ML di balik endpoint yang diterminasi TLS, pola Cert-Manager yang sama berlaku pada infrastruktur GPU Hosting, di mana manajemen sertifikat otomatis sama pentingnya untuk mengamankan endpoint API model.

Matriks Keputusan Praktis: Memilih Issuer yang Tepat

Poin-poin Utama

• Instal Cert-Manager menggunakan Helm dengan installCRDs=true dan selalu validasi terhadap endpoint ACME staging sebelum beralih ke produksi.
• Gunakan ClusterIssuer untuk kluster multi-namespace; gunakan Issuer yang tercakup namespace hanya ketika Anda memerlukan isolasi CA per tim.
• DNS-01 sangat diperlukan untuk sertifikat wildcard dan untuk kluster yang tidak dapat dijangkau langsung dari internet pada port 80.
• Kolom renewBefore tidak opsional dalam produksi — atur ke setidaknya sepertiga dari total duration sertifikat.
• Ketika penerbitan terhenti, jalur debugging selalu: Certificate → CertificateRequest → Order → Challenge → log kontroler.
• Kredensial API penyedia DNS yang direferensikan oleh ClusterIssuer harus berada di namespace cert-manager, bukan di namespace aplikasi.
• Pantau certmanager_certificate_expiration_timestamp_seconds di Prometheus dan beri peringatan — kegagalan pembaruan yang diam adalah mode kegagalan yang paling berbahaya.
• Cadangkan manifes Certificate dan ClusterIssuer Anda sebagai bagian dari rencana pemulihan bencana.

Pertanyaan yang Sering Diajukan

Apa perbedaan antara Issuer dan ClusterIssuer di Cert-Manager?

Issuer tercakup namespace dan hanya dapat menerbitkan sertifikat dalam namespace tempat ia didefinisikan. ClusterIssuer berskala seluruh kluster dan dapat direferensikan oleh sumber daya Certificate di namespace mana pun. Untuk sebagian besar kluster produksi, ClusterIssuer adalah pilihan yang tepat kecuali Anda memerlukan isolasi CA tingkat namespace yang ketat.

Mengapa sertifikat Cert-Manager saya terhenti dalam status “Issuing”?

Periksa objek Order dan Challenge di namespace yang sama menggunakan kubectl describe. Penyebab paling umum adalah: port 80 diblokir oleh firewall (HTTP-01), kredensial API DNS yang salah atau penundaan propagasi (DNS-01), batas rate Let's Encrypt terlampaui, atau pod webhook cert-manager tidak berjalan. Selalu periksa log kontroler dengan kubectl logs -n cert-manager deploy/cert-manager.

Bisakah Cert-Manager menerbitkan sertifikat wildcard dari Let's Encrypt?

Ya, tetapi hanya menggunakan jenis tantangan DNS-01. HTTP-01 tidak dapat memvalidasi domain wildcard. Anda harus mengonfigurasi integrasi penyedia DNS (Cloudflare, Route53, dll.) dalam konfigurasi solver ClusterIssuer Anda dan memastikan kredensial API memiliki izin untuk membuat catatan TXT pada domain target.

Bagaimana Cert-Manager menangani pembaruan sertifikat secara otomatis?

Kontroler Cert-Manager terus membandingkan kedaluwarsa setiap objek Certificate dengan waktu saat ini. Ketika validitas yang tersisa turun di bawah ambang renewBefore (default: 30 hari), kontroler membuat CertificateRequest baru, menyelesaikan tantangan ACME, dan secara atomik mengganti isi Secret target — semua tanpa memulai ulang pod yang mengonsumsi sertifikat. Pod yang memasang Secret sebagai volume akan melihat sertifikat yang diperbarui pada siklus sinkronisasi kubelet berikutnya.

Apakah Cert-Manager cocok untuk mengamankan komunikasi layanan-ke-layanan internal, bukan hanya HTTPS publik?

Ya. Menggunakan issuer CA atau issuer HashiCorp Vault, Cert-Manager dapat menerbitkan sertifikat berumur pendek untuk mTLS internal antara layanan mikro. Ini adalah pola umum dalam deployment service mesh di mana setiap beban kerja memerlukan sertifikat identitas unik. Kolom duration dan renewBefore memungkinkan sertifikat berumur sesingkat menit, dengan rotasi yang sepenuhnya otomatis.