Belajar Platform Engineer - Zero Trust Platform

#Pendahuluan

Model keamanan lama adalah castle-and-moat: tembok luar (firewall perimeter) dijaga sekuat mungkin, dan siapa pun yang sudah masuk dianggap tepercaya. Di episode 17 kita menyadari bahwa model itu runtuh ketika perimeter sudah bocor — dan di dunia nyata, perimeter selalu bocor. Episode ini membangun zero trust platform: tidak ada yang dipercaya karena lokasinya; setiap request dibuktikan identitasnya, dienkripsi, dan diberi hak paling minimum.

Mengapa ini penting? Serangan modern tidak datang dari luar firewall lagi — mereka datang dari kredensial yang bocor, supply chain, atau insider. Zero trust mengubah pertanyaannya dari "apakah kamu di jaringan kita?" menjadi "apakah identitasmu valid dan apakah kamu boleh melakukan ini?". Platform engineering adalah tempat yang tepat untuk menerapkannya karena ia mengendalikan semua layer sekaligus.

#Tiga Prinsip Zero Trust

1. Verifikasi identitas setiap request — tidak ada "sudah masuk sekali, selamanya percaya". Setiap akses dibuktikan (mTLS, token, device posture).
2. Least privilege — setiap manusia dan service hanya mendapat hak minimum yang dibutuhkan untuk bekerja.
3. Asumsikan sudah dibobol — desain dengan asumsi attacker ada di dalam; segmentasi, monitoring, dan ekses minimal adalah pertahanan keduanya.

#Identity-Aware Access untuk Manusia

Model BeyondCorp (Google) adalah referensi klasik: akses ke aplikasi internal tidak lagi bergantung pada VPN, melainkan pada identity + context — siapa, dari device apa, pada jam berapa, dengan kualitas sinyal apa.

Implementasi praktis di platform:

Hasilnya: aplikasi internal tidak perlu lagi "berada di belakang VPN" untuk aman. Akses bisa di-revoke instan saat developer keluar dari perusahaan — satu klik, bukan hapus dari 15 sistem.

#mTLS by Default: Kunci untuk Service

Untuk komunikasi service-to-service, zero trust butuh mutual TLS (mTLS) — dua arah: server membuktikan diri ke client, client membuktikan diri ke server. Di episode 8 kita memasang service mesh; kini meshlah yang menerapkan zero trust:

• SPIFFE/SPIRE — standar identitas workload. Setiap service mendapat identitas terverifikasi (misal spiffe://example.com/ns/team-payments/sa/payments-api) yang tidak bisa dipalsukan.
• mTLS otomatis — semua traffic antar service terenkripsi dan terautentikasi tanpa mengubah kode aplikasi.

# Contoh otorisasi layer L7 (Istio/Service Mesh)
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payments-api-allow-internal
  namespace: team-payments
spec:
  selector:
    matchLabels:
      app: payments-api
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/team-gateway/sa/api-gw"]
      to:
        - operation:
            methods: ["GET"]

Policy ini berkata: hanya service dari gateway yang boleh GET ke payments-api, dengan identitas terverifikasi. Lokasi jaringan tidak lagi relevan.

#Workload Identity: Service Menjadi First-Class Citizen

Service yang berjalan di cluster perlu akses ke cloud (misal S3, KMS). Zero trust berarti jangan pernah pakai access key bersama. Gunakan workload identity — Kubernetes ServiceAccount dipetakan ke IAM cloud tanpa secret statis:

gcloud iam service-accounts add-iam-policy-binding \
  payments-sa@example.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:example.svc.id.goog[team-payments/payments-api]"

Kredensial dirotasi otomatis oleh platform — tidak ada lagi .env berisi access key yang bocor ke git.

#Least Privilege di Seluruh Layer

#Common Pitfalls

1. mTLS terpasang tapi traffic L7 tidak dibatasi — semua service "terautentikasi" tapi boleh saling akses apa saja; tambahkan AuthorizationPolicy.
2. VPN dihapus sebelum identity-aware proxy siap — developer kehilangan akses dan zero trust ditinggalkan; transisi bertahap.
3. ServiceAccount bersama — identitas jadi tidak bermakna jika 20 workload memakai akun yang sama.
4. Access key statis di environment — kembalinya ke model kredensial permanen; selalu pakai workload identity.
5. Zero trust hanya untuk workload baru — workload lama tetap "terbuka"; buat program migrasi bertahap dengan mTLS strict-mode per namespace.

#Penutup

Inti yang harus dibawa pulang:

• Zero trust = verifikasi setiap request + least privilege + asumsi sudah dibobol.
• Manusia: identity-aware access menggantikan VPN; akses di-revoke instan.
• Service: mTLS + SPIFFE/SPIRE memberi identitas yang tidak bisa dipalsukan.
• Workload identity menggantikan access key statis dengan kredensial yang berotasi otomatis.
• Terapkan bertahap per namespace, dan lengkapi dengan otorisasi L7, bukan sekadar enkripsi.

Di episode 19 selanjutnya kita mengamankan rantai yang membawa kode ke produksi: supply chain security — SBOM, image signing, SLSA, dan vulnerability scanning yang memastikan image yang jalan benar-benar image yang kalian bangun!