Belajar PKI - Zero Trust & Service Identity

#Pendahuluan

Di episode-episode sebelumnya kalian sudah membangun CA pribadi, mengotomatiskan sertifikat di Kubernetes, dan menjajal berbagai toolkit PKI dari OpenSSL hingga CFSSL. Selama ini sertifikat kita perlakukan sebagai pelengkap: dipasang di service, lalu dilupakan sampai masa berlakunya hampir habis. Pada episode 15 kita membalik perspektif tersebut.

Dalam arsitektur Zero Trust, sertifikat bukan lagi pelengkap. Ia adalah fondasi identitas digital. Prinsipnya sederhana: jangan pernah mempercayai sesuatu hanya karena ia berada di dalam jaringan internal. Setiap permintaan harus diverifikasi, dan setiap service harus membuktikan siapa dirinya sebelum diberi akses.

Roadmap episode ini: kita mulai dari paradigma Zero Trust dan peran mTLS, lalu membedakan workload identity dengan machine identity, melihat bagaimana service mesh seperti Linkerd, Istio, serta Cilium memanfaatkan mTLS, dan menutup dengan SSH PKI memakai step-ca yang kalian kenal di episode 9.

#Zero Trust dan Peran mTLS

Zero Trust lahir dari kegagalan model perimeter lama. Dulu cukup aman di belakang firewall; sekarang server cloud tersebar, karyawan bekerja dari mana saja, dan data berpindah antar region. Model lama menghancurkan keamanan begitu satu lapisan ditembus, karena traffic internal dianggap bersih.

Prinsip Zero Trust yang sering dipakai: never trust, always verify. Tidak ada zona yang otomatis dipercaya. Setiap koneksi diverifikasi identitasnya, otorisasinya, dan kondisi perangkatnya. Di sinilah mTLS bekerja sebagai mekanisme verifikasi antar service.

#mTLS sebagai Fondasi

mTLS alias mutual TLS adalah TLS biasa dengan satu perbedaan besar: dua arah. Server membuktikan identitasnya lewat sertifikatnya, dan klien juga wajib menyerahkan sertifikatnya. Handshake tidak selesai sebelum kedua pihak saling memvalidasi. Kalian sudah membangun alur ini secara manual di episode 7, dan sekarang kita lihat penerapannya dalam skala besar.

Dengan mTLS, keputusan akses bisa diambil lebih cepat: apakah sertifikat diterbitkan oleh CA yang kita percayai, apakah masih berlaku, dan apakah identitas yang tertulis cocok dengan nama service yang dituju. Sertifikat menjadi kartu identitas yang diperiksa setiap kali dua service berkomunikasi.

#Workload Identity vs Machine Identity

Dua istilah yang sering tertukar: machine identity dan workload identity. Machine identity melekat pada perangkat fisik atau virtual, seperti server atau host container. Ia diwakili sertifikat mesin yang panjang umurnya dan umumnya dipasang sekali. Workload identity melekat pada proses atau service tertentu yang berjalan di dalam mesin tersebut.

Perbedaan ini penting karena di dunia container, banyak service berbagi satu mesin. Jika identitas hanya melekat pada mesin, semua service di mesin itu tidak bisa dibedakan. Workload identity memberikan identitas unik per service, sehingga satu pod bisa dirotasi, dihapus, atau dipindah tanpa mengubah identitas service lain.

Sertifikat untuk workload biasanya berumur pendek, dari beberapa jam hingga beberapa hari. Ini membatasi jendela serangan: jika sertifikat bocor, ia tidak lagi berguna setelah kedaluwarsa. Machine identity tetap relevan untuk hal seperti SSH ke mesin, namun workload identity menjadi standar untuk komunikasi antar service.

#Service Mesh: mTLS Otomatis

Menerapkan mTLS manual ke ratusan service adalah pekerjaan raksasa. Service mesh menjawabnya dengan menempatkan sidecar proxy di samping setiap pod. Sidecar menangani TLS, sehingga aplikasi tetap polos dan tidak perlu tahu soal sertifikat. Tiga implementasi yang paling sering dibahas: Linkerd, Istio, dan Cilium.

#Linkerd

Linkerd adalah service mesh yang paling ringan. Ia memakai sertifikat untuk setiap pod dan melakukan mTLS otomatis antar sidecar. Ketika sebuah service memanggil service lain, koneksi melewati dua sidecar yang saling memverifikasi sertifikat masing-masing. Linkerd bisa memanfaatkan CA eksternal seperti step-ca sebagai penyedia identitasnya.

#Istio

Istio lebih besar dan kaya fitur. Ia juga mengaktifkan mTLS antar service, namun menambahkan lapisan otorisasi bernama AuthorizationPolicy. Kombinasi mTLS dan AuthorizationPolicy memungkinkan aturan seperti: hanya service di namespace payment yang boleh memanggil endpoint tertentu. mTLS menjawab pertanyaan siapa, sedangkan policy menjawab apa yang boleh dilakukan.

#Cilium dan SPIRE

Cilium dengan CiliumNetworkPolicy bisa mengaktifkan mTLS dan policy berbasis identitas di level kernel lewat eBPF. Untuk identitas workload, Cilium sering dipasangkan dengan SPIRE. SPIRE adalah implementasi SPIFFE yang memberikan identitas unik kepada setiap workload berbentuk SPIFFE ID, dan menerbitkan SVID berupa sertifikat dengan umur terbatas.

#Sertifikat per Pod dengan SPIFFE

SPIFFE adalah standar untuk workload identity. Setiap workload mendapat SPIFFE ID, misalnya dengan format spiffe://example.org/workload/billing. SPIRE, sebagai implementasinya, memverifikasi kondisi pod lewat berbagai attestor, lalu menerbitkan SVID yang berupa sertifikat X.509 pendek umur.

Keuntungan utama SPIFFE terletak pada konsistensi. Berapa pun jumlah service mesh, selama semuanya memahami SPIFFE, identitas antar workload bisa saling diverifikasi tanpa konversi manual. Inilah alasan Cilium, Istio, dan Linkerd semuanya mendukung atau bisa dihubungkan ke SPIFFE.

apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSPIFFEID
metadata:
  name: billing-workload
spec:
  spiffeIDTemplate: spiffe://example.org/workload/billing
  podSelector:
    matchLabels:
      app: billing

Contoh resource di atas meminta SPIRE memberikan SPIFFE ID kepada semua pod berlabel app: billing. SPIRE menangani pembuatan sertifikat, distribusi ke pod, dan perpanjangan otomatis sebelum kedaluwarsa. Aplikasi cukup membaca SVID dari trust domain yang disediakan.

#SSH PKI dengan step-ca

Zero Trust tidak berhenti di traffic HTTP. Akses administratif seperti SSH juga butuh identitas yang dikelola dengan baik. Kebanyakan tim masih memakai static keys: satu key public disalin ke authorized_keys, dipakai bertahun-tahun, dan hilang kendali ketika karyawan keluar. SSH PKI menggantikan model ini sepenuhnya.

Dengan SSH PKI, CA menandatangani sertifikat untuk setiap host dan setiap user. Server tidak lagi menyimpan daftar public key. Ia cukup mempercayai satu CA public key. Client certificate diberikan masa berlaku pendek, dan ketika kedaluwarsa user harus meminta yang baru lewat alur otomatis.

#Sertifikat Host dan User

step-ca dari episode 9 mendukung SSH secara native. Kalian tinggal menginisialisasi CA dengan opsi SSH, dan step-ca akan membuat key pair untuk host CA dan user CA.

step ca init \
  --name "Homelab Internal CA" \
  --ssh \
  --dns ca.internal \
  --address ":443"

Setelah itu, sertifikat host dan user bisa diterbitkan dengan perintah yang hampir sama.

step ssh certificate host server01.internal \
  host/server01.internal-ssh.pub \
  host/server01.internal-ssh.crt

step ssh certificate user arman \
  user/arman-ssh.pub \
  user/arman-ssh.crt

Perintah step ssh certificate host menandatangani sertifikat untuk mesin, sedangkan step ssh certificate user menandatangani untuk manusia. Setiap sertifikat membawa masa berlaku, principal, dan batasan lain yang ditulis CA.

#Short-Lived Certificate untuk Host dan User

Keuntungan terbesar SSH PKI adalah durasi sertifikat yang pendek. Bandingkan: static key berlaku tanpa batas sampai seseorang mencabutnya secara manual. Sertifikat SSH bisa dibuat hanya berlaku 12 jam, sehingga bocornya sertifikat sore hari sudah tidak berguna keesokan paginya.

step-ca bahkan menyediakan perintah untuk memperbarui sertifikat. User cukup login ulang, dan otomatisasi renew bisa dipasang di sisi client.

step ssh renew user/arman-ssh.crt \
  --expires-in 24h

step ssh renew memperpanjang masa berlaku sertifikat selama masih memiliki kredensial yang sah. Di server, opsi TrustedUserCAKeys memberitahu sshd CA mana yang dianggap tepercaya, sehingga host tidak perlu mengelola daftar key manual.

#Penutup

Episode 15 membawa kalian dari paradigma lama ke pola pikir Zero Trust. Kalian memahami peran mTLS sebagai fondasi verifikasi dua arah, membedakan workload identity dengan machine identity, melihat bagaimana Linkerd, Istio, dan Cilium memanfaatkan mTLS serta SPIFFE untuk identitas per pod, dan menutup dengan SSH PKI yang menggantikan static keys dengan sertifikat berumur pendek.

Inti yang harus dibawa pulang:

• Zero Trust menempatkan sertifikat sebagai fondasi identitas, bukan pelengkap.
• mTLS memverifikasi dua arah dan menjadi tulang punggung komunikasi antar service.
• Workload identity melekat pada service dan berumur pendek, berbeda dengan machine identity.
• Service mesh seperti Linkerd, Istio, dan Cilium mengotomatiskan mTLS tanpa mengubah aplikasi.
• SPIFFE dan SPIRE memberikan identitas per pod yang konsisten antar platform.
• SSH PKI dengan step-ca menggantikan static keys menjadi sertifikat short-lived yang mudah dirotasi.

Di episode 16 kita masuk ke ranah governance. Kalian akan belajar security best practices dan compliance: bagaimana merancang root CA offline, mengelola intermediate online, melakukan key rotation, sampai memahami kerangka audit seperti PCI DSS, SOC 2, NIST, dan FIPS 140-3. Sampai jumpa!