Kebijakan otorisasi dan keamanan jaringan sekitar

Halaman ini menunjukkan cara membuat kebijakan otorisasi di jaringan ambient.

Prasyarat

Sebelum dapat menyelesaikan langkah-langkah dalam dokumen ini, Anda harus memenuhi kondisi berikut:

• Cluster GKE yang berjalan dengan jaringan ambient Cloud Service Mesh diaktifkan.
• Namespace yang terdaftar dalam ambient networking (misalnya, ambient-test) dengan contoh workload klien dan server yang di-deploy.
• Mutual TLS (mTLS) diaktifkan antara workload klien dan server menggunakan GCPServerTLSPolicy (dengan mtlsMode: Strict) dan GCPClientTLSPolicy. Aturan GCPAuthzPolicy berbasis identitas yang cocok dengan CLIENT_CERT_URI_SAN memerlukan mTLS aktif untuk mengekstrak identitas SPIFFE klien.

Untuk penyiapan lingkungan yang mendetail, lihat Menyiapkan Ambient Networking GKE.

Kebijakan tolak secara default

Secara default, GKE Ambient Authorization Policy API mengizinkan semua traffic kecuali jika dibatasi oleh kebijakan, yang sesuai dengan perilaku NetworkPolicy Kubernetes standar.

Tindakan DENY_BY_DEFAULT memungkinkan Anda mengubah perilaku default ini. Saat diterapkan ke namespace, kebijakan ini memblokir semua traffic ke workload di namespace tersebut, kecuali jika diizinkan secara eksplisit oleh kebijakan ALLOW.

Halaman ini menunjukkan cara mengonfigurasi dan menggunakan DENY_BY_DEFAULT di Cloud Service Mesh untuk menetapkan postur aman secara default untuk workload Anda.

Batasan

Sebelum menerapkan kebijakan DENY_BY_DEFAULT, perhatikan batasan berikut:

• Anda hanya dapat membuat satu kebijakan DENY_BY_DEFAULT per namespace.
• Kebijakan dengan tindakan DENY_BY_DEFAULT tidak dapat memiliki aturan yang ditentukan.
• Gunakan tindakan ini untuk menetapkan matchLabels: {} dasar di seluruh namespace untuk menargetkan semua Pod. Anda tidak dapat menggunakan DENY_BY_DEFAULT untuk pembatasan per Pod.

Menyiapkan kebijakan otorisasi tolak secara default

Untuk menetapkan dasar pengukuran tolak secara default di seluruh namespace dan secara selektif mengizinkan akses ke workload tertentu, ikuti langkah-langkah berikut:

1. Buat dan terapkan GCPAuthzPolicy dengan tindakan yang ditetapkan ke DENY_BY_DEFAULT ke namespace Anda.

   cat <<EOF > deny-by-default-policy.yaml && kubectl apply -f deny-by-default-policy.yaml
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzPolicy
   metadata:
     name: deny-by-default-authz
     namespace: ambient-test
   spec:
     action: DENY_BY_DEFAULT
     enforcementLevel: L4
     targetRefs:
     - group: ""
       kind: Pod
       selector:
         matchLabels: {}
   EOF
   

   Outputnya mirip dengan:

    gcpauthzpolicy.networking.gke.io/deny-by-default-authz created
   

   Kebijakan ini memblokir semua traffic masuk (Timur-Barat dan ingress) ke workload di namespace ambient-test secara default. Kebijakan ini tidak membatasi traffic keluar yang berasal dari workload di namespace.

2. Untuk mengizinkan traffic secara selektif, buat dan terapkan kebijakan ALLOW:

   cat <<EOF > allow-policy.yaml && kubectl apply -f allow-policy.yaml
   apiVersion: networking.gke.io/v1
   kind: GCPAuthzPolicy
   metadata:
     name: allow-client-to-server
     namespace: ambient-test
   spec:
     action: ALLOW
     enforcementLevel: L4
     targetRefs:
     - group: ""
       kind: Pod
       selector:
         matchLabels:
           app: server
     rules:
     - from:
         sources:
         - principals:
           - principalSelector: CLIENT_CERT_URI_SAN
             principal:
               type: Exact
               value: spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client
   EOF
   

   Ganti PROJECT_ID dengan project ID Anda.

   Penerapan kebijakan dapat memerlukan waktu hingga tiga menit setelah pengontrol menerimanya. Tunggu tiga menit sebelum melanjutkan.

3. Uji konektivitas dari klien ke server. Permintaan ini akan berhasil karena cocok dengan kebijakan ALLOW.

   kubectl exec -it deploy/client -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local
   

4. Uji konektivitas dari server ke server itu sendiri (atau workload lain tanpa kebijakan izin eksplisit). Permintaan ini akan gagal karena kebijakan DENY_BY_DEFAULT.

   kubectl exec -it deploy/server -n ambient-test -- /bin/curl -fsLS server.ambient-test.svc.cluster.local
   

   Outputnya mirip dengan:

   curl: (52) Empty reply from server.
   

Logging

Jika permintaan ditolak oleh kebijakan otorisasi, proxy node akan menulis entri log akses ke Cloud Logging dengan nama log gke-ambient-node-proxy-accesslog. Entri ini berisi kolom berikut dalam payload JSON:

• jsonPayload.error_details: - rbac_access_denied_matched_policy[none]

Anda dapat menggunakan Logs Explorer di konsol Cloud de Confiance untuk melihat entri log akses untuk koneksi yang ditolak:

resource.type="k8s_container"
logName="projects/PROJECT_ID/logs/gke-ambient-node-proxy-accesslog"
jsonPayload.error_details=~"rbac_access_denied"

Untuk mengetahui informasi selengkapnya, lihat Memverifikasi bahwa traffic diautentikasi dan diotorisasi.

Kebijakan keamanan egress

Untuk memeriksa dan mengontrol traffic keluar dari workload jaringan ambient ke endpoint eksternal atau internet, Anda dapat merutekan traffic keluar melalui Secure Web Proxy (SWP).

Untuk mengetahui petunjuk tentang cara mengonfigurasi resource GCPBackend dan GCPEgressPolicy, lihat Merutekan traffic egress ambient melalui Secure Web Proxy.