All Products
Search
Document Center

Alibaba Cloud Service Mesh:Keamanan percaya nol

Last Updated:Mar 11, 2026

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:

PilarFungsinya
Workload IdentityMenetapkan identitas unik yang sesuai dengan standar SPIFFE untuk setiap workload. Identitas ini menjadi dasar bagi semua keputusan otentikasi dan otorisasi.
Manajemen sertifikatMenerbitkan sertifikat TLS X.509 yang menyematkan identitas workload, serta secara otomatis memutar sertifikat dan kunci privat. Semua sidecar proxy menggunakan sertifikat ini.
Penegakan kebijakanMendukung kebijakan Role Based Access Control (RBAC) Istio dan kebijakan otorisasi granular berbasis OPA.
ObservabilityMengumpulkan log dan metrik eksekusi kebijakan, sehingga Anda dapat menganalisis efektivitas setiap kebijakan.
Zero trust architecture in ASM

Keunggulan dibanding keamanan tingkat aplikasi

Dibandingkan dengan penerapan keamanan dalam kode aplikasi, ASM menawarkan beberapa keunggulan:

KeunggulanDeskripsi
Manajemen siklus hidup independenSidecar proxy dikelola terpisah dari aplikasi. Perbarui kebijakan keamanan tanpa perlu men-deploy ulang kode.
Penegakan kebijakan instanKonfigurasikan atau perbarui kebijakan dan langsung berlaku.
Tata kelola keamanan terpusatSatu lapisan kontrol memungkinkan tim keamanan membuat, mengelola, dan menerapkan kebijakan skala perusahaan tanpa mengharuskan developer mengimplementasikan logika keamanan di setiap layanan.
Validasi kredensial bawaanASM mendukung otentikasi JSON Web Token (JWT) untuk memvalidasi kredensial pengguna dalam permintaan.
Pertahanan berlapisTerapkan 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

  1. Masuk ke Konsol ASM. Di panel navigasi sebelah kiri, pilih Service Mesh > Mesh Management.

  2. Pada halaman Mesh Management, klik nama instans ASM. Di panel navigasi sebelah kiri, pilih Mesh Security Center > Workload Identity.

  3. 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 injectionPerilaku
Client dan serverEnkripsi mTLS diaktifkan untuk seluruh komunikasi.
Hanya clientClient mengaktifkan mTLS berdasarkan konfigurasi server.
Hanya serverMode 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.

Catatan

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

  1. Buat file sleep.yaml dengan konten berikut:

    Klik untuk melihat sleep.yaml

       apiVersion: v1
       kind: ServiceAccount
       metadata:
         name: sleep
       ---
       apiVersion: v1
       kind: Service
       metadata:
         name: sleep
         labels:
           app: sleep
           service: sleep
       spec:
         ports:
         - port: 80
           name: http
         selector:
           app: sleep
       ---
       apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: sleep
       spec:
         replicas: 1
         selector:
           matchLabels:
             app: sleep
         template:
           metadata:
             labels:
               app: sleep
           spec:
             terminationGracePeriodSeconds: 0
             serviceAccountName: sleep
             containers:
             - name: sleep
               image: curlimages/curl
               command: ["/bin/sleep", "3650d"]
               imagePullPolicy: IfNotPresent
               volumeMounts:
               - mountPath: /etc/sleep/tls
                 name: secret-volume
             volumes:
             - name: secret-volume
               secret:
                 secretName: sleep-secret
                 optional: true
  2. 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

  1. Masuk ke Konsol ASM. Di panel navigasi sebelah kiri, pilih Service Mesh > Mesh Management.

  2. Pada halaman Mesh Management, klik nama instans ASM. Di panel navigasi sebelah kiri, pilih Mesh Security Center > RequestAuthentication. Klik Create.

  3. Definisikan aturan JWT untuk workload details dengan parameter berikut, lalu klik Create. Parameter utama: Nilai JWKS: Untuk informasi lebih lanjut, lihat jwks.json.

    ParameterNilaiDeskripsi
    issuertesting@asm.istio.ioPenerbit JWT.
    audiences(kosong)Biarkan kosong agar semua layanan dapat menggunakan JWT ini.
    jwksLihat di bawahJSON 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"}]}

    Request authentication parameters

Langkah 3: Verifikasi kebijakan

  1. 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_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
  2. Kirim 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'
  3. 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'
  4. 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:

BidangTujuan
selectorMenentukan workload target untuk kebijakan tersebut.
actionMenentukan apakah akan ALLOW atau DENY permintaan.
rulesMenentukan 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

Langkah 1: Buat kebijakan otorisasi

  1. Masuk ke Konsol ASM. Di panel navigasi sebelah kiri, pilih Service Mesh > Mesh Management.

  2. Pada halaman Mesh Management, klik nama instans ASM. Di panel navigasi sebelah kiri, pilih Mesh Security Center > AuthorizationPolicy. Klik Create from YAML.

  3. Pilih default dari daftar drop-down Namespace, tempel YAML berikut, lalu klik Create. Kebijakan ini mengizinkan permintaan ke layanan details hanya jika principal permintaan cocok dengan testing@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:

KomponenPeran
Certificate authorityMengelola siklus hidup lengkap sertifikat, termasuk penerbitan dan rotasi sertifikat CA.
Control plane APIsMendistribusikan kebijakan otentikasi, kebijakan otorisasi, dan informasi penamaan aman ke sidecar proxy Envoy.
Sidecar proxiesBerperan sebagai titik penegakan kebijakan (PEP) yang mengamankan seluruh trafik yang masuk dan keluar dari setiap layanan.
Envoy extensionsMengumpulkan 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.