Ringkasan kebijakan otorisasi

Kebijakan otorisasi (AuthzPolicy) yang diterapkan pada aturan penerusan Application Load Balancer menentukan aturan yang menentukan sumber traffic masuk dan operasi yang diizinkan atau dibatasi untuk sumber tersebut. Selain itu, kebijakan otorisasi menguraikan kondisi saat aturan berlaku dan menentukan tindakan untuk mengizinkan, menolak, atau mengevaluasi lebih lanjut traffic.

Kebijakan otorisasi memungkinkan Anda menetapkan pemeriksaan kontrol akses untuk traffic masuk ke Load Balancer Aplikasi. Permintaan yang lulus pemeriksaan ini akan dirutekan ke layanan backend. Permintaan yang gagal dalam pemeriksaan ini akan dihentikan dengan respons yang tidak sah.

Kebijakan otorisasi dapat dikonfigurasi pada aturan penerusan semua Load Balancer Aplikasi dengan skema load balancing EXTERNAL_MANAGED atau INTERNAL_MANAGED. Load Balancer Aplikasi berikut mendukung kebijakan otorisasi:

  • Load Balancer Aplikasi eksternal global

  • Load Balancer Aplikasi eksternal regional

  • Load Balancer Aplikasi internal regional

  • Load Balancer Aplikasi internal lintas region

Di Load Balancer Aplikasi, kebijakan otorisasi dipanggil setelah mengevaluasi ekstensi rute, kebijakan keamanan jaringan (dievaluasi oleh Google Cloud Armor), kebijakan berbagi resource lintas origin (CORS), dan kebijakan Identity-Aware Proxy (IAP), tetapi sebelum menjalankan tindakan manajemen traffic.

Untuk mempelajari lebih lanjut kapan kebijakan otorisasi dipanggil di jalur pemrosesan permintaan, lihat Titik ekstensi di jalur data load balancing.

Jika Anda ingin menggunakan kebijakan otorisasi untuk layanan yang di-deploy dengan Cloud Service Mesh, lihat Menyiapkan keamanan layanan dengan Envoy.

Aturan kebijakan otorisasi

Kebijakan otorisasi terdiri dari daftar aturan HTTP yang akan dicocokkan dengan permintaan masuk.

Untuk kebijakan otorisasi dengan tindakan ALLOW atau DENY, aturan HTTP (AuthzRule) menentukan kondisi yang menentukan apakah traffic diizinkan untuk melewati load balancer. Diperlukan minimal satu aturan HTTP.

Untuk kebijakan otorisasi dengan tindakan CUSTOM, aturan HTTP (AuthzRule) menentukan kondisi yang menentukan apakah traffic didelegasikan ke penyedia kustom untuk otorisasi. Penyedia kustom diperlukan, sedangkan aturan HTTP bersifat opsional.

Kecocokan kebijakan terjadi jika minimal satu aturan HTTP cocok dengan permintaan atau jika tidak ada aturan HTTP yang ditentukan dalam kebijakan.

Aturan HTTP kebijakan otorisasi terdiri dari kolom berikut:

  • from: menentukan identitas klien yang diizinkan oleh aturan. Identitas dapat berasal dari sertifikat klien dalam koneksi TLS timbal balik, atau dapat berupa identitas standby yang terkait dengan instance virtual machine (VM) klien, seperti dari akun layanan atau tag aman.
  • to: menentukan operasi yang diizinkan oleh aturan, seperti URL yang dapat diakses atau metode HTTP yang diizinkan.
  • when: menentukan batasan tambahan yang harus dipenuhi. Anda dapat menggunakan ekspresi Common Expression Language (CEL) untuk menentukan batasan.

Tindakan kebijakan otorisasi

Saat mengevaluasi permintaan, kebijakan otorisasi menentukan tindakan (AuthzAction) yang akan diterapkan pada permintaan. Kebijakan otorisasi harus memiliki setidaknya satu tindakan, yang dapat berupa salah satu dari hal berikut:

  • ALLOW: memungkinkan permintaan diteruskan ke backend jika permintaan tersebut cocok dengan salah satu aturan yang ditentukan dalam kebijakan ALLOW. Jika kebijakan ALLOW ada, tetapi tidak ada kecocokan, permintaan akan ditolak. Dengan kata lain, permintaan akan ditolak jika tidak ada kebijakan otorisasi yang dikonfigurasi dengan tindakan ALLOW yang cocok dengan permintaan. Di Cloud Logging, tindakan ini dicatat dalam log sebagai denied_as_no_allow_policies_matched_request.

    Agar tindakan ALLOW diterapkan, Anda memerlukan minimal satu aturan HTTP.

  • DENY: menolak permintaan jika permintaan cocok dengan salah satu aturan yang ditentukan dalam kebijakan DENY. Jika kebijakan DENY ada, tetapi tidak ada kecocokan, permintaan akan diizinkan. Dengan kata lain, permintaan diizinkan jika tidak ada kebijakan otorisasi yang dikonfigurasi dengan tindakan DENY yang cocok dengan permintaan. Di Cloud Logging, tindakan ini dicatat dalam log sebagai allowed_as_no_deny_policies_matched_request.

    Agar tindakan DENY diterapkan, Anda memerlukan minimal satu aturan HTTP.

  • CUSTOM: mendelegasikan keputusan otorisasi ke penyedia otorisasi kustom, seperti IAP atau ekstensi layanan. Untuk mempelajari lebih lanjut, lihat Menggunakan kebijakan otorisasi untuk mendelegasikan keputusan otorisasi.

    Jika ada aturan HTTP yang dikonfigurasi untuk kebijakan CUSTOM, permintaan harus cocok dengan aturan HTTP untuk memanggil penyedia kustom. Namun, jika tidak ada aturan HTTP yang ditentukan, kebijakan otorisasi akan selalu mendelegasikan keputusan otorisasi ke penyedia otorisasi kustom. Untuk mempelajari lebih lanjut, lihat contoh berikut saat tidak ada aturan HTTP yang ditentukan dan kebijakan otorisasi mendelegasikan keputusan otorisasi ke IAP:

    Membuat kebijakan otorisasi dan mengaktifkan IAP

Urutan evaluasi kebijakan otorisasi

Kebijakan otorisasi mendukung kebijakan CUSTOM, DENY, dan ALLOW untuk kontrol akses. Jika beberapa kebijakan otorisasi dikaitkan dengan satu resource, kebijakan CUSTOM dievaluasi terlebih dahulu, lalu kebijakan DENY, dan terakhir kebijakan ALLOW. Evaluasi ditentukan oleh aturan berikut:

  1. Jika ada kebijakan CUSTOM yang cocok dengan permintaan, kebijakan CUSTOM akan dievaluasi menggunakan penyedia otorisasi kustom dan permintaan akan ditolak jika penyedia menolak permintaan. Kebijakan DENY atau ALLOW tidak dievaluasi, meskipun jika ada yang dikonfigurasi.

  2. Jika ada kebijakan DENY yang cocok dengan permintaan, permintaan tersebut akan ditolak. Kebijakan ALLOW apa pun tidak dievaluasi, meskipun telah dikonfigurasi.

  3. Jika tidak ada kebijakan ALLOW, permintaan akan diizinkan.

  4. Jika ada kebijakan ALLOW yang cocok dengan permintaan, izinkan permintaan tersebut.

  5. Jika kebijakan ALLOW ada, tetapi tidak ada kecocokan, permintaan akan ditolak. Dengan kata lain, permintaan ditolak secara default jika tidak ada AuthzPolicies yang dikonfigurasi dengan tindakan ALLOW yang cocok dengan permintaan.

Menggunakan kebijakan otorisasi untuk mendelegasikan keputusan otorisasi

Untuk keputusan otorisasi kompleks yang tidak dapat dinyatakan menggunakan kebijakan otorisasi, delegasikan keputusan otorisasi ke penyedia otorisasi kustom, seperti Identity-Aware Proxy (IAP), atau buat ekstensi otorisasi Anda sendiri yang dibuat menggunakan Ekstensi Layanan. Hal ini berguna saat Anda ingin menggunakan mesin otorisasi on-premise atau penyedia identitas pihak ketiga melalui IAP.

  • IAP: mengonfigurasi IAP untuk mengontrol akses ke aplikasi di balik aturan penerusan Load Balancer Aplikasi. IAP memverifikasi identitas dan konteks pengguna untuk menentukan akses. Layanan ini juga dapat mengautentikasi token akun layanan Identity and Access Management (IAM) dan mengevaluasi kebijakan IAM, yang melindungi akses ke bucket backend yang ditampilkan dari Application Load Balancer. Untuk mengetahui informasi selengkapnya, lihat Mendelegasikan otorisasi ke IAP dan IAM.

    Anda dapat memilih untuk mendelegasikan autentikasi ke IAP dan IAM dalam skenario berikut:

    • Gunakan IAM untuk pengelolaan izin.
    • Menerapkan Akses Kontekstual.
    • Gunakan autentikasi berbasis browser untuk aplikasi web yang memerlukan autentikasi interaktif.

  • Ekstensi Layanan: mendelegasikan keputusan otorisasi ke mesin otorisasi kustom Anda yang berjalan di Google Cloud instance VM atau di lokal. Hal ini memberikan fleksibilitas untuk kebijakan otorisasi yang kompleks yang tidak tercakup dalam kebijakan bawaan. Untuk informasi selengkapnya, lihat Mengonfigurasi ekstensi otorisasi.

Kebijakan otorisasi berdasarkan akun layanan atau tag

Anda dapat menggunakan atribut seperti akun layanan atau tag untuk mengidentifikasi sumber traffic untuk Application Load Balancer internal.

Untuk Load Balancer Aplikasi internal, Anda dapat menerapkan kebijakan otorisasi berdasarkan akun layanan atau tag yang dilampirkan ke resource Google Cloud . Setiap traffic yang berasal dari resource Google Cloud ini yang ditautkan ke akun layanan atau tag tertentu dapat diizinkan, ditolak, atau didelegasikan ke layanan eksternal.

Tabel berikut mencantumkan resource sumber dan berbagai arsitektur Virtual Private Cloud (VPC) yang mendukung penggunaan akun layanan dan tag.

Sumber Dukungan akun layanan Dukungan tag
VM
Node GKE
Penampung GKE * *
VPC Langsung untuk Cloud Run *
Konektor Akses VPC Serverless † †
Cloud VPN * *
Cloud Interconnect di lokasi * *
Load Balancer Aplikasi
Network Load Balancer

* Tidak didukung oleh Google Cloud.

† Alamat IP sumber bersifat unik dan dapat digunakan sebagai gantinya.

VPC Arsitektur VPC Dukungan
Dalam VPC Lintas project (VPC Bersama)
Dalam VPC Lintas region
VPC Lintas Link peering silang (VPC peer)
VPC Lintas Private Service Connect Lintas
VPC Lintas Spoke lintas Network Connectivity Center

Untuk mempelajari lebih lanjut cara menyiapkan kebijakan otorisasi yang didasarkan pada akun layanan dan tag yang dilampirkan ke resource VM Google Cloud , lihat Kebijakan otorisasi berdasarkan akun layanan atau tag.

Kuota

Untuk mengetahui informasi tentang kuota untuk kebijakan otorisasi, lihat kuota dan batas untuk kebijakan otorisasi.

Harga

Kebijakan otorisasi tidak dikenai biaya selama periode Pratinjau. Namun, Anda akan dikenai biaya jaringan saat menggunakan Google Cloud load balancer. Untuk mengetahui informasi harga, lihat Harga.

Langkah berikutnya