Mengonfigurasi fitur lanjutan kebijakan otorisasi

Kebijakan otorisasi Cloud Service Mesh menyediakan mesh-, namespace-, dan akses kontrol akses tingkat workload untuk workload Anda di mesh. Halaman ini menjelaskan detail tentang cara mengonfigurasi kebijakan otorisasi Cloud Service Mesh tingkat lanjut fitur, termasuk mode uji coba dan logging penolakan. Fitur yang dijelaskan di halaman ini menganggap Anda sudah mengenal otorisasi dasar konsep kebijakan yang dijelaskan dalam Ringkasan kebijakan otorisasi.

Mode uji coba

Kebijakan otorisasi Cloud Service Mesh mendukung mode uji coba, yang memungkinkan Anda menguji kebijakan otorisasi dengan lalu lintas produksi yang nyata tanpa menerapkannya. Mode uji coba memungkinkan Anda untuk lebih memahami pengaruh otorisasi sebelum memberlakukannya. Hal ini membantu mengurangi risiko merusak traffic produksi yang disebabkan oleh kebijakan otorisasi yang salah.

Anda menggunakan anotasi "istio.io/dry-run": "true" dalam kebijakan otorisasi untuk mengubahnya ke mode uji coba.

Contoh mode uji coba

Contoh berikut, deny-path-headers, menunjukkan kebijakan dengan anotasi dry-run yang disetel ke "true. Kebijakan otorisasi menolak permintaan ke jalur headers dan mengizinkan semua permintaan lainnya.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Saat Anda menerapkan kebijakan otorisasi dalam mode uji coba, Cloud Service Mesh akan mencatat hasil penegakan kebijakan terhadap Cloud Logging, tetapi tidak menegakkan kebijakan. Permintaan ini selalu diizinkan, dan Anda bisa memeriksa Logs Explorer untuk memutuskan apakah kebijakan otorisasi berfungsi atau tidak sesuai yang diharapkan.

Detail logging uji coba

Setelah menerapkan kebijakan otorisasi dalam mode uji coba, Anda dapat melihat hasil kebijakan di Logs Explorer.

1. Buka Logs Explorer. Di URL berikut, ganti PROJECT_ID dengan project ID Anda:

   https://console.cloud.google.com/logs/query?project=PROJECT_ID
   

2. Di kolom Query-builder, masukkan kueri untuk menemukan mode uji coba kebijakan otorisasi. Dalam kueri berikut, ganti NAMESPACE dengan namespace Anda:

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"
   

3. Klik Run query.

4. Sesuaikan rentang waktu sesuai kebutuhan.

Screenshot berikut menampilkan label uji coba di login traffic Logs Explorer setelah contoh kebijakan deny-path-headers diterapkan:

Mode uji coba mendukung kebijakan otorisasi ALLOW dan DENY, selain ke Hasil uji coba Istio. Cloud Service Mesh menyimpan hasil uji coba ke Cloud Logging berikut label:

• dry_run_result: Hasil uji coba adalah "AuthzAllowed" atau "AuthzDitolak".
• dry_run_policy_name: Namespace dan nama otorisasi yang cocok kebijakan untuk membuat keputusan uji coba.
• dry_run_policy_rule: Indeks aturan kebijakan otorisasi yang cocok membuat keputusan uji coba.

Tabel berikut menampilkan detail yang dicatat untuk otorisasi kebijakan dalam mode uji coba:

Setelah yakin dengan hasil uji coba, Anda dapat menonaktifkan mode uji coba menggunakan salah satu pendekatan berikut:

• Menghapus anotasi uji coba sepenuhnya; atau

• Ubah nilai anotasi uji coba menjadi false.

Setelah Anda menerapkan kebijakan dengan mode uji coba dinonaktifkan, Cloud Service Mesh akan menerapkan kebijakan tersebut.

Logging penolakan

Kebijakan otorisasi akan menolak permintaan jika tidak diizinkan oleh kebijakan. Untuk protokol HTTP (termasuk gRPC), permintaan ditolak dengan kode status 403. Untuk protokol non-HTTP, koneksi diakhiri secara langsung. Tujuan Log traffic Cloud Logging mencakup informasi tambahan yang berguna untuk memahami mengapa traffic ditolak. Misalnya, log menunjukkan berapa banyak permintaan ditolak oleh kebijakan otorisasi, yang dapat membantu Anda menentukan aturan kebijakan mana yang menyebabkan penolakan versus penolakan dari backend aplikasi.

Pada contoh berikut, anotasi dry-run disetel ke "false. Jika Anda menerapkan kebijakan otorisasi DENY, Cloud Service Mesh akan menerapkannya.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "false"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Setelah menerapkan kebijakan otorisasi DENY, Anda dapat melihat hasil di Logs Explorer.

1. Buka Logs Explorer. Di URL berikut, ganti PROJECT_ID dengan project ID Anda:

   https://console.cloud.google.com/logs/query?project=PROJECT_ID
   

2. Di kolom Query-builder, masukkan kueri untuk menemukan DENY kebijakan otorisasi. Dalam kueri berikut, ganti NAMESPACE dengan namespace Anda:

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.response_details="AuthzDenied"
   

3. Klik Run query.

4. Sesuaikan rentang waktu sesuai kebutuhan.

Screenshot berikut menampilkan entri log di Logs Explorer setelah contoh kebijakan deny-path-headers diterapkan untuk menegakkan kebijakan tersebut. Anda dapat mengatakan bahwa kebijakan otorisasi bertanggung jawab atas 403 dengan melihat pada label:

Log traffic Logs Explorer menyertakan label berikut untuk penolakan otorisasi:

• response_details: Ditetapkan ke "AuthzDenied" jika penolakan disebabkan oleh kebijakan otorisasi.
• policy_name: Berisi namespace dan nama otorisasi Kebijakan DENY yang menyebabkan penolakan. Nilainya dalam format <Namespace>.<Name>, misalnya, foo.deny-path-headers berarti kebijakan otorisasi deny-path-headers di namespace foo.
• policy_rule: Berisi indeks aturan di dalam kebijakan otorisasi yang menyebabkan penolakan, misalnya, 0 berarti aturan pertama di dalam kebijakan.

Apa langkah selanjutnya?

Untuk mengetahui daftar semua kebijakan otorisasi di mesh layanan:

kubectl get authorizationpolicy --all-namespaces

Jika ada kebijakan otorisasi yang berlaku, Anda dapat menghapusnya dengan kubectl delete:

kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME

Untuk informasi selengkapnya tentang cara mendapatkan log traffic, lihat Mengakses log di Cloud Logging.