Alibaba Cloud Service Mesh：Tinjauan Keamanan Percaya Nol

Mengapa menggunakan ASM untuk menerapkan keamanan percaya nol?

ASM menyediakan bidang kontrol tunggal untuk menerapkan manajemen identitas dan akses yang ketat, enkripsi Transport Layer Security (TLS), otentikasi dan otorisasi, serta pencatatan audit. Fitur-fitur ini tersedia out-of-the-box, memungkinkan pengembang, administrator sistem, dan tim keamanan jaringan melindungi aplikasi berorientasi mikroservis dengan mudah.

Bagaimana menggunakan sistem percaya nol dalam ASM?

ASM mengurangi permukaan serangan dalam lingkungan cloud-native dan menyediakan kerangka dasar untuk membangun jaringan aplikasi percaya nol. ASM mengadopsi enkripsi ujung-ke-ujung, otentikasi identitas tingkat layanan, dan kebijakan otorisasi granular untuk mengamankan komunikasi layanan-ke-layanan.

ASM menyediakan kemampuan keamanan percaya nol berikut: identitas workload, otentikasi peer, otentikasi permintaan, kebijakan otorisasi, dan kebijakan OPA.

Identitas Workload

Instance ASM memberikan pengenal unik kepada setiap mikroservis yang berjalan di dalamnya. Mikroservis menggunakan pengenal ini untuk berkomunikasi dengan mikroservis lain dalam instance ASM yang sama. Pengenal dapat digunakan dalam otentikasi dua arah untuk mengizinkan atau menolak akses ke layanan serta dalam kebijakan otorisasi.

Saat menggunakan ASM untuk mengelola workload di kluster Kubernetes, ASM menetapkan identitas layanan ke setiap workload berdasarkan token layanan workload.

Identitas layanan dalam ASM sesuai dengan SPIFFE dan berada dalam format berikut: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>.

Anda dapat masuk ke konsol ASM untuk melihat identitas workload layanan yang berada di kluster Kubernetes dalam ASM.

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

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

3. Di bagian atas halaman Workload Identity, pilih ID kluster yang diinginkan dari daftar drop-down Data Plane dan pilih namespace yang diinginkan dari daftar drop-down Namespace untuk melihat identitas workload layanan yang berada di kluster Kubernetes dalam ASM.

Otentikasi Peer

ASM menyediakan dua jenis otentikasi: otentikasi peer dan otentikasi permintaan. Otentikasi peer dapat dilakukan menggunakan otentikasi Mutual TLS saat dua mikroservis berinteraksi satu sama lain.

• Jika proxy sidecar disuntikkan ke klien dan server, enkripsi mTLS diaktifkan untuk komunikasi antar layanan dalam ASM.

• Jika hanya klien yang disuntikkan dengan proxy sidecar, klien mengaktifkan enkripsi mTLS untuk komunikasi berdasarkan konfigurasi server.

• Jika hanya server yang disuntikkan dengan proxy sidecar, mode mTLS default adalah permissive, yang menunjukkan bahwa server dapat menerima lalu lintas teks biasa dan lalu lintas terenkripsi. Jika Anda mengonfigurasi otentikasi peer untuk server dan menyetel mode mTLS ke strict dalam kasus ini, permintaan gagal.

Otentikasi Permintaan

ASM menyediakan dua jenis otentikasi: otentikasi peer dan otentikasi permintaan. ASM memungkinkan pengguna dan sistem berinteraksi dengan mikroservis menggunakan otentikasi permintaan. Umumnya, JWT digunakan untuk mengotentikasi permintaan.

Anda dapat membuat kebijakan otentikasi permintaan untuk mikroservis untuk menerapkan otentikasi berbasis JWT pada permintaan yang masuk. Jika permintaan berisi JWT, kebijakan otentikasi permintaan memeriksa validitas JWT. Mikroservis hanya dapat diakses jika JWT valid. Jika permintaan tidak berisi JWT, permintaan tidak diperiksa, dan mikroservis dapat diakses seperti yang diharapkan.

