Ringkasan kebijakan otorisasi

Kebijakan otorisasi memungkinkan Anda membuat pemeriksaan kontrol akses dan pemeriksaan pembersihan konten saat memproses permintaan atau respons melalui berbagai layananGoogle Cloud seperti Load Balancer Aplikasi, Agent Gateway (Pratinjau Pribadi), dan Secure Web Proxy.

Untuk Agent Gateway dan Secure Web Proxy, kebijakan otorisasi dilampirkan langsung ke resource gateway layanan ini. Untuk load balancer, kebijakan otorisasi dilampirkan ke resource aturan penerusan load balancer.

Kebijakan otorisasi (AuthzPolicy), yang dilampirkan ke aturan penerusan load balancer, memungkinkan Anda menentukan kondisi yang mengizinkan, membatasi, atau mendelegasikan otorisasi permintaan berdasarkan sumber dan operasi yang dimaksud. Permintaan yang lulus pemeriksaan ini akan dirutekan ke layanan backend load balancer, sedangkan permintaan yang gagal dalam pemeriksaan ini akan ditolak dengan respons tidak sah.

Anda dapat mengonfigurasi kebijakan otorisasi 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

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 kebijakan ALLOW ada, 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 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 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 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 dalam Kebijakan otorisasi untuk mendelegasikan keputusan otorisasi.

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. Jika penyedia kustom menolak permintaan, permintaan tersebut akan ditolak. 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 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 AuthzPolicies yang dikonfigurasi dengan tindakan ALLOW yang cocok dengan permintaan.

Untuk Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Agent Gateway, dan Secure Web Proxy—layananGoogle Cloud yang mendukung profil kebijakan—urutan evaluasi kebijakan otorisasi adalah sebagai berikut:

  1. Jika ada kebijakan otorisasi permintaan kustom (REQUEST_AUTHZ) yang cocok dengan permintaan, kebijakan REQUEST_AUTHZ dievaluasi menggunakan penyedia otorisasi kustom. Jika penyedia kustom menolak permintaan, permintaan tersebut akan ditolak. Kebijakan DENY, ALLOW, dan CONTENT_AUTHZ tidak dievaluasi, meskipun ada yang dikonfigurasi.

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

  3. Jika tidak ada kebijakan ALLOW, permintaan akan dilanjutkan ke evaluasi otorisasi konten (CONTENT_AUTHZ).

  4. Jika ada kebijakan ALLOW yang cocok dengan permintaan, permintaan akan dilanjutkan ke evaluasi CONTENT_AUTHZ.

  5. Jika ada kebijakan ALLOW, tetapi tidak ada kecocokan, permintaan akan ditolak. Kebijakan CONTENT_AUTHZ tidak dievaluasi.

  6. Jika ada kebijakan CONTENT_AUTHZ yang cocok dengan permintaan, kebijakan tersebut akan dievaluasi terakhir. Jika penyedia kustom menolak permintaan, permintaan tersebut akan ditolak.

Profil kebijakan dalam kebijakan otorisasi

Profil kebijakan dalam kebijakan otorisasi didukung untuk layanan Google Cloud berikut:

  • Load Balancer Aplikasi eksternal regional
  • Load Balancer Aplikasi internal regional
  • Agent Gateway
  • Secure Web Proxy

Profil kebijakan (PolicyProfile) dalam kebijakan otorisasi memiliki jenis berikut:

  • Profil otorisasi permintaan (REQUEST_AUTHZ): mengandalkan informasi di header permintaan HTTP untuk mengizinkan atau menolak traffic.
  • Profil otorisasi konten (CONTENT_AUTHZ): memberikan keamanan dan pemfilteran berbasis konten untuk memblokir serangan injeksi perintah, mencegah kebocoran data sensitif, dan memfilter konten berbahaya.

Anda dapat mengonfigurasi kebijakan otorisasi dengan profil REQUEST_AUTHZ atau profil CONTENT_AUTHZ, tetapi tidak keduanya. Jika profil kebijakan tidak ditentukan, kebijakan otorisasi akan menggunakan profil REQUEST_AUTHZ secara default.

Meminta profil otorisasi

