Service Mesh (ASM) menerapkan keamanan percaya nol untuk aplikasi cloud-native dengan memindahkan otentikasi identitas dan otorisasi dari kode aplikasi ke infrastruktur mesh. Anda dapat menetapkan kebijakan keamanan melalui ASM, memperbaruinya kapan saja, dan langsung menerapkannya—tanpa perlu men-deploy ulang aplikasi.
Mengapa percaya nol penting bagi layanan mikro
Layanan mikro menawarkan skalabilitas, kelincahan, penskalaan independen, isolasi logika bisnis, manajemen siklus hidup independen, serta pengembangan terdistribusi yang lebih mudah, tetapi juga memperluas permukaan serangan. Setiap layanan menjadi target potensial. Kubernetes merupakan platform andal untuk meng-host dan meng-orchestrate layanan mikro, namun secara default, layanan dalam kluster Kubernetes berkomunikasi melalui HTTP teks biasa. Keamanan berbasis perimeter tidak cukup untuk melindungi trafik internal—jika penyerang berhasil mengompromikan satu layanan, mereka dapat bergerak lateral ke layanan lain di jaringan.
Percaya nol mengatasi tantangan ini dengan mewajibkan otentikasi eksplisit untuk setiap permintaan dan menerapkan prinsip hak istimewa minimal pada semua akses. Selain kebijakan jaringan Kubernetes yang mengontrol trafik di Lapisan 3, ASM menyediakan otentikasi peer, otentikasi permintaan, kebijakan otorisasi, serta kontrol akses granular berbasis Open Policy Agent (OPA) pada lapisan yang lebih tinggi.
Cara ASM Menerapkan Percaya Nol
ASM mengamankan layanan mikro tanpa memerlukan perubahan pada kode aplikasi. Arsitektur percaya nol didasarkan pada empat pilar:
| Pilar | Fungsinya |
|---|---|
| Workload Identity | Menetapkan identitas unik yang sesuai dengan standar SPIFFE untuk setiap workload. Identitas ini menjadi dasar bagi semua keputusan otentikasi dan otorisasi. |
| Manajemen sertifikat | Menerbitkan sertifikat TLS X.509 yang menyematkan identitas workload, serta secara otomatis memutar sertifikat dan kunci privat. Semua sidecar proxy menggunakan sertifikat ini. |
| Penegakan kebijakan | Mendukung kebijakan Role Based Access Control (RBAC) Istio dan kebijakan otorisasi granular berbasis OPA. |
| Observability | Mengumpulkan log dan metrik eksekusi kebijakan, sehingga Anda dapat menganalisis efektivitas setiap kebijakan. |