1. Sebarkan aplikasi Bookinfo yang menerima permintaan. Untuk informasi lebih lanjut, lihat Sebarkan aplikasi dalam kluster ACK yang ditambahkan ke instance ASM.

2. Sebarkan aplikasi sleep yang memulai permintaan.

   1. Gunakan kubectl untuk terhubung ke kluster Container Service for Kubernetes (ACK) berdasarkan informasi dalam file kubeconfig, lalu buat file sleep.yaml.

      Tampilkan file 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. Jalankan perintah berikut untuk menerapkan aplikasi sleep:

      kubectl apply -f sleep.yaml -n default 

3. Buat kebijakan otentikasi permintaan yang memerlukan otentikasi JWT untuk semua permintaan untuk mengakses layanan detail.

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

   2. Di halaman Mesh Management, klik nama instance ASM. Di panel navigasi kiri, pilih Mesh Security Center > RequestAuthentication. Di halaman yang muncul, klik Create.

   3. Di halaman Buat, atur parameter yang ditunjukkan dalam gambar berikut, tentukan aturan JWT untuk workload detail, lalu klik Create.

      

      Berikut ini menjelaskan beberapa parameter:

      • issuer: penerbit JWT. Dalam contoh ini, parameter ini disetel ke testing@asm.istio.io.

      • audiences: audiens JWT. Parameter ini menentukan layanan yang dapat menggunakan JWT untuk mengakses layanan yang diinginkan. Dalam contoh ini, tidak ada audiens yang ditentukan, yang menunjukkan bahwa semua layanan dapat menggunakan JWT untuk mengakses layanan yang diinginkan.

      • jwks: informasi permintaan JWT. Dalam contoh ini, parameter ini disetel ke konten yang ditunjukkan dalam blok kode berikut. Untuk informasi lebih lanjut, lihat jwks.json.

        { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

4. Gunakan Alat JWT untuk mengkodekan informasi permintaan JWT menjadi string JWT.

   { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

   String JWT yang diharapkan setelah pengkodean:

   eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg

5. Verifikasi bahwa kebijakan otentikasi permintaan berlaku seperti yang diharapkan.

   1. Jalankan perintah berikut untuk mengakses layanan detail menggunakan string JWT yang dikodekan:

      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'        

      Nilai 200 dikembalikan, yang menunjukkan bahwa layanan detail diakses seperti yang diharapkan.

   2. Jalankan perintah berikut untuk menggunakan JWT tidak valid untuk mengakses layanan detail:

      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'                              

      Nilai 403 dikembalikan, yang menunjukkan bahwa layanan detail gagal diakses.

   3. Jalankan perintah berikut untuk mengirim permintaan yang tidak berisi token JWT untuk mengakses layanan detail:

      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'

      Nilai 200 dikembalikan, yang menunjukkan bahwa layanan detail diakses seperti yang diharapkan.

      Hasil di atas menunjukkan bahwa permintaan dapat mengakses layanan detail jika permintaan berisi JWT yang valid atau tidak berisi JWT, dan permintaan yang berisi JWT tidak valid tidak dapat mengakses layanan detail. Ini menunjukkan bahwa kebijakan otentikasi permintaan berlaku.

Kebijakan Otorisasi

Anda dapat membuat kebijakan otorisasi untuk mikroservis untuk menentukan bahwa hanya permintaan yang memenuhi persyaratan tertentu yang dapat mengakses mikroservis. Misalnya, Anda dapat menentukan port, alamat IP, dan sumber permintaan yang valid. Untuk contoh ini, gunakan kebijakan otorisasi untuk menentukan bahwa permintaan dapat mengakses layanan tujuan hanya jika permintaan berisi JWT yang diterbitkan oleh penerbit yang ditentukan.

1. Sebarkan aplikasi Bookinfo yang menerima permintaan. Untuk informasi lebih lanjut, lihat Sebarkan aplikasi dalam kluster ACK yang ditambahkan ke instance ASM.

2. Sebarkan aplikasi sleep yang memulai permintaan.

   1. Buat file sleep.yaml yang berisi konten berikut:

      Tampilkan file 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 ACK berdasarkan informasi dalam file kubeconfig, lalu jalankan perintah berikut untuk menerapkan layanan sleep:

      kubectl apply -f sleep.yaml -n default 

3. Buat kebijakan otorisasi.

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

   2. Di halaman Mesh Management, klik nama instance ASM. Di panel navigasi kiri, pilih Mesh Security Center > AuthorizationPolicy. Di halaman yang muncul, klik Create from YAML.

4. Di halaman Create, pilih default dari daftar drop-down Namespace, salin kode YAML berikut ke dalam editor kode, lalu klik Create.

   Untuk informasi lebih lanjut tentang bidang dalam kode YAML, 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

5. Jalankan perintah berikut untuk mengirim permintaan yang tidak berisi JWT untuk mengakses layanan detail:

    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'

   Keluaran yang diharapkan:

   403

   Permintaan yang tidak berisi JWT gagal mengakses layanan detail, yang menunjukkan bahwa kebijakan otorisasi berlaku seperti yang diharapkan. Kebijakan otorisasi menentukan bahwa permintaan dapat mengakses layanan tujuan hanya jika permintaan berisi JWT yang diterbitkan oleh testing@secure.istio.io.

Kebijakan OPA

OPA adalah mesin kebijakan serbaguna yang memungkinkan kontrol akses granular untuk aplikasi Anda. Anda dapat menerapkan OPA sebagai layanan mandiri bersama dengan mikroservis. Untuk melindungi aplikasi, pastikan setiap permintaan ke mikroservis aplikasi diautorisasi sebelum diproses. Mikroservis membuat panggilan API ke OPA untuk memeriksa apakah permintaan tersebut diautorisasi. Untuk informasi lebih lanjut, kunjungi OPA.

ASM terintegrasi dengan OPA. Anda dapat menggunakan OPA untuk mendefinisikan kebijakan kontrol akses guna menerapkan kontrol akses granular pada aplikasi Anda. Anda juga dapat memperbarui kebijakan ini secara dinamis. Untuk informasi lebih lanjut, lihat Perbarui kebijakan OPA secara dinamis dalam ASM.

Ringkasan dan Contoh

Secara keseluruhan, ASM menyediakan komponen peningkat keamanan berikut:

• Infrastruktur yang menawarkan manajemen siklus hidup penuh sertifikat, yang menyederhanakan penerbitan dan rotasi sertifikat CA.

• API bidang kontrol terkelola yang mendistribusikan kebijakan otentikasi, kebijakan otorisasi, dan informasi penamaan keamanan ke proxy Envoy.

• Proxy sidecar yang menggunakan PEP untuk memastikan keamanan instance ASM.

• Ekstensi Envoy yang memungkinkan pengumpulan data telemetri dan audit.

Setiap workload memiliki sertifikat TLS X.509 yang berisi identitas. Setiap proxy sidecar menggunakan sertifikat ini. ASM menyediakan sertifikat ini dan secara berkala merotasinya bersama dengan kunci privat. Jika kunci privat dicuri, ASM segera menggantinya dengan kunci privat baru. Ini mengurangi permukaan serangan.

Contoh

• Kebijakan otorisasi ditambahkan ke gateway ingress untuk menerapkan kontrol akses berbasis IP atau kontrol akses berbasis otorisasi eksternal kustom.

• Seorang pelanggan fintech internet ingin menerapkan kontrol akses pada aplikasi lintas wilayah multi-bahasa. ASM memberikan kebijakan otorisasi kepada pelanggan untuk melindungi aplikasi dari jaringan eksternal. ASM juga mengaudit lalu lintas egress menggunakan gateway egress. Audit lalu lintas egress dan kebijakan otorisasi mengontrol akses aplikasi ke layanan pihak ketiga.