Belajar PKI - Monitoring, Observability & Automation Pipeline

#Pendahuluan

Episode 18 membangun arsitektur multi-CA yang siap produksi: HA untuk step-ca, leader election untuk cert-manager, dan playbook recovery. Tapi ada satu pertanyaan yang menganga: bagaimana kita tahu semuanya sehat? Sertifikat kedaluwarsa biasanya baru disadari saat error TLS muncul di tengah jam sibuk. Infrastruktur sebanyak apa pun tidak berguna jika tidak ada yang mengawasinya.

Episode 19 menutup celah itu dengan dua hal: observability dan automation. Pertama, kita pelajari cara memantau masa berlaku sertifikat, membaca status cert-manager, mengekspos metrik step-ca ke Prometheus, dan menyusun alerting yang benar-benar membantu. Kedua, kita bangun pipeline otomatis — dari Terraform dan Helm, lewat GitOps dengan ArgoCD atau Flux, hingga pipeline yang menerbitkan dan mendeploy sertifikat tanpa sentuhan manual.

#Expiry Monitoring dengan openssl x509

Cara paling sederhana untuk memantau masa berlaku sertifikat adalah openssl x509 -checkend, yang mengembalikan status sukses jika sertifikat masih hidup dalam rentang detik tertentu. Perintah ini bisa di-loop untuk seluruh direktori sertifikat sehingga kita punya sensor sederhana tanpa dependensi apa pun.

for cert in /etc/ssl/certs/*.pem; do
  openssl x509 -checkend 86400 -noout -in "$cert" || echo "segera kedaluwarsa: $cert"
done

Ganti angka 86400 sesuai toleransi: 86400 detik untuk satu hari, 604800 untuk tujuh hari. Cron atau systemd timer menjalankan skrip ini setiap pagi, dan output yang tidak kosong dikirim ke Slack atau email. Untuk pemeriksaan satu sertifikat secara cepat, openssl x509 -enddate -noout -in cert.pem menampilkan tanggal kedaluwarsa secara langsung.

#Status dan Conditions di cert-manager

Jika kalian jalan di Kubernetes, cert-manager sudah menyediakan status yang kaya. Setiap Certificate object punya condition yang menjelaskan apakah sertifikat siap dipakai, sedang diproses, atau gagal. Kondisi seperti Ready dan Issuing, beserta reason seperti CertificateRequestFailed, memberi petunjuk akar masalah tanpa harus membuka log secara manual.

kubectl get certificate -A
kubectl get certificaterequest -A
kubectl describe certificate app-cert

kubectl describe menunjukkan kondisi lengkap, termasuk last transition time dan message dari controller. Kebiasaan yang bagus: simpan output ini ke sistem logging jangka panjang, lalu buat dashboard dari metrik cert-manager. Dengan begitu, sertifikat yang gagal renew bisa terlihat dari grafik sebelum user melapor.

#Metrik step-ca untuk Prometheus

step-ca mengekspos metrik Prometheus di endpoint khusus yang bisa diaktifkan saat startup. Metrik ini mencakup jumlah sertifikat yang diterbitkan, durasi proses, dan status kesehatan server. Taruh endpoint ini di belakang ServiceMonitor jika kalian memakai kube-prometheus-stack, atau scrape langsung jika Prometheus berjalan di luar Kubernetes.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: step-ca
spec:
  endpoints:
    - port: metrics
      path: /metrics
  selector:
    matchLabels:
      app: step-ca

Metrik yang sama juga bisa diambil dengan curl manual untuk debug cepat — misalnya curl -s localhost:9000/metrics untuk melihat snapshot metrik dari instance yang sedang bermasalah. Kunci dari observability bukan sekadar punya metrik, tapi punya kebiasaan memakainya.

#Alerting yang Tepat

Metrik tanpa alerting hanya berakhir di dashboard yang tidak pernah dibuka. Aturan alerting yang baik berfokus pada hal yang butuh tindakan: sertifikat yang hampir kedaluwarsa, rate penerbitan yang melonjak mencurigakan, dan CA yang tidak sehat. Hindari alert yang berisik — alert yang selalu menyala akan diabaikan.

groups:
  - name: pki
    rules:
      - alert: CertificateExpiringSoon
        expr: certificate_expires_in_seconds < 604800
        for: 1h
        labels:
          severity: warning

Tentukan kepemilikan alert sejak awal: siapa yang dihubungi untuk sertifikat aplikasi, siapa untuk root CA, siapa untuk kebijakan. Routing alerting di Alertmanager bisa memisahkan ketiganya ke channel berbeda, sehingga on-call tidak tenggelam oleh notifikasi yang bukan tanggung jawabnya.

#Otomatisasi dengan Terraform

Terraform membawa PKI masuk ke dalam alur Infrastructure as Code. Provider ACME untuk Terraform memungkinkan kalian menerbitkan sertifikat sebagai resource, lengkap dengan lifecycle renewal otomatis. Ini ideal untuk infrastruktur klasik yang belum pakai Kubernetes penuh, atau untuk sertifikat yang harus dijamin keberadaannya sebelum layanan lain di-provision.

resource "acme_registration" "admin" {
  account_key_pem = tls_private_key.reg.private_key_pem
  email_address   = "ops@example.com"
}
 
resource "acme_certificate" "web" {
  account_key_pem           = acme_registration.admin.account_key_pem
  common_name               = "app.example.com"
  dns_challenge {
    provider = "cloudflare"
  }
}

Terraform juga bisa mengelola Helm release cert-manager dan step-ca, sehingga versi, values, dan konfigurasi issuernya tercatat sebagai kode yang bisa di-review. State Terraform adalah bagian dari aset kritikal — simpan di backend remote dengan locking, bukan di laptop.

#GitOps dengan ArgoCD dan Flux

Untuk cluster Kubernetes, GitOps menempatkan repo git sebagai sumber kebenaran. ArgoCD dan Flux terus membandingkan kondisi cluster dengan apa yang ada di repo dan memperbaikinya bila melenceng. Ini berlaku juga untuk sertifikat: Certificate, Issuer, dan ClusterIssuer dideklarasikan di git, lalu diterapkan otomatis ke cluster.

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: pki
spec:
  sourceRef:
    kind: GitRepository
    name: infra
  path: ./pki/production
  prune: true

Kelebihannya besar: setiap perubahan issuer atau kebijakan sertifikat melewati pull request, di-review, lalu di-apply. Jika ada konfigurasi yang salah, GitOps menampilkan drift dan memudahkan rollback ke versi sebelumnya. PKI kalian kini punya jejak audit otomatis tanpa alat tambahan.

#Pipeline Issue dan Deploy

Langkah terakhir adalah menghubungkan semuanya: ketika sebuah layanan baru dibutuhkan sertifikatnya, pipeline menerbitkan, menyimpan, dan mendeploy sertifikat itu secara berurutan tanpa manusia di tengahnya. Untuk lingkungan non-Kubernetes, skrip sederhana sudah cukup; untuk Kubernetes, biarkan cert-manager yang menangani secret dan renewal.

step ca certificate app.example.com app.crt app.key \
  --provisioner admin --kty ec
kubectl create secret tls app-tls --cert=app.crt --key=app.key -o yaml
kubectl apply -f app-tls.yaml
kubectl rollout restart deployment app

Jalur ini menggabungkan kekuatan episode 9 dan 10: step-ca menerbitkan dengan cepat dan murah untuk integrasi, cert-manager menangani renewal di Kubernetes, dan GitOps menjaga konsistensi. Pipeline yang sama bisa dipicu oleh event lain — misalnya saat deploy aplikasi baru, bukan hanya saat sertifikat dibuat.

#Penutup

Episode 19 melengkapi infrastruktur PKI kalian dengan kesadaran dan otomatisasi: expiry monitoring dengan openssl x509 -checkend, status cert-manager yang kaya informasi, metrik step-ca untuk Prometheus, alerting yang disiplin, lalu otomatisasi penuh lewat Terraform, GitOps dengan ArgoCD atau Flux, dan pipeline issue plus deploy yang idempotent.

Inti yang harus dibawa pulang:

• Monitor masa berlaku sertifikat secara rutin dan berikan toleransi yang masuk akal, bukan menunggu error TLS.
• Bacalah kondisi Certificate dan CertificateRequest di cert-manager untuk diagnosis cepat.
• Ekspos metrik step-ca dan scrape dengan Prometheus; buat alert hanya untuk hal yang butuh tindakan.
• Jadikan Terraform dan Helm sebagai kode untuk issuer dan sertifikat, lengkap dengan state yang aman.
• Gunakan GitOps supaya perubahan PKI selalu lewat review dan bisa di-rollback.
• Rancang pipeline issue dan deploy yang idempotent agar bisa dijalankan berulang kali tanpa efek samping.

PKI kalian kini terlihat dan terotomatisasi. Tapi dunia kriptografi terus bergerak. Di episode 20 kita melihat ke depan: post-quantum cryptography dan tren kriptografi modern. Sampai jumpa di sana!