Keunggulan dibanding keamanan tingkat aplikasi
Dibandingkan dengan penerapan keamanan dalam kode aplikasi, ASM menawarkan beberapa keunggulan:
| Keunggulan | Deskripsi |
|---|---|
| Manajemen siklus hidup independen | Sidecar proxy dikelola terpisah dari aplikasi. Perbarui kebijakan keamanan tanpa perlu men-deploy ulang kode. |
| Penegakan kebijakan instan | Konfigurasikan atau perbarui kebijakan dan langsung berlaku. |
| Tata kelola keamanan terpusat | Satu lapisan kontrol memungkinkan tim keamanan membuat, mengelola, dan menerapkan kebijakan skala perusahaan tanpa mengharuskan developer mengimplementasikan logika keamanan di setiap layanan. |
| Validasi kredensial bawaan | ASM mendukung otentikasi JSON Web Token (JWT) untuk memvalidasi kredensial pengguna dalam permintaan. |
| Pertahanan berlapis | Terapkan otentikasi identitas dan otorisasi sebagai layanan dalam instans ASM. Layanan-layanan ini mendapat manfaat dari perlindungan ASM: enkripsi dalam transit, otentikasi identitas, penegakan kebijakan, dan validasi kredensial. |
ASM menyediakan manajemen identitas dan akses ketat, enkripsi Transport Layer Security (TLS), otentikasi, otorisasi, serta pencatatan log audit—semuanya siap pakai.
Kemampuan keamanan
ASM mengamankan komunikasi antarlayanan melalui enkripsi end-to-end, otentikasi identitas tingkat layanan, serta kebijakan otorisasi granular.
Identitas workload
ASM menetapkan pengidentifikasi unik untuk setiap layanan mikro yang berjalan dalam mesh. Layanan menggunakan pengidentifikasi ini untuk otentikasi timbal balik dan pengambilan keputusan otorisasi.
Saat mengelola workload dalam kluster Kubernetes, ASM menetapkan identitas layanan berdasarkan token layanan workload tersebut. Identitas layanan ini mematuhi Secure Production Identity Framework for Everyone (SPIFFE) dan menggunakan format berikut:
spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>Lihat identitas workload di Konsol
Masuk ke Konsol ASM. Di panel navigasi sebelah kiri, pilih Service Mesh > Mesh Management.
Pada halaman Mesh Management, klik nama instans ASM. Di panel navigasi sebelah kiri, pilih Mesh Security Center > Workload Identity.
Pada halaman Workload Identity, pilih kluster dari daftar drop-down Data Plane dan namespace dari daftar drop-down Namespace untuk melihat identitas workload.
Otentikasi peer
Otentikasi peer memverifikasi identitas kedua pihak dalam interaksi antarlayanan menggunakan mutual TLS (mTLS) atau otentikasi TLS sisi server. Manajemen siklus hidup sertifikat, seperti rotasi sertifikat otomatis, juga didukung. Perilaku ini bergantung pada layanan mana yang telah disuntikkan sidecar proxy:
| Sidecar injection | Perilaku |
|---|---|
| Client dan server | Enkripsi mTLS diaktifkan untuk seluruh komunikasi. |
| Hanya client | Client mengaktifkan mTLS berdasarkan konfigurasi server. |
| Hanya server | Mode mTLS default adalah permissive: server menerima trafik teks biasa maupun terenkripsi. Jika Anda mengatur mode mTLS ke strict, permintaan dari client tanpa sidecar proxy akan gagal. |
Otentikasi permintaan
Otentikasi permintaan memvalidasi kredensial pengguna akhir atau sistem menggunakan JWT. Saat kebijakan otentikasi permintaan diterapkan pada suatu layanan:
Permintaan dengan JWT valid diizinkan.
Permintaan dengan JWT tidak valid ditolak (HTTP 403).
Permintaan tanpa JWT diizinkan secara default.
Untuk mewajibkan JWT valid pada semua permintaan, gabungkan kebijakan otentikasi permintaan dengan kebijakan otorisasi. Hal ini akan memblokir permintaan dengan JWT tidak valid maupun permintaan tanpa JWT.
Contoh: Siapkan otentikasi JWT untuk suatu layanan
Contoh ini menggunakan aplikasi sampel Bookinfo sebagai layanan target dan Pod sleep sebagai client.
Prasyarat
Deploy aplikasi Bookinfo. Untuk detailnya, lihat Deploy aplikasi dalam instans ASM.
Langkah 1: Deploy sleep client
Buat file
sleep.yamldengan konten berikut:Gunakan kubectl untuk terhubung ke kluster Container Service for Kubernetes (ACK) Anda dan deploy aplikasi sleep:
kubectl apply -f sleep.yaml -n default
Langkah 2: Buat kebijakan otentikasi permintaan
Masuk ke Konsol ASM. Di panel navigasi sebelah kiri, pilih Service Mesh > Mesh Management.
Pada halaman Mesh Management, klik nama instans ASM. Di panel navigasi sebelah kiri, pilih Mesh Security Center > RequestAuthentication. Klik Create.
Definisikan aturan JWT untuk workload
detailsdengan parameter berikut, lalu klik Create. Parameter utama: Nilai JWKS: Untuk informasi lebih lanjut, lihat jwks.json.Parameter Nilai Deskripsi issuer testing@asm.istio.ioPenerbit JWT. audiences (kosong) Biarkan kosong agar semua layanan dapat menggunakan JWT ini. jwks Lihat di bawah JSON Web Key Set yang digunakan untuk memverifikasi tanda tangan JWT. { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}
Langkah 3: Verifikasi kebijakan
Gunakan tool JWT untuk meng-encode JWKS menjadi string JWT. Hasil yang diharapkan:
eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUgKirim permintaan dengan JWT valid: Output yang diharapkan:
200. JWT valid diterima.export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep \ -- curl http://details:9080/details/1 -o /dev/null \ --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n'Kirim permintaan dengan JWT tidak valid: Output yang diharapkan:
403. Token tidak valid ditolak.kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep \ -- curl http://details:9080/details/1 -o /dev/null \ --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n'Kirim permintaan tanpa JWT: Output yang diharapkan:
200. Tanpa JWT, permintaan melewati validasi JWT dan diizinkan.kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep \ -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'
Hasil ini mengonfirmasi bahwa kebijakan bekerja sesuai harapan: JWT valid lolos, JWT tidak valid ditolak, dan permintaan tanpa JWT diizinkan kecuali dibatasi oleh kebijakan otorisasi.
Kebijakan otorisasi
Kebijakan otorisasi mengontrol permintaan mana yang dapat mengakses layanan berdasarkan kriteria seperti identitas sumber, Port, alamat IP, atau klaim JWT. Gunakan kebijakan otorisasi bersama otentikasi permintaan untuk memastikan hanya permintaan terotentikasi yang mencapai layanan Anda.
Kebijakan otorisasi terdiri dari tiga bagian:
| Bidang | Tujuan |
|---|---|
selector | Menentukan workload target untuk kebijakan tersebut. |
action | Menentukan apakah akan ALLOW atau DENY permintaan. |
rules | Menentukan kapan aksi dipicu. Berisi from (sumber permintaan), to (operasi permintaan), dan when (kondisi tambahan). |
Contoh: Wajibkan JWT valid untuk semua permintaan
Contoh ini melanjutkan konfigurasi otentikasi permintaan di atas. Kebijakan otorisasi ditambahkan untuk memblokir permintaan tanpa JWT valid.
Prasyarat
Deploy aplikasi Bookinfo. Untuk detailnya, lihat Deploy aplikasi dalam instans ASM.
Deploy client sleep seperti dijelaskan pada bagian otentikasi permintaan di atas.
Langkah 1: Buat kebijakan otorisasi
Masuk ke Konsol ASM. Di panel navigasi sebelah kiri, pilih Service Mesh > Mesh Management.
Pada halaman Mesh Management, klik nama instans ASM. Di panel navigasi sebelah kiri, pilih Mesh Security Center > AuthorizationPolicy. Klik Create from YAML.
Pilih default dari daftar drop-down Namespace, tempel YAML berikut, lalu klik Create. Kebijakan ini mengizinkan permintaan ke layanan
detailshanya jika principal permintaan cocok dengantesting@secure.istio.io/testing@secure.istio.io—artinya permintaan harus membawa JWT valid yang diterbitkan oleh identitas ini. Untuk informasi lebih lanjut tentang bidang kebijakan otorisasi, lihat Authorization Policy.apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: require-jwt namespace: default spec: action: ALLOW rules: - from: - source: requestPrincipals: - testing@secure.istio.io/testing@secure.istio.io selector: matchLabels: app: details
Langkah 2: Verifikasi kebijakan
Kirim permintaan tanpa JWT:
kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep \
-- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'Output yang diharapkan: 403. Kebijakan otorisasi memblokir permintaan tanpa JWT valid dari testing@secure.istio.io.
Kebijakan OPA
Open Policy Agent (OPA) adalah mesin kebijakan tujuan umum untuk kontrol akses granular. OPA berjalan bersama layanan mikro Anda dan mengevaluasi setiap permintaan terhadap kebijakan Anda sebelum permintaan diproses.
ASM terintegrasi dengan OPA, sehingga Anda dapat mendefinisikan dan memperbarui dinamis kebijakan kontrol akses granular tanpa perlu men-deploy ulang layanan. Untuk detailnya, lihat Perbarui dinamis kebijakan OPA dalam ASM.
Untuk informasi lebih lanjut tentang OPA, kunjungi website Open Policy Agent.
Komponen arsitektur
Arsitektur percaya nol ASM terdiri dari empat komponen yang bekerja sama:
| Komponen | Peran |
|---|---|
| Certificate authority | Mengelola siklus hidup lengkap sertifikat, termasuk penerbitan dan rotasi sertifikat CA. |
| Control plane APIs | Mendistribusikan kebijakan otentikasi, kebijakan otorisasi, dan informasi penamaan aman ke sidecar proxy Envoy. |
| Sidecar proxies | Berperan sebagai titik penegakan kebijakan (PEP) yang mengamankan seluruh trafik yang masuk dan keluar dari setiap layanan. |
| Envoy extensions | Mengumpulkan data telemetri untuk audit dan pemantauan. |
Setiap workload menerima sertifikat TLS X.509 yang menyandikan identitasnya. ASM secara otomatis memutar sertifikat dan kunci privat ini sesuai jadwal reguler. Jika kunci privat dikompromikan, ASM segera menggantinya untuk meminimalkan permukaan serangan.
Contoh kasus penggunaan
Kontrol akses berbasis IP di gerbang masuk. Tambahkan kebijakan otorisasi pada gerbang masuk untuk mengizinkan atau menolak trafik berdasarkan alamat IP sumber, atau integrasikan layanan otorisasi eksternal kustom.
Kontrol akses cross-region untuk aplikasi finansial. Gunakan kebijakan otorisasi untuk melindungi aplikasi multi-bahasa cross-region dari jaringan eksternal. Audit trafik egress melalui gerbang keluar untuk mengontrol layanan pihak ketiga mana yang dapat dijangkau oleh aplikasi Anda.