Kebijakan otorisasi yang menggunakan profil kebijakan REQUEST_AUTHZ dapat mengevaluasi keputusan akses untuk traffic masuk secara langsung atau mendelegasikannya. Anda dapat mendelegasikan keputusan akses ke Identity-Aware Proxy atau ke mesin otorisasi kustom menggunakan ekstensi otorisasi. Profil kebijakan REQUEST_AUTHZ bertindak berdasarkan informasi di header permintaan HTTP untuk mengizinkan atau menolak permintaan.

Kebijakan otorisasi dengan profil kebijakan REQUEST_AUTHZ dapat memiliki tindakan ALLOW, DENY, atau CUSTOM yang diterapkan ke permintaan. Tindakan ALLOW atau DENY berarti keputusan akses dievaluasi secara langsung, sedangkan tindakan CUSTOM berarti keputusan akses didelegasikan.

Saat keputusan akses didelegasikan, kebijakan otorisasi, yang dikonfigurasi pada aturan penerusan load balancer, mengarah ke ekstensi otorisasi permintaan yang berjalan di layanan backend callout. Untuk setiap permintaan otorisasi, load balancer meneruskan header permintaan ke ekstensi otorisasi menggunakan protokol ext_proc atau ext_authz Envoy. Bergantung pada respons dari ekstensi, proxy load balancer akan meneruskan permintaan ke layanan backend-nya atau menolak permintaan.

Jika profil kebijakan tidak ditentukan, kebijakan otorisasi akan menggunakan profil otorisasi permintaan (REQUEST_AUTHZ) secara default.

Profil otorisasi konten

Kebijakan otorisasi menggunakan profil kebijakan CONTENT_AUTHZ dapat digunakan untuk melakukan pemeriksaan mendalam pada payload aplikasi Anda untuk mengizinkan atau menolak permintaan atau mengubah permintaan atau respons, sesuai kebutuhan. Anda dapat mendelegasikan keputusan akses ke Model Armor atau ekstensi pembersihan konten Anda sendiri.

Kebijakan otorisasi dengan profil kebijakan CONTENT_AUTHZ hanya dapat menerapkan tindakan CUSTOM ke permintaan. Artinya, permintaan tidak dapat dievaluasi secara langsung dan perlu didelegasikan.

Kebijakan otorisasi, yang dikonfigurasi pada aturan penerusan load balancer, mengarah ke ekstensi otorisasi konten. Untuk setiap permintaan otorisasi, load balancer meneruskan konten permintaan dan respons lengkap, yang mencakup header, isi, dan trailer, menggunakan protokol ext_proc Envoy dalam mode streaming dupleks penuh (FULL_DUPLEX_STREAMED), ke ekstensi otorisasi konten. Bergantung pada respons dari ekstensi, proxy load balancer akan meneruskan permintaan ke tujuannya atau menolak permintaan. Tujuan, dalam kasus permintaan, adalah layanan backend load balancer, dan dalam kasus respons, adalah klien.

Mendelegasikan keputusan otorisasi

Kebijakan otorisasi dapat dievaluasi secara langsung atau didelegasikan. Untuk keputusan otorisasi yang kompleks yang tidak dapat dinyatakan menggunakan kebijakan otorisasi, Anda dapat membuat kebijakan otorisasi dengan tindakan CUSTOM dan mendelegasikan keputusan otorisasi ke layanan yang dikelola Google atau layanan yang dikelola pengguna melalui Ekstensi Layanan.

  • Layanan yang dikelola Google
    • Model Armor
    • Identity-Aware Proxy
  • Layanan yang dikelola pengguna
    • Google Cloud layanan backend
    • layanan yang dapat diakses oleh nama domain yang sepenuhnya memenuhi syarat (FQDN) yang mendukung protokol ext_proc atau ext_authz Envoy

Tabel berikut merangkum berbagai layanan yang dapat didelegasikan keputusan otorisasi melalui Ekstensi Layanan.

Kebijakan otorisasi Dievaluasi secara langsung Didelegasikan ke Ekstensi Layanan (ekstensi otorisasi)
Layanan yang dikelola Google Layanan yang dikelola pengguna
Model Armor Identity-Aware Proxy Google Cloud layanan backend Layanan berbasis FQDN
Profil REQUEST_AUTHZ
Profil CONTENT_AUTHZ

Service Extensions

