Ringkasan kebijakan otorisasi

Kebijakan otorisasi (AuthzPolicy) yang diterapkan pada aturan penerusan Load Balancer Aplikasi menentukan aturan yang menetapkan sumber traffic masuk dan operasi yang diizinkan atau dibatasi untuk sumber tersebut. Selain itu, kebijakan otorisasi menguraikan kondisi yang menyebabkan 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 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 pengelolaan traffic.

Untuk mempelajari lebih lanjut kapan kebijakan otorisasi dipanggil di jalur pemrosesan permintaan, lihat Titik ekstensibilitas 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 saat minimal satu aturan HTTP cocok dengan permintaan atau saat 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 diperoleh dari sertifikat klien dalam koneksi mutual TLS, atau dapat berupa identitas sekitar 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 berikut:

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

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

  • DENY: menolak permintaan jika permintaan cocok dengan salah satu aturan yang ditentukan dalam kebijakan DENY. Jika ada kebijakan DENY, 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 sebagai allowed_as_no_deny_policies_matched_request.

    Agar tindakan DENY diterapkan, Anda memerlukan setidaknya 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 yang tidak menentukan aturan HTTP 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 akan 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 dievaluasi menggunakan penyedia otorisasi kustom dan permintaan ditolak jika penyedia menolak permintaan. DENY atau ALLOW tidak dievaluasi, meskipun ada yang dikonfigurasi.

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

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

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

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

Menggunakan kebijakan otorisasi untuk mendelegasikan keputusan otorisasi

Untuk keputusan otorisasi yang 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 lokal 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, sehingga melindungi akses ke bucket backend yang diekspos dari Load Balancer Aplikasi. 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 lokal. Hal ini memberikan fleksibilitas untuk kebijakan otorisasi kompleks yang tidak dicakup oleh kebijakan bawaan. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi ekstensi otorisasi.

Kebijakan otorisasi berdasarkan akun utama

Untuk mengidentifikasi sumber traffic dengan perincian tinggi, Anda dapat mengonfigurasi kebijakan otorisasi berdasarkan identitas yang berasal dari sertifikat klien. Metode ini mengharuskan mTLS frontend diaktifkan di load balancer dan menggunakan atribut sertifikat berikut sebagai pemilih principal untuk identifikasi:

  • SAN URI sertifikat klien (CLIENT_CERT_URI_SAN)
  • SAN Nama DNS sertifikat klien (CLIENT_CERT_DNS_NAME_SAN)
  • Nama Umum sertifikat klien (CLIENT_CERT_COMMON_NAME)

Jika tidak ada pemilih prinsipal yang ditentukan untuk identifikasi, CLIENT_CERT_URI_SAN akan digunakan sebagai pemilih prinsipal default. Artinya, SAN URI sertifikat klien dievaluasi saat membuat keputusan otorisasi.

Agar otorisasi berbasis prinsipal dapat berfungsi, kondisi berikut harus berlaku:

  • mTLS frontend harus diaktifkan. Jika mTLS frontend tidak diaktifkan, klien tidak menyajikan sertifikat. Akibatnya, aturan berbasis prinsipal dalam kebijakan otorisasi tidak menemukan informasi sertifikat untuk dievaluasi. Misalnya, aturan yang memeriksa CLIENT_CERT_URI_SAN melihat nilai kosong.

  • Harus ada sertifikat klien yang valid. Meskipun mTLS diaktifkan, sertifikat klien tidak digunakan untuk otorisasi jika koneksi dibuat dengan sertifikat yang tidak ada atau tidak valid. Skenario ini terjadi saat mode validasi klien mTLS disetel ke mode permisif ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Dalam kasus ini juga, aturan berbasis akun utama dalam kebijakan otorisasi tidak menemukan informasi sertifikat untuk dievaluasi. Misalnya, aturan yang memeriksa CLIENT_CERT_URI_SAN melihat nilai kosong.

Dampak batas ukuran atribut

Keputusan otorisasi sensitif terhadap ukuran atribut sertifikat klien. Permintaan akan ditolak jika atribut melebihi batas ukurannya dan kebijakan dikonfigurasi untuk memvalidasi atribut tertentu tersebut.

Penolakan dapat terjadi dalam kondisi berikut:

  • Kebijakan divalidasi terhadap CLIENT_CERT_URI_SAN, dan SAN URI sertifikat melebihi batas ukuran.
  • Kebijakan divalidasi terhadap CLIENT_CERT_DNS_NAME_SAN, dan SAN Nama DNS sertifikat melebihi batas ukuran.
  • Kebijakan divalidasi terhadap CLIENT_CERT_COMMON_NAME, dan Subjek sertifikat (yang berisi Nama Umum) melebihi batas ukuran.

Jika atribut sertifikat melebihi batas ukurannya, tetapi tidak divalidasi secara eksplisit oleh pemilih prinsipal kebijakan, permintaan tersebut tetap dievaluasi berdasarkan aturan prinsipal yang dikonfigurasi. Misalnya, jika kebijakan dikonfigurasi untuk memvalidasi hanya CLIENT_CERT_DNS_NAME_SAN, permintaan dari klien dengan SAN URI yang terlalu besar tidak akan ditolak karena alasan tersebut. Kebijakan ini akan mengevaluasi permintaan berdasarkan SAN Nama DNS-nya.

Kebijakan otorisasi berdasarkan akun layanan atau tag

Anda dapat menggunakan atribut seperti akun layanan atau tag untuk mengidentifikasi sumber traffic untuk Load Balancer Aplikasi 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
Container GKE * *
VPC Langsung untuk Cloud Run *
Konektor Akses VPC Serverless † †
Cloud VPN * *
Cloud Interconnect di lokal * *
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 Layanan lintas project (VPC Bersama)
Dalam VPC Lintas region
VPC Lintas Link peering silang (VPC peer)
VPC Lintas Private Service Connect lintas
VPC Lintas Spoke Network Connectivity Center lintas jaringan

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

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 load balancer Google Cloud . Untuk mengetahui informasi harga, lihat Harga.

Langkah berikutnya