Anda dapat menggunakan kebijakan otorisasi untuk mendelegasikan keputusan otorisasi ke Ekstensi Layanan, khususnya jenis ekstensi otorisasi. Ekstensi otorisasi mendukung teks promosi untuk menyuntikkan logika kustom ke dalam Load Balancer Aplikasi Google Cloud. Kemampuan ini memungkinkan Anda menulis kode sendiri untuk melakukan berbagai aktivitas pada traffic yang diproses oleh load balancer seperti penulisan ulang header, keamanan inkremental, logging kustom, dan autentikasi pengguna kustom.

Dengan callout Service Extensions, Anda menginstruksikan load balancer untuk meneruskan traffic dari dalam jalur pemrosesan data load balancing menggunakan panggilan gRPC, ke layanan callout, yang dapat dikelola pengguna atau dikelola Google. Berbagai layanan info ditentukan dalam tabel sebelumnya. Layanan anotasi ini menjalankan ekstensi otorisasi dan dapat menerapkan berbagai kebijakan atau fungsi sebelum mengembalikan traffic ke load balancer untuk diproses lebih lanjut. Diagram berikut menunjukkan proses ini.

Kebijakan otorisasi dapat mendelegasikan keputusan otorisasi ke Ekstensi Layanan, khususnya jenis ekstensi otorisasi.
Kebijakan otorisasi yang mendelegasikan keputusan otorisasi melalui ekstensi otorisasi (klik untuk memperbesar).

Untuk mendelegasikan keputusan otorisasi ke ekstensi otorisasi, buat ekstensi otorisasi (AuthzExtension) yang berjalan di layanan panggilan. Kemudian, Anda dapat membuat kebijakan otorisasi dengan tindakan CUSTOM dan mengarahkannya ke ekstensi otorisasi yang Anda buat. Ekstensi otorisasi dapat digunakan untuk melakukan otorisasi tingkat permintaan (REQUEST_AUTHZ) dan sanitasi konten (CONTENT_AUTHZ).

Untuk mempelajari lebih lanjut cara mendelegasikan keputusan otorisasi ke layanan backend Google Cloud yang dikelola pengguna atau layanan berbasis FQDN, lihat Mendelegasikan keputusan otorisasi ke layanan yang dikelola pengguna.

Ekstensi otorisasi di jalur pemrosesan data

Saat mendelegasikan keputusan otorisasi ke Ekstensi Layanan, khususnya jenis ekstensi otorisasi, perhatikan terminologi berikut:

  • Jika kebijakan otorisasi kustom dengan profil kebijakan REQUEST_AUTHZ menunjuk ke ekstensi otorisasi (AuthzExtension), ekstensi otorisasi tersebut disebut sebagai ekstensi otorisasi permintaan.

  • Jika kebijakan otorisasi dengan profil kebijakan CONTENT_AUTHZ mengarah ke ekstensi otorisasi (AuthzExtension), ekstensi otorisasi tersebut disebut sebagai ekstensi otorisasi konten.

Di jalur pemrosesan permintaan, ekstensi otorisasi permintaan dipanggil terlebih dahulu, diikuti dengan evaluasi kebijakan penolakan dan izin, lalu ekstensi otorisasi konten, dan terakhir ekstensi traffic. Ekstensi otorisasi konten juga dapat dipanggil di jalur pemrosesan respons. Diagram berikut menunjukkan urutan pemanggilan berbagai ekstensi.

Ekstensi otorisasi permintaan dipanggil sebelum ekstensi otorisasi konten
Permintaan perpanjangan otorisasi dipanggil sebelum perpanjangan otorisasi konten (klik untuk memperbesar).

Anda dapat menganggap berbagai ekstensi sebagai hook yang dipicu di sepanjang titik tertentu pada jalur pemrosesan data. Untuk mempelajari lebih lanjut berbagai ekstensi, lihat Titik ekstensibilitas di jalur data load balancing dalam dokumentasi Service Extensions.

Model Armor

Anda dapat menggunakan kebijakan otorisasi untuk mengaktifkan Model Armor agar menerapkan pembatasan AI yang mencegah pembuatan konten berbahaya, mencegah injeksi prompt, dan mencegah kebocoran data.

Untuk melakukannya, Anda dapat membuat ekstensi otorisasi (AuthzExtension) yang berjalan di layanan Model Armor. Kemudian, Anda dapat membuat kebijakan otorisasi dengan tindakan CUSTOM dan profil CONTENT_AUTHZ yang mengarah ke ekstensi otorisasi yang Anda buat.

Untuk mempelajari lebih lanjut cara mendelegasikan otorisasi ke Model Armor, lihat Mendelegasikan keputusan otorisasi ke Model Armor.

Identity-Aware Proxy

Anda dapat mendelegasikan keputusan otorisasi ke Identity-Aware Proxy. IAP memverifikasi identitas pengguna dan konteks permintaan untuk menentukan apakah pengguna harus diizinkan untuk mengakses aplikasi atau resource.

Untuk Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi internal lintas-region, Anda tidak dapat mendelegasikan keputusan otorisasi ke IAP melalui ekstensi otorisasi.

Untuk Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal regional, Anda dapat mengonfigurasi kebijakan otorisasi untuk mendelegasikan keputusan otorisasi ke IAP melalui ekstensi otorisasi.

Untuk mempelajari lebih lanjut cara menggunakan IAP sebagai layanan otorisasi, lihat Mendelegasikan keputusan otorisasi ke Identity-Aware Proxy.

Kebijakan otorisasi berdasarkan akun utama

Untuk mengidentifikasi sumber traffic dengan perincian yang tinggi, Anda dapat mengonfigurasi kebijakan otorisasi berdasarkan identitas yang berasal dari sertifikat klien. Metode ini memerlukan 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 principal 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 prinsipal 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 ukuran 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 melampaui batas ukurannya, tetapi tidak divalidasi secara eksplisit oleh pemilih prinsipal kebijakan, permintaan 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 akan mengevaluasi permintaan berdasarkan SAN Nama DNS-nya.

Untuk melihat contoh kebijakan otorisasi berdasarkan akun utama, lihat Kebijakan otorisasi untuk menolak permintaan.

Kebijakan otorisasi berdasarkan akun layanan atau tag aman

Kebijakan otorisasi berdasarkan akun layanan atau tag aman didukung untuk load balancer berikut:

  • Load Balancer Aplikasi internal regional
  • Load Balancer Aplikasi internal lintas region

Kebijakan otorisasi, berdasarkan akun layanan dan tag aman, memungkinkan Anda menerapkan aturan keamanan berdasarkan siapa atau apa yang mengirim traffic, bukan hanya alamat IP. Hal ini menyebabkan peralihan dari aturan berbasis IP ke kontrol berbasis identitas dengan menggunakan akun layanan dan tag aman untuk menentukan perimeter keamanan Anda. Misalnya, Anda dapat membuat kebijakan otorisasi untuk melakukan hal berikut:

  • menolak VM Compute Engine dengan akun layanan tertentu (my-sa-123@PROJECT_ID.iam.gserviceaccount.com) untuk mencapai jalur /api/payments.

  • mengizinkan VM Compute Engine dengan tag aman (pasangan nilai kunci environment: prod) untuk mencapai jalur /api/payments.

Anda dapat menerapkan kebijakan otorisasi berdasarkan akun layanan atau tag aman yang dilampirkan ke berbagai layanan Google Cloud . Traffic apa pun yang berasal dari layanan Google Cloud ini, yang ditautkan ke akun layanan tertentu atau tag aman, dapat diizinkan, ditolak, atau didelegasikan untuk evaluasi lebih lanjut.

Tabel berikut mencantumkan berbagai Google Cloud layanan yang mendukung penggunaan akun layanan dan tag aman.

Google Cloud layanan Dukungan akun layanan Dukungan tag aman
Virtual machine (VM) Compute Engine
Node Google Kubernetes Engine (GKE)
Container Google Kubernetes Engine (GKE) 1 1
VPC Langsung untuk Cloud Run 1
Konektor Akses VPC Serverless 2 2
Cloud VPN 1 1
Cloud Interconnect di lokasi 1 1
Load Balancer Aplikasi 3 3
Load Balancer Jaringan 3 3

1 Tidak didukung oleh Google Cloud.

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

3 Akun layanan dan tag tidak didukung saat Load Balancer Aplikasi dan Load Balancer Jaringan berfungsi sebagai sumber traffic dalam arsitektur bertingkat.

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

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 Google Cloud resource, 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

Untuk mengetahui informasi harga, lihat Harga jaringan: Cloud Load Balancing.

Langkah berikutnya