Pola jaringan pribadi multi-agen di Google Cloud

Last reviewed 2026-04-16 UTC

Dokumen ini memberikan panduan untuk membantu Anda mendesain infrastruktur jaringan pribadi yang mendukung aplikasi Gemini Enterprise multi-agen yang dapat diakses secara publik dengan koneksi pribadi antara agen, subagen, dan alat. Desain jaringan menyediakan koneksi pribadi untuk agen yang dihosting di Vertex AI Agent Engine, Cloud Run, Google Kubernetes Engine (GKE), pusat data lokal, atau di cloud lain. Desain ini juga mendukung konektivitas ke agen yang berjalan di lokasi internet.

Sistem AI multi-agen sering kali melibatkan data eksklusif atau sensitif secara organisasi. Jaringan pribadi memungkinkan Anda menghindari pemaparan traffic ini ke internet publik. Desain ini menggunakan Google Cloud infrastruktur jaringan, resource jaringan Virtual Private Cloud (VPC), dan konektivitas pribadi ke lingkungan lokal atau jaringan lintas cloud.

Dalam desain yang dijelaskan dalam dokumen ini, agen berkomunikasi dengan agen lain dan dengan alat menggunakan protokol Agent2Agent (A2A) dan Model Context Protocol (MCP). Komunikasi dibuat pribadi dengan merutekannya melalui jaringan VPC. Untuk memindahkan traffic ke dan dari jaringan VPC, desain ini menggunakan kombinasi endpoint Private Service Connect, antarmuka Private Service Connect, dan keluar VPC Langsung Cloud Run. Cloud Next Generation Firewall (Cloud NGFW) mengatur traffic yang melewati jaringan VPC. Lapisan keamanan tambahan menyediakan egress internet yang terkontrol dengan menggunakan Secure Web Proxy dan menyediakan kebijakan akses layanan API dengan menggunakan perimeter Kontrol Layanan VPC.

Audiens yang dituju untuk dokumen ini mencakup arsitek, developer, dan administrator yang membangun serta mengelola infrastruktur dan aplikasi AI cloud. Dokumen ini mengasumsikan bahwa Anda memiliki pemahaman dasar tentang agen dan model AI serta memahami konsep jaringan Google Cloud .

Pola desain multi-agen

Aplikasi Gemini Enterprise multi-agen memerlukan agen kustom untuk berfungsi sebagai pengelola atau agen root untuk koneksi ke alat dan sub-agen. Untuk menerapkan koneksi pribadi ke alat dan subagen yang dihosting di Google Cloud atau lokal, desain ini menggunakan jaringan VPC dengan alamat IP pribadi. Agen root dihosting dalam infrastruktur Google, menggunakan Agent Engine, Cloud Run, atau GKE. Pola desain multi-agen menyoroti interaksi ini:

  1. Aplikasi Gemini Enterprise berinteraksi dengan agen root kustom. Aplikasi Gemini Enterprise menampilkan antarmuka pengguna terkelola dengan fungsi keamanan bawaan yang mengekspos fungsi agen kustom. Agen root buatan kustom didaftarkan ke Gemini Enterprise dan tersedia di aplikasi untuk pengguna akhir. Agen root kustom bertindak sebagai pengelola alur kerja tingkat teratas dan mendelegasikan tugas khusus ke sub-agen. Arsitektur ini menggunakan agen root kustom yang dihosting di Vertex AI Agent Engine, Cloud Run, atau GKE.
  2. Agen root berinteraksi dengan subagen dan alat. Alur kerja sistem AI dan logika bisnis inti berada di agen root dan di subagen khusus. Fleksibilitas dalam framework agen, runtime, dan platform hosting memungkinkan berbagai opsi untuk menghubungkan agen root ke subagen dan alat melalui jaringan VPC. Dengan menggunakan jaringan VPC untuk bagian arsitektur ini, agen dapat menggunakan jalur jaringan pribadi yang Anda tentukan yang mengekspos endpoint pribadi lainnya, kontrol keamanan perusahaan, dan jangkauan jaringan yang lebih luas.

Ringkasan tingkat tinggi arsitektur jaringan multi-agen.

Arsitektur ini mencakup komponen berikut:

  • Aplikasi Gemini Enterprise: Frontend bagi pengguna untuk mengakses antarmuka chat dalam aplikasi dan berinteraksi dengan sistem AI multi-agen. Pengguna dapat mengakses aplikasi Gemini Enterprise melalui internet publik atau secara pribadi melalui koneksi hybrid.
  • Agen kustom: Agen root yang dibuat dan didaftarkan dengan Gemini Enterprise serta dihosting di Vertex AI Agent Engine, Cloud Run, atau GKE. Agen root ini berfungsi sebagai pengelola yang mendelegasikan tugas ke sub-agen.
  • Jaringan VPC: Resource yang Anda kontrol untuk menyediakan konektivitas jaringan IP ke endpoint pribadi dan jangkauan jaringan yang lebih luas bagi agen. Jaringan VPC menyediakan platform untuk menerapkan konektivitas pribadi dan kontrol keamanan jaringan untuk permintaan agen ke agen dan alat lainnya.
  • Subagen: Agen khusus yang dipicu oleh alur kerja agen root. Subagen berkomunikasi menggunakan protokol A2A, yang memungkinkan interoperabilitas antar-agen terlepas dari bahasa pemrograman dan runtime.
  • Alat: Sistem jarak jauh yang mengekspos layanan seperti API, sumber data, dan fungsi alur kerja. Alat ini mengambil data dan melakukan tindakan atau transaksi untuk agen. Alat bersifat eksternal bagi agen, dan agen terhubung dan berinteraksi dengan alat menggunakan spesifikasi MCP.

Pola desain multi-agen tingkat tinggi ini menyoroti komponen jaringan yang ada dalam sistem AI multi-agen. Agent Engine dapat mendukung berbagai jenis pola perutean antar-agen. Untuk mengetahui informasi tentang pola desain sistem AI lainnya, lihat Memilih pola desain untuk sistem AI agentic Anda.

VPC Bersama

Pola desain multi-agen menggunakan VPC Bersama untuk memusatkan otoritas dan tanggung jawab jaringan dan keamanan. Desain ini memberi developer lingkungan yang membantu memenuhi kebutuhan keamanan organisasi. Sebaiknya gunakan VPC Bersama untuk memusatkan dan menyederhanakan konfigurasi jaringan dan keamanan Anda.

Dalam arsitektur VPC Bersama, project host berisi resource jaringan bersama, termasuk jaringan VPC, Cloud Router, subnet, firewall, dan Cloud DNS. Administrator dapat memberikan akses project layanan untuk menggunakan resource ini. Project layanan berisi resource runtime agen, termasuk Vertex AI Agent Engine, Cloud Run, GKE, Gemini Enterprise, dan load balancer khusus aplikasi.

VPC Bersama menerapkan batas yang jelas antara persona administrator jaringan dan keamanan serta persona developer aplikasi AI:

  • Administrator jaringan dan keamanan mengontrol infrastruktur inti, seperti perutean VPC, subnet, peering DNS, dan kebijakan firewall.
  • Developer aplikasi AI membuat agen di project layanan terlampir tanpa memiliki izin untuk mengubah infrastruktur jaringan yang mendasarinya.

Jika Anda memusatkan deployment jaringan dan keamanan dalam project host, Anda akan membuat satu titik pengelolaan untuk komunikasi antar-agen dan komunikasi agen ke layanan. Desain ini menyederhanakan penerapan kebijakan keamanan di berbagai project layanan sekaligus memastikan konektivitas yang konsisten.

Anda dapat menggabungkan jaringan VPC Bersama ke dalam Jaringan Lintas Cloud dengan menggunakan spoke VPC Network Connectivity Center (NCC) untuk menambahkan jaringan VPC Bersama sebagai jaringan VPC workload. Implementasi ini memberikan keterjangkauan penuh VPC Bersama ke rute hub NCC dan konektivitas ke titik akses layanan dari spoke lain.

Permintaan yang dimulai dari agen root kustom menggunakan jaringan VPC pribadi yang dikelola pelanggan untuk menyediakan jalur jaringan yang aman ke subagen, alat, dan layanan. Pemilihan rute jaringan VPC mengatur keterjangkauan ke endpoint pribadi. Kebijakan Cloud NGFW yang diterapkan ke jaringan VPC mengatur akses jaringan.

Agen mendapatkan akses aman ke jalur jaringan VPC pribadi, termasuk konektivitas ke berikut ini:

  • Jaringan VPC lain melalui peering jaringan VPC, peralatan multi-NIC, atau NCC.
  • Endpoint Private Service Connect untuk mengakses layanan produsen.
  • Layanan terkelola yang memiliki alamat IP pribadi, seperti Cloud SQL.
  • Frontend load balancer internal dan resource Compute Engine.
  • Google API melalui Akses Google Pribadi atau melalui Private Service Connect.
  • Internet, dikontrol melalui Secure Web Proxy.
  • Tujuan hybrid dan lintas cloud menggunakan Cloud Interconnect, Cloud VPN, router appliance, atau SD-WAN.
  • Tujuan endpoint apa pun yang dapat dijangkau melalui perutean IP jaringan VPC.
  • Agen, alat, dan layanan pendukung AI lainnya.

Untuk mengetahui informasi selengkapnya tentang VPC Bersama, lihat sumber daya berikut:

Jaringan Gemini Enterprise

Aplikasi Gemini Enterprise adalah resource terkelola yang beroperasi di lingkungan yang dihosting di luar jaringan VPC, tetapi di dalam jaringan Google. Bagian berikut menjelaskan konfigurasi untuk jaringan antara pengguna dan aplikasi Gemini Enterprise serta menjelaskan jaringan antara aplikasi dan agen.

Percakapan pengguna dengan aplikasi Gemini Enterprise

Pengguna melakukan percakapan dengan aplikasi Gemini Enterprise menggunakan aplikasi berbasis browser yang mengirimkan permintaan ke API dan layanan Google. Untuk mengaktifkan konektivitas pengguna pribadi, Anda dapat mengonfigurasi URL Google API agar di-resolve ke rentang alamat IP pribadi yang dirutekan melalui jaringan VPC Anda. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi akses UI pribadi.

Aplikasi Gemini Enterprise ke agen kustom

Anda mendaftarkan agen kustom dengan layanan penemuan Gemini Enterprise. Saat Anda mendaftarkan agen, Gemini Enterprise memetakan nama agen ke target tertentu, baik URI resource Vertex AI Agent Engine maupun URL agen A2A. Aplikasi Gemini Enterprise memiliki antarmuka chat bawaan yang disebut asisten. Saat pengguna menentukan agen menggunakan @agent_name, atau saat asisten memutuskan untuk mendelegasikan, aplikasi akan mencari agen di registry untuk menemukan endpoint terkait.

Saat mendaftarkan agen root dengan Gemini Enterprise, Anda dapat men-deploy agen tersebut di mana saja sebagai agen kustom. Agen kustom di Vertex AI Agent Engine dan di Cloud Run dapat menggunakan jalur jaringan pribadi yang ada tanpa mengonfigurasi resource jaringan tambahan. Untuk men-deploy agen kustom di GKE, Anda harus mengekspos layanan dengan Gateway eksternal. Untuk mengetahui informasi tentang cara mengonfigurasi Gateway eksternal agar lebih aman, lihat Jaringan GKE nanti dalam dokumen ini.

Untuk membuat permintaan ke agen kustom, Gemini Enterprise menggunakan identitas akun Vertex AI Discovery Engine Service. Jalur jaringan dan mekanisme otorisasi berbeda-beda berdasarkan platform hosting yang Anda gunakan:

  • Agen kustom di Vertex AI Agent Engine: Agen layanan Vertex AI Discovery Engine mencakup peran Identity and Access Management (IAM) Vertex AI yang diperlukan untuk memanggil resource Vertex AI Agent Engine sebagai fitur bawaan. Sistem merutekan permintaan yang dibuat ke layanan Vertex AI API melalui jaringan Google sebagai panggilan API internal.
  • Agen kustom di Cloud Run: Aplikasi Gemini Enterprise menggunakan identitas agen layanan Vertex AI Discovery Engine untuk melakukan panggilan ke URL run.app yang stabil dan terdaftar dari kartu agen. Agar layanan Cloud Run agen AI dapat mengizinkan panggilan ini, Anda harus memberikan peran IAM Cloud Run Invoker (roles/run.invoker) kepada Agen Layanan Discovery Engine. Permintaan ke Cloud Run dirutekan melalui jaringan produksi Google ke Google Front End (GFE) untuk masuknya Cloud Run.

  • Agen kustom di GKE: Aplikasi Gemini Enterprise menggunakan identitas agen layanan Vertex AI Discovery Engine untuk melakukan panggilan ke URL yang terdaftar dari kartu agen. DNS publik harus dapat me-resolve nama host ke alamat IP eksternal yang dikelola oleh Gateway. Sebaiknya gunakan gke-l7-regional-external-managed load balancer atau load balancer gke-l7-global-external-managed. Untuk keamanan tambahan, sebaiknya Gemini Enterprise memanggil agen A2A yang dihosting GKE menggunakan Identity-Aware Proxy (IAP). Agar IAP dapat mengizinkan panggilan ini, Anda harus memberikan peran IAM IAP-secured Web App User (roles/iap.httpsResourceAccessor) kepada agen layanan Discovery Engine. Jaringan produksi Google merutekan permintaan ke GKE ke GFE untuk ingress Load Balancer Aplikasi eksternal.

    Untuk mengamankan Ingress GKE dari Gemini Enterprise, lihat bagian IAP dan Google Cloud Armor di bagian selanjutnya dalam dokumen ini.

Jaringan pribadi untuk platform hosting agen

Setelah pengguna memulai permintaan ke aplikasi Gemini Enterprise, permintaan dimulai dari agen root kustom ke subagen dan alat. Platform hosting agen kustom menyediakan antarmuka antara Gemini Enterprise dan jaringan VPC Anda. Platform hosting untuk agen dan alat dalam container Anda adalah Vertex AI Agent Engine, Cloud Run, dan GKE.

Saat memilih platform hosting agen, Anda perlu mempertimbangkan pola jaringan pribadi, kontrol keamanan, kontrol pengelolaan, tingkat penyesuaian, dan kepatuhan keamanan setiap platform. Untuk mengetahui informasi selengkapnya tentang cara memilih platform hosting agen AI, lihat Memilih model dan infrastruktur untuk aplikasi AI generatif Anda dan Memilih komponen arsitektur AI agen Anda.

Anda membuat konektivitas VPC pribadi melalui berbagai mekanisme berdasarkan platform hosting agen yang Anda gunakan:

  • Agen kustom di Vertex AI Agent Engine: Antarmuka Private Service Connect menghubungkan runtime Vertex AI Agent Engine ke jaringan VPC. Anda membuat lampiran jaringan di subnet jaringan VPC Anda dan memberikan izin Vertex AI Agent Engine untuk melampirkannya. Traffic yang dikirim dari Vertex AI Agent Engine muncul di jaringan VPC seolah-olah berasal dari alamat IP subnet lampiran. Jaringan VPC kemudian merutekan traffic ke alamat IP tujuan yang sesuai.
  • Agen kustom di Cloud Run: Traffic keluar VPC Langsung Cloud Run menghubungkan instance layanan Cloud Run ke jaringan VPC. Jaringan VPC yang ditentukan saat layanan Cloud Run di-deploy dapat berasal dari project layanan Cloud Run atau dari project host VPC Bersama. Traffic yang dikirim dari Cloud Run muncul di jaringan VPC seolah-olah berasal dari alamat IP subnet traffic keluar VPC Langsung. Jaringan VPC kemudian merutekan traffic ke alamat IP tujuan yang sesuai.
  • Agen kustom di GKE: Cluster GKE berada langsung di jaringan VPC dan menggunakan alamat IP subnet lokal. Secara default, traffic keluar GKE menggunakan alamat IP Pod sebagai alamat IP sumber. Jika Anda mengonfigurasi penyamaran, traffic keluar GKE menggunakan alamat IP node sebagai alamat IP sumber. Semua traffic keluar GKE dirutekan oleh jaringan VPC.

Bagian berikut memberikan panduan tambahan untuk mengelola permintaan ingress dan egress ke dan dari jaringan VPC untuk setiap platform hosting agen. Pertimbangan jaringan berlaku untuk fungsi agen root dan subagen.

Jaringan Vertex AI Agent Engine

Bagian ini menjelaskan jaringan pribadi untuk agen root dan subagen yang dihosting di Vertex AI Agent Engine. Jika Anda menggunakan Vertex AI Agent Engine untuk menghosting agen root, Anda harus men-deploy Gemini Enterprise dan Vertex AI Agent Engine dalam project yang sama.

Vertex AI Agent Engine menghosting container di infrastruktur Google di luar jaringan VPC Anda. Untuk mengaktifkan konektivitas pribadi ke agen lain, Anda dapat menghubungkan agen ke jaringan VPC dengan menggunakan metode berikut:

Untuk mengizinkan permintaan antara agen Anda dan agen lainnya, siapkan kedua koneksi sebelumnya.

Traffic keluar Vertex AI Agent Engine ke jaringan VPC

Vertex AI Agent Engine menggunakan project tenant yang dikelola Google untuk keluar dari jaringan. Jaringan tenant menyediakan konektivitas bagi agen ke Google API dan untuk keluar dari internet publik, tetapi secara default tidak terhubung langsung ke jaringan VPC pelanggan.

Untuk menghubungkan agen ke resource yang berada di dalam jaringan VPC Anda, Vertex AI Agent Engine menggunakan antarmuka Private Service Connect. Vertex AI Agent Engine men-deploy antarmuka jaringan di project tenant yang terhubung ke resource lampiran jaringan di project Anda. Koneksi ini membuat jalur data yang aman antara runtime Vertex AI Agent Engine dan jaringan VPC. Saat Anda mengonfigurasi antarmuka Private Service Connect di project Vertex AI Agent Engine, sistem akan merutekan semua traffic agen yang tidak ditujukan untuk Google API ke jaringan VPC.

Untuk men-deploy egress jaringan VPC Vertex AI Agent Engine, lihat referensi berikut:

Untuk lebih mengamankan agen dan jaringan VPC untuk keluar dari Vertex AI Agent Engine, lihat bagian berikut dalam dokumen ini:

Ingress Vertex AI Agent Engine dari jaringan VPC

Permintaan ke agen yang berjalan di Vertex AI Agent Engine dilakukan dengan menggunakan endpoint Vertex AI API (aiplatform.googleapis.com). Untuk menjangkau endpoint Google API menggunakan jalur jaringan pribadi dari jaringan VPC, gunakan Akses Google Pribadi atau gunakan endpoint Private Service Connect untuk Google API.

Pengguna pribadi yang membuat kueri ke agen perlu menyelesaikan nama host endpoint Vertex AI API ke rentang alamat IP pribadi untuk Akses Google Pribadi atau ke alamat IP endpoint Private Service Connect untuk Google API. Zona Cloud DNS terkelola pribadi untuk googleapis.com menyelesaikan permintaan untuk Vertex AI API. Jaringan VPC merutekan permintaan secara langsung melalui jaringan produksi Google.

Jika Anda menggunakan Akses Google Pribadi atau Private Service Connect untuk Google API, Anda dapat membantu melindungi traffic dari jaringan VPC ke Vertex AI Agent Engine dengan menggunakan produk dan fitur berikut:

Pertimbangan jaringan tambahan Vertex AI Agent Engine

Egress Vertex AI Agent Engine yang menggunakan antarmuka Private Service Connect hanya dapat merutekan ke rentang alamat IP RFC 1918 di jaringan VPC. Untuk rentang tujuan tertentu yang tidak dapat dirutekan oleh keluar dari Vertex AI Agent Engine, lihat Persyaratan rentang IP subnetwork. Untuk menjangkau tujuan rentang alamat IP yang tidak dapat dirutekan, gunakan konfigurasi proxy eksplisit pada agen dan deploy resource proxy yang menggunakan alamat IP yang dapat dirutekan di jaringan VPC.

Saat di-deploy tanpa antarmuka Private Service Connect, Vertex AI Agent Engine memiliki akses ke internet secara default. Untuk melindungi dari pemindahan data yang tidak sah, nonaktifkan akses default dengan mengaktifkan Kontrol Layanan VPC.

Saat Vertex AI Agent Engine di-deploy dengan antarmuka Private Service Connect, egress internet langsung dinonaktifkan, terlepas dari Kontrol Layanan VPC. Jika Anda ingin agen Anda mengakses tujuan yang biasanya tidak dapat dijangkau oleh Vertex AI Agent Engine, seperti internet, lakukan hal berikut:

  1. Konfigurasi Secure Web Proxy di subnet RFC 1918 jaringan VPC Anda. Anda harus mengonfigurasi proxy dalam mode pemilihan rute proxy eksplisit.
  2. Buat data Cloud DNS untuk nama host Secure Web Proxy.
  3. Konfigurasi peering DNS untuk Vertex AI Agent Engine guna mendukung resolusi kueri DNS agen ke alamat pribadi Secure Web Proxy di jaringan VPC.
  4. Saat men-deploy agen, lakukan hal berikut:
    1. Tentukan variabel lingkungan untuk menggunakan proxy eksplisit dengan menentukan nama host dan port Secure Web Proxy.
    2. Jika Anda mengakses tujuan pribadi, konfigurasi zona DNS pribadi untuk tujuan tersebut.

Setelah traffic keluar dari Vertex AI Agent Engine mencapai jaringan VPC, traffic tersebut dapat mencapai tujuan jaringan mana pun yang dapat dirutekan oleh jaringan VPC. Untuk mengetahui informasi tentang cara membatasi cakupan tujuan jaringan keluar yang tersedia untuk agen Vertex AI Agent Engine, lihat bagian Cloud NGFW nanti dalam dokumen ini.

Jaringan Cloud Run

Bagian ini menjelaskan jaringan pribadi untuk agen root dan subagen yang dihosting di Cloud Run. Cloud Run menghosting container di infrastruktur Google di luar jaringan VPC Anda. Untuk mengaktifkan konektivitas pribadi ke agen lain, Anda dapat menghubungkan agen ke jaringan VPC menggunakan metode berikut:

Untuk mengizinkan permintaan antara agen Anda dan agen lainnya, siapkan kedua koneksi sebelumnya.

Traffic keluar Cloud Run ke jaringan VPC

Untuk memulai koneksi Cloud Run ke jaringan VPC, sebaiknya gunakan traffic keluar VPC Langsung. Dengan traffic keluar VPC Langsung, instance Cloud Run terhubung langsung ke jaringan VPC bersama menggunakan alamat IP dari subnet yang Anda tentukan saat men-deploy traffic keluar VPC Langsung.

Saat Anda mengonfigurasi Traffic keluar VPC langsung, lakukan hal berikut:

  1. Konfigurasi subnet target dengan Akses Google Pribadi yang diaktifkan.
  2. Konfigurasi perutean traffic untuk merutekan semua traffic ke jaringan VPC.

Konfigurasi ini mengirimkan semua traffic melalui jaringan VPC untuk privasi dan mengirimkan permintaan dari Cloud Run ke Google API lainnya melalui jaringan internal Google.

Semua kueri DNS dari Cloud Run menggunakan kebijakan dan zona Cloud DNS yang terkait dengan jaringan VPC. Tidak diperlukan konfigurasi peering DNS tambahan. Agen yang dihosting di Cloud Run me-resolve semua nama host publik dan zona pribadi Cloud DNS.

Untuk mengetahui informasi tentang cara mengamankan lebih lanjut agen dan jaringan VPC untuk traffic keluar Cloud Run, lihat bagian berikut dalam dokumen ini:

Traffic masuk Cloud Run dari jaringan VPC

Cloud Run adalah platform yang dikelola Google yang beroperasi di lingkungan di luar jaringan VPC. Lingkungan ini menghosting endpoint URL *.run.app yang stabil untuk layanan Cloud Run yang menjalankan beban kerja alat atau agen AI. Endpoint ini disalurkan oleh titik masuk GFE yang sama yang menyalurkan layanan API *.googleapis.com. Cloud Run menggunakan jalur jaringan pokok yang sama yang memungkinkan konektivitas pribadi untuk Akses Google Pribadi dan untuk Private Service Connect untuk Google API.

Pengguna pribadi di jaringan VPC yang membuat kueri ke agen atau alat perlu menyelesaikan nama host run.app ke rentang alamat IP pribadi untuk Akses Google Pribadi atau ke alamat IP endpoint Private Service Connect untuk Google API. Zona Cloud DNS terkelola pribadi untuk run.app URL menyelesaikan permintaan untuk layanan Cloud Run. Jaringan VPC merutekan permintaan secara langsung melalui jaringan produksi Google.

Menyetel ingress Cloud Run ke Internal akan membatasi akses ke layanan Anda dengan hanya mengizinkan permintaan dari sumber internal yang terverifikasi. Sumber yang disetujui mencakup hal berikut:

  • Jaringan VPC project layanan Cloud Run.
  • Jaringan VPC Bersama yang menghosting endpoint traffic keluar VPC Langsung.
  • Resource yang berada dalam perimeter Kontrol Layanan VPC yang sama.
  • Load Balancer Aplikasi internal di jaringan VPC.
  • Layanan Google seperti Cloud Scheduler dan Pub/Sub yang berada dalam project layanan atau perimeter Kontrol Layanan VPC.

Jika Anda tidak menggunakan perimeter Kontrol Layanan VPC umum untuk mencakup layanan yang memanggil dan dipanggil, traffic dari luar project layanan Cloud Run atau lingkungan VPC Bersama akan diperlakukan sebagai eksternal. Traffic tersebut mencakup traffic dari layanan Google Cloud lain seperti Vertex AI Agent Engine dan layanan Cloud Run lainnya. Untuk memenuhi pemeriksaan ingress Internal Cloud Run, traffic ini harus dirutekan sedemikian rupa sehingga tampak berasal dari dalam jaringan VPC layanan target.

Untuk memberikan atribusi jaringan internal yang diperlukan, Anda dapat melakukan salah satu hal berikut:

  • Gunakan endpoint Private Service Connect untuk mengizinkan layanan di VPC atau project lain terhubung ke Google API dan layanan, termasuk layanan Cloud Run Anda, dengan menggunakan alamat IP pribadi dalam jaringan VPC Anda.
  • Merutekan traffic melalui Load Balancer Aplikasi internal yang ditempatkan di dalam jaringan VPC Anda di depan layanan Cloud Run Anda. Load balancer menyalurkan permintaan dari layanan lain melalui jaringan VPC sehingga memenuhi kriteria ingress internal.

Load Balancer Aplikasi Internal dengan backend grup endpoint jaringan (NEG) serverless membuat resource VPC yang dipetakan langsung ke layanan Cloud Run. Dalam model ini, load balancer menghentikan koneksi TLS klien dengan sertifikat tepercaya. Load Balancer Aplikasi Internal mendukung kontrol keamanan tambahan termasuk kebijakan keamanan backend Cloud Armor dan kebijakan otorisasi tambahan.

Secara default, akses ke semua layanan Cloud Run memerlukan autentikasi IAM. Sebaiknya gunakan identitas berdasarkan per layanan dan berikan peran IAM Cloud Run Invoker (roles/run.invoker) kepada principal.

Untuk mengetahui informasi tentang cara mengonfigurasi kontrol traffic masuk Cloud Run, lihat referensi berikut:

Jika Anda menggunakan Akses Google Pribadi atau endpoint Private Service Connect untuk Google API guna mengirim traffic dari jaringan VPC ke Cloud Run, Anda dapat membantu melindungi traffic tersebut dengan menggunakan produk dan fitur berikut:

Jika Anda menggunakan Load Balancer Aplikasi internal untuk mengirim traffic dari jaringan VPC ke Cloud Run, Anda dapat membantu melindungi traffic tersebut dengan menggunakan produk dan fitur berikut:

Jaringan GKE

Bagian ini menjelaskan jaringan untuk agen yang berbasis GKE.

GKE dan Gemini Enterprise

Sebagai host untuk alat dan agen AI, GKE menawarkan platform yang sangat dapat disesuaikan untuk kontrol jaringan dan keamanan. Sistem AI multi-agen yang di-deploy di GKE dapat memberikan efisiensi operasional dalam skala besar. Aplikasi ini dapat terintegrasi erat dengan aplikasi Kubernetes lainnya dan arsitektur mikroservice yang lebih besar.

Cluster GKE adalah node VM Compute Engine yang berjalan dalam subnet jaringan VPC. Aplikasi Gemini Enterprise adalah resource terkelola yang beroperasi di lingkungan yang dihosting di luar jaringan VPC. Untuk mengaktifkan aplikasi Gemini Enterprise memanggil agen kustom yang dihosting di GKE, Anda harus mengekspos Gateway eksternal dengan aman menggunakan alamat IP publik dan nama DNS. Traffic mengalir dari keluar Gemini Enterprise ke jaringan edge Google yang mengambil rute yang dioptimalkan ke load balancer eksternal GKE.

Penting untuk mengamankan endpoint GKE menggunakan autentikasi dan otorisasi yang kuat, Cloud Armor, dan izin terbatas. Untuk menyediakan model pertahanan yang mendalam dan komprehensif guna mengamankan agen AI yang berjalan di GKE, pertimbangkan kontrol keamanan yang dijelaskan di bagian berikut.

Mode operasi GKE

GKE menawarkan mode operasi ini untuk menyeimbangkan pengelolaan dan kontrol:

  • Autopilot: Google mengotomatiskan seluruh infrastruktur cluster GKE, termasuk bidang kontrol, penyediaan node, penguatan keamanan, dan penskalaan.
  • Standard: Google mengelola bidang kontrol. Anda tetap memiliki tanggung jawab penuh atas konfigurasi node pool, seperti memilih jenis mesin, mengelola image OS, dan penskalaan manual.
Penguatan infrastruktur dan bidang kontrol
  • Cluster GKE pribadi: Menyediakan node tanpa alamat IP publik, yang memastikan lingkungan runtime terisolasi dari eksposur langsung ke internet.
  • Jaringan yang diizinkan master: Membatasi akses administratif ke Kubernetes API untuk rentang alamat IP tertentu yang tepercaya, yang memperkuat bidang kontrol terhadap perubahan konfigurasi yang tidak sah. Amankan Endpoint DNS untuk Kubernetes API menggunakan IAM Google Clouddan Kontrol Layanan VPC.
Identitas dan akses (zero trust)
  • IAP: Bertindak sebagai penjaga di tingkat load balancer. Hal ini memastikan bahwa hanya pengguna terautentikasi dengan izin IAM yang benar yang dapat mengakses endpoint agen. Pendekatan ini secara efektif mengalihkan perimeter keamanan dari jaringan ke pengguna perorangan dan konteks perangkatnya.
Perlindungan edge dan pengelolaan traffic
  • Cloud Armor: Menyediakan keamanan edge yang tangguh, termasuk aturan Firewall Aplikasi Web (WAF) untuk membantu memblokir payload berbahaya, perlindungan DDoS untuk membantu memastikan waktu aktif, dan pembatasan kecepatan untuk membantu mencegah kelelahan layanan.
  • Model Armor: Dirancang khusus untuk keamanan LLM, Model Armor memeriksa dan membersihkan perintah dan respons secara real-time untuk mencegah injeksi perintah dan pemindahan data yang tidak sah.
Isolasi jaringan internal
  • Kebijakan jaringan Kubernetes: Menerapkan komunikasi yang terperinci dan hak istimewa paling rendah antar-microservice. Secara default, kebijakan menolak semua traffic kecuali jika Anda mengizinkannya secara eksplisit, yang mencegah pergerakan lateral dalam cluster.

Traffic keluar GKE ke jaringan VPC

Jaringan VPC merutekan koneksi keluar dari agen yang dihosting di GKE. Mode jaringan cluster GKE default adalah VPC native, yang memberikan atribut berikut:

  • Cluster GKE menggunakan rentang alamat IP alias.
  • Alamat IP Pod dicadangkan dengan menentukan rentang IP Pod.
  • Alamat IP pod dapat dirutekan secara native dalam jaringan VPC cluster dan jaringan VPC terhubung lainnya.

Jika Pod agen berkomunikasi dengan Pod subagen di node yang sama, maka traffic akan dirutekan secara lokal dalam namespace jaringan node. Jika Pod agen tujuan berada di node yang berbeda dalam cluster, traffic akan dirutekan menggunakan tabel perutean jaringan VPC. Agar Pod agen dapat berkomunikasi dengan resource VPC lain seperti load balancer atau endpoint Private Service Connect, Pod tersebut dapat mencapai tujuan menggunakan perutean VPC standar yang sama, sesuai dengan aturan firewall.

Anda dapat membantu melindungi traffic yang keluar dari cluster GKE dengan menggunakan produk dan layanan berikut:

Ingress GKE dari jaringan VPC

Layanan Kubernetes menyediakan akses ke resource GKE. Untuk sistem AI multi-agen, sebaiknya Anda menggunakan GKE Gateway atau GKE Inference Gateway. Gateway memberikan kemampuan yang ditingkatkan dengan kontrol traffic, pemisahan operasional resource, dan integrasi keamanan. Namun, opsi layanan ingress lainnya tersedia bergantung pada persyaratan sistem Anda.

Resource Gateway membuat Load Balancer Aplikasi dan menyediakan semua komponen load balancing yang diperlukan. Grup endpoint jaringan backend layanan terhubung untuk menyediakan load balancing langsung ke container. Untuk mengekspos layanan secara internal untuk traffic yang berasal dari jaringan VPC, gunakan class Gateway untuk Load Balancer Aplikasi internal regional (gke-l7-rilb) atau Load Balancer Aplikasi internal lintas region (gke-l7-cross-regional-internal-managed-mc).

Load Balancer Aplikasi menyediakan titik kontrol keamanan tambahan untuk melindungi agen dan alat AI yang dihosting di cluster GKE:

  • Cloud Armor: Melindungi layanan dengan melampirkan kebijakan keamanan Cloud Armor ke layanan backend yang dikelola oleh Gateway. Cloud Armor menyediakan pemeriksaan WAF, pemfilteran berbasis IP dan geolokasi, perlindungan DDoS, dan pembatasan frekuensi sebelum traffic mencapai cluster GKE atau IAP.
  • IAP: Diaktifkan di layanan backend untuk mengontrol akses ke aplikasi menggunakan kredensial IAM, IAP menerapkan kebijakan akses zero-trust. IAP mengautentikasi dan mengizinkan agen AI yang mengakses resource cluster, termasuk aplikasi Gemini Enterprise, agen kustom, dan resource eksternal. Layanan ini mengharuskan pemanggil memiliki identitas yang diautentikasi oleh IAM dan memiliki izin yang sah untuk mengakses layanan backend.

Jika Anda mengirim traffic dari jaringan VPC ke layanan GKE melalui Gateway, Anda dapat membantu melindungi traffic tersebut dengan menggunakan produk dan fitur berikut:

Jika Anda tidak menggunakan Gateway untuk mengirim traffic dari jaringan VPC ke layanan GKE, Anda dapat membantu melindungi traffic tersebut dengan menggunakan produk dan layanan berikut:

Untuk mengetahui informasi selengkapnya tentang mengamankan GKE, lihat Praktik terbaik keamanan jaringan dan Memahami keamanan jaringan di GKE.

Keamanan jaringan agen

Untuk melindungi jaringan sistem AI multi-agen, Anda harus mengamankan komunikasi melalui jaringan VPC dan permukaan API. Bidang data jaringan VPC membahas cara agen dan alat terhubung dengan aman. Permukaan API menentukan identitas dan jenis pertukaran data yang diizinkan. Pelapisan kontrol akses di seluruh jaringan VPC dan permukaan API membantu menerapkan postur keamanan yang sangat terkontrol dan tangguh.

Cloud NGFW

Cloud NGFW bertindak sebagai penjaga gerbang tingkat jaringan untuk mengamankan komunikasi A2A dan MCP. Firewall memastikan bahwa hanya traffic yang diizinkan yang dapat mencapai endpoint agen dengan memverifikasi setiap koneksi masuk atau keluar ke dan dari agen serta alat lainnya.

Cloud NGFW adalah layanan firewall terdistribusi yang dibangun ke dalam fabric jaringan VPC. Fitur ini menawarkan tingkat fitur yang beroperasi di berbagai lapisan stack jaringan:

  • Cloud Next Generation Firewall Essentials: Menyediakan pemfilteran paket firewall stateful. Aturan kebijakan ditentukan berdasarkan alamat IP (L3), protokol, dan port (L4).
  • Cloud Next Generation Firewall Standard: Menyediakan penegakan berbasis IP dengan objek Nama Domain yang Sepenuhnya Memenuhi Syarat (FQDN), objek geolokasi, dan feed dari Google Threat Intelligence untuk memblokir alamat berbahaya yang diketahui.
  • Cloud Next Generation Firewall Enterprise: Menyediakan kemampuan pemeriksaan aplikasi (L7) yang sebenarnya dengan kemampuan dekripsi TLS dan sistem deteksi dan pencegahan intrusi (IDPS) untuk menganalisis payload terhadap tanda tangan ancaman tingkat lanjut.

Cloud NGFW dapat diterapkan di jaringan VPC untuk menerapkan kebijakan firewall berdasarkan aturan yang diperlukan untuk menargetkan platform hosting agen yang Anda gunakan.

  • Vertex AI Agent Engine: Agen yang berjalan di Vertex AI Agent Engine terhubung ke jaringan VPC menggunakan lampiran jaringan Private Service Connect. Lampiran ini membuat antarmuka jaringan agen muncul dalam subnet di jaringan VPC. Kebijakan firewall jaringan Cloud NGFW diterapkan ke jaringan VPC. Kebijakan memfilter traffic berdasarkan alamat IP sumber dari subnet yang dikhususkan untuk lampiran jaringan Private Service Connect. Untuk pencocokan traffic, Anda dapat menggunakan rentang alamat IP sumber dan alamat IP tujuan.
  • Cloud Run: Layanan Cloud Run yang menggunakan traffic keluar VPC Langsung mengirim traffic langsung dari instance yang berjalan dalam subnet yang ditentukan di jaringan VPC. Kebijakan firewall jaringan Cloud NGFW berlaku untuk subnet yang digunakan oleh Cloud Run untuk memfilter traffic. Untuk pencocokan traffic, Anda dapat menggunakan rentang alamat IP sumber dan rentang alamat IP tujuan.
  • GKE: Cluster GKE VPC native memberikan alamat IP Pod yang langsung dari rentang alamat IP sekunder jaringan VPC. Kebijakan firewall jaringan dapat memfilter traffic berdasarkan rentang alamat IP untuk node dan Pod GKE, dan kebijakan dapat menggunakan tag aman dan akun layanan. Tag aman terikat ke instance VM yang bertindak sebagai node GKE. Aturan firewall kemudian dapat menargetkan atau mendapatkan traffic dari node yang memiliki tag tertentu. Aturan firewall juga dapat menargetkan atau mendapatkan traffic dari node GKE berdasarkan identitas akun layanan yang terkait dengan node pool.

Kebijakan keluar dengan penolakan default

Menerapkan strategi penolakan default adalah praktik terbaik keamanan yang mematuhi prinsip hak istimewa terendah. Strategi ini memastikan hanya traffic jaringan yang diizinkan secara eksplisit yang diizinkan, sementara semua traffic lainnya diblokir secara default. Penerapan ini dilakukan dengan menyusun aturan firewall dengan aturan ALLOW berprioritas tinggi untuk alur yang diketahui dan sah, serta aturan DENY serba guna berprioritas rendah. Semua tingkat Cloud NGFW mengizinkan aturan berdasarkan rentang alamat IP sumber dan tujuan.

Aturan kebijakan firewall dapat secara efektif mencocokkan traffic sumber dari subnet lampiran jaringan Vertex AI Agent Engine dan dari subnet keluar VPC Langsung Cloud Run.

Berikut adalah contoh kebijakan egress tolak-default:

  • Membuat kebijakan dan aturan firewall jaringan: Buat kebijakan firewall global atau regional dan kaitkan kebijakan tersebut dengan jaringan VPC. Buat aturan kebijakan firewall yang menargetkan traffic ke arah keluar (--direction=EGRESS) berdasarkan rentang alamat IP sumber (--src-ip-ranges=SRC_IP_RANGES) dan rentang alamat IP tujuan (--dest-ip-ranges=DEST_IP_RANGES).
  • Aturan ALLOWspesifik: Gunakan angka prioritas yang lebih rendah, misalnya 100-1000. Aturan ini secara tepat mengizinkan traffic jaringan yang diperlukan agar agen AI Anda dapat berfungsi. Traffic ini mencakup komunikasi ke layanan internal lainnya, load balancer, Google API yang diperlukan, atau endpoint eksternal yang sah. Buat aturan yang cocok dengan traffic sumber dari subnet lampiran jaringan Vertex AI Agent Engine atau dari subnet traffic keluar VPC Langsung Cloud Run ke tujuan yang Anda inginkan.
  • Aturan DENY umum: Untuk memastikan bahwa aturan ini adalah yang terakhir dalam urutan evaluasi, gunakan nomor prioritas tertinggi, misalnya 2147483647. Aturan ini menolak traffic ke tujuan mana pun (--dest-ip-ranges=0.0.0.0/0) yang tidak cocok dengan aturan ALLOW sebelumnya.

Kebijakan keluar tolak default mencegah agen AI membuat koneksi jaringan yang tidak diizinkan secara eksplisit dan memblokir potensi eksfiltrasi data atau akses ke situs berbahaya. Kebijakan ini membatasi agen yang dihosting agar hanya berkomunikasi dengan endpoint yang disetujui, yang sangat penting untuk mempertahankan kontrol atas workload otonom.

Pertimbangan kebijakan Cloud NGFW tambahan

Selain strategi penolakan default yang tersedia dengan semua tingkatan Cloud NGFW, Anda dapat lebih memperkuat keamanan jaringan AI multi-agen dengan menggunakan fitur tingkat berbayar:

  • Fitur Cloud NGFW Standard:
    • Objek FQDN untuk endpoint dinamis: Agen AI sering berinteraksi dengan API eksternal, endpoint model, atau sumber data yang alamat IP-nya dapat berubah. Untuk akses yang konsisten ke layanan yang diperlukan berdasarkan nama domain, gunakan objek FQDN dalam aturan ALLOW.
    • Kontrol geolokasi: Jika agen AI memiliki persyaratan kepatuhan atau jika agen AI tidak boleh berinteraksi dengan layanan di wilayah geografis tertentu, gunakan objek geolokasi (--src-region-codes=SRC_COUNTRY_CODES) dalam aturan firewall Anda untuk membatasi traffic ke atau dari lokasi tersebut.
    • Google Threat Intelligence: Gunakan Google Threat Intelligence dalam filter keluar untuk otomatis memblokir agen agar tidak terhubung ke tujuan berbahaya yang diketahui, seperti server command and control (C2), anonimizer seperti Tor, dan situs distribusi malware. Penggunaan Google Threat Intelligence membantu membatasi dampak agen yang berpotensi disusupi. Sebaiknya sertakan filter tujuan ini dalam aturan DENY dengan nomor prioritas yang lebih tinggi (urutan evaluasi yang lebih rendah).
  • Fitur Cloud NGFW Enterprise:
    • Pemeriksaan Layer 7: Untuk agen yang menangani data sensitif atau yang berisiko lebih tinggi, periksa payload paket untuk mendeteksi ancaman seperti malware, spyware, dan eksploitasi yang tidak dianalisis oleh aturan firewall lapisan jaringan.
    • Pemeriksaan TLS: Untuk mengizinkan mesin pemeriksaan menganalisis traffic terenkripsi, aktifkan pemeriksaan TLS. Penggunaan inspeksi TLS sangat penting karena sebagian besar serangan modern dan komunikasi C2 dienkripsi.

Untuk pertimbangan atau batasan penerapan tambahan yang mungkin berlaku untuk lingkungan Anda, lihat referensi berikut:

IAP

IAP mengamankan permintaan ingress ke cluster GKE dengan menyediakan lapisan otorisasi dan autentikasi pusat untuk aplikasi AI. IAP mencegat semua permintaan HTTPS yang ditujukan untuk Gateway, dan memeriksa identitas serta izin pemanggil. IAP hanya mengizinkan permintaan terautentikasi dan berwenang untuk diteruskan ke beban kerja layanan backend. IAP di load balancer Gateway hanya melindungi traffic yang berasal dari luar cluster. Komunikasi dalam cluster tidak melewati IAP.

Untuk mengakses aplikasi AI yang dihosting di GKE dan dilindungi oleh IAP, identitas pengguna utama harus diberi peran IAM IAP-secured Web App User (roles/iap.httpsResourceAccessor) di resource layanan backend yang dilindungi IAP. Sebaiknya konfigurasi akun layanan kustom sebagai identitas untuk agen yang di-deploy. Dengan akun layanan kustom, Anda dapat menetapkan izin secara lebih tepat sesuai dengan prinsip hak istimewa terendah.

Hanya berikan peran IAM Web App User yang diamankan oleh IAP secara langsung ke akun layanan agen yang diizinkan untuk mengakses agen dan alat lain yang dihosting di resource kustom BackendConfig GKE. Untuk mengizinkan akses aplikasi Gemini Enterprise, berikan izin dengan mengikat peran IAM Akun Layanan Discovery Engine (roles/discoveryengine.serviceAgent) untuk project Gemini Enterprise Anda.

Kontrol Layanan VPC

Kontrol Layanan VPC mengurangi risiko pemindahan data yang tidak sah dengan mengontrol akses ke Google API secara ketat. Sebaiknya deploy satu perimeter makro yang mencakup semua layanan yang didukung. Pendekatan ini memberikan pertahanan paling tangguh terhadap eksfiltrasi. Untuk memastikan penerapan kebijakan yang konsisten untuk arsitektur VPC Bersama, penting untuk menyertakan project host dan semua project layanan terkait dalam perimeter layanan yang sama.

Untuk mengamankan interaksi antara Gemini Enterprise dan Cloud Run di seluruh batas project, pertimbangkan rekomendasi berikut:

  • Deploy perimeter Kontrol Layanan VPC tunggal yang mencakup project Gemini Enterprise dan Cloud Run.
  • Tambahkan semua layanan yang didukung Kontrol Layanan VPC ke daftar layanan yang dibatasi. Pendekatan ini membantu mencegah perubahan administratif yang tidak sah.
  • Terapkan setelan ingress dan otorisasi internal untuk memblokir semua akses internet publik ke layanan Cloud Run Anda.

Layanan Cloud Run diamankan oleh IAM. Pemanggil harus diautentikasi dan harus memiliki peran IAM Cloud Run Invoker (roles/run.invoker) pada layanan target. Peran diperiksa dengan memvalidasi token dari header Otorisasi. Agar berhasil memanggil layanan Cloud Run, akun layanan, seperti yang digunakan oleh Gemini Enterprise, juga harus diberi peran Cloud Run Invoker.

Jika Gemini Enterprise dan Cloud Run di-deploy di project yang berbeda, perimeter Kontrol Layanan VPC diperlukan untuk menyetel ingress Cloud Run ke Internal. Tanpa perimeter ini, panggilan lintas project dari Gemini diperlakukan sebagai traffic eksternal, yang mengharuskan Anda menyetel ingress Cloud Run ke Semua—yang membuat layanan terekspos ke internet publik.

  • Ingress Cloud Run all didukung jika kedua hal berikut benar:
    • Kontrol Layanan VPC tidak diaktifkan.
    • Cloud Run dan Gemini Enterprise tidak berada dalam project yang sama.
  • Hanya ingress Cloud Run internal yang didukung untuk semua konfigurasi lainnya.

Pertimbangan tambahan Kontrol Layanan VPC

Saat Cloud Run di-deploy di dalam perimeter Kontrol Layanan VPC, sebaiknya Anda menerapkan panduan kebijakan berikut untuk membantu memastikan perlindungan yang komprehensif:

  • Membatasi setelan traffic masuk yang diizinkan: Mencegah developer men-deploy endpoint yang menghadap publik secara tidak sengaja dengan menetapkan batasan kebijakan organisasi run.allowedIngress. Batasan ini hanya berlaku untuk deployment baru. Penerapan sebelumnya mungkin tidak mematuhi kebijakan. Sebaiknya Anda mengaudit layanan Cloud Run yang ada dalam perimeter dan men-deploy ulang atau mengupdate layanan yang tidak memenuhi setelan ingress dan egress yang diperlukan.
    • Untuk mengizinkan hanya permintaan internal, tetapkan nilai ke internal.
    • Untuk mengizinkan permintaan melalui Load Balancer Aplikasi eksternal, tetapkan nilai ke internal-and-cloud-load-balancing.
  • Membatasi setelan traffic keluar VPC yang diizinkan: Untuk merutekan semua permintaan keluar melalui VPC agar dapat diperiksa oleh aturan firewall perimeter, tetapkan nilai batasan kebijakan organisasi run.allowedVPCEgress ke all-traffic. Setelan ini mewajibkan setiap revisi Cloud Run menggunakan traffic keluar VPC Langsung atau konektor Akses VPC Serverless. Batasan ini hanya berlaku untuk deployment baru. Penerapan sebelumnya mungkin tidak mematuhi kebijakan. Sebaiknya Anda mengaudit layanan Cloud Run yang ada dalam perimeter dan men-deploy ulang atau mengupdate layanan yang tidak memenuhi setelan ingress dan egress yang diperlukan.
  • Menempatkan image dan layanan container secara bersamaan: Repositori Artifact Registry yang berisi image container Anda harus berada dalam perimeter yang sama dengan layanan Cloud Run. Penarikan image lintas perimeter diblokir secara otomatis kecuali jika Anda menetapkan aturan ingress dan egress secara eksplisit.
  • Mengelola tingkat akses: Aturan kebijakan ingress Kontrol Layanan VPC dan tingkat akses yang mengandalkan identitas principal IAM tidak didukung untuk pemanggilan Cloud Run. Sebagai gantinya, Anda harus mengelola akses dengan kriteria berbasis jaringan atau tingkat akses berbasis perangkat.

Model Armor

Model Armor adalah layanan berbasis API yang memberikan keamanan dan keselamatan yang ditingkatkan untuk aplikasi AI. Agen AI berinteraksi dengan Model Armor dengan melakukan panggilan untuk membersihkan perintah pengguna sebelum dikirim ke LLM dan untuk membersihkan respons model sebelum ditampilkan kepada pengguna. Model Armor secara aktif menyaring perintah dan respons LLM, yang memberikan titik pemeriksaan penting untuk mendeteksi risiko yang muncul dan menyediakan titik kontrol untuk menerapkan standar AI yang bertanggung jawab. Sebaiknya Anda menggunakan Model Armor untuk memastikan kepatuhan terhadap persyaratan residensi data dan peraturan hukum kedaulatan data. Untuk menggunakan Model Armor dalam perimeter Kontrol Layanan VPC, Anda harus mengonfigurasi endpoint Private Service Connect untuk endpoint regional Model Armor dalam jaringan VPC Anda.

Model Armor adalah layanan regional yang diakses secara pribadi melalui endpoint Private Service Connect regional di jaringan VPC. Misalnya, layanan us-central1 dipanggil dengan menggunakan endpoint regional modelarmor.us-central1.rep.googleapis.com. Endpoint regional membantu memastikan residensi data.

Untuk mengaktifkan akses bagi agen, konfigurasikan komponen berikut di setiap region tempat layanan Model Armor diperlukan:

  1. Buat atau identifikasi subnet RFC 1918 di region jaringan VPC tempat layanan Model Armor berada.
  2. Buat endpoint regional di subnet RFC 1918.
  3. Buat zona pribadi Cloud DNS dan data untuk nama host endpoint regional Model Armor (misalnya, modelarmor.us-central1.rep.googleapis.com) yang di-resolve ke alamat IP endpoint regional.
  4. Untuk interoperabilitas Vertex AI Agent Engine, buat peering DNS dari Vertex AI Agent Engine ke zona pribadi Cloud DNS yang terkait dengan jaringan VPC Anda. Saat agen membuat permintaan ke Model Armor, Cloud DNS menyelesaikan permintaan nama host ke alamat IP endpoint regional Private Service Connect di jaringan VPC. Langkah ini tidak diperlukan untuk agen yang dihosting di Cloud Run dan GKE.

Untuk mengintegrasikan Gemini Enterprise dengan Model Armor, buat template Model Armor di project yang sama dengan Gemini Enterprise. Lokasi template dan aplikasi Gemini Enterprise harus sama.

Untuk mengetahui informasi selengkapnya tentang cara mengaktifkan Model Armor, lihat referensi berikut:

Cloud Armor

Cloud Armor adalah layanan keamanan jaringan terdistribusi yang melindungi aplikasi dan layanan di belakang load balancer sebelum permintaan mencapai runtime layanan backend. Workload agen AI melibatkan komunikasi antar-layanan dalam volume tinggi yang menggunakan panggilan A2A, MCP, dan API. Perlindungan Cloud Armor memberikan lapisan tambahan ketahanan dalam desain keamanan dengan pembatasan kecepatan, pemeriksaan WAF, dan aturan kustom yang sesuai dengan permintaan agentik yang diharapkan. Dengan melampirkan kebijakan keamanan Cloud Armor ke layanan backend Application Load Balancer, traffic dapat difilter untuk permintaan berbahaya dan diatur dengan batas kecepatan, serta serangan DDoS dapat dimitigasi.

Cloud Armor dapat di-deploy dalam arsitektur jaringan agen dalam skenario berikut:

  • Cloud Run dengan Load Balancer Aplikasi internal: Lindungi agen dan alat yang berjalan di Cloud Run dengan menggunakan Load Balancer Aplikasi internal dengan backend NEG serverless. Terapkan kebijakan keamanan backend ke NEG serverless untuk menerapkan aturan WAF bagi traffic internal dan pembatasan kapasitas. Untuk mengontrol komunikasi agen, Anda dapat menentukan aturan kustom tambahan berdasarkan alamat IP dan header.
  • Gateway: Lindungi agen dan alat yang berjalan di GKE dengan menggunakan definisi resource Gateway untuk Load Balancer Aplikasi eksternal global atau regional dengan backend NEG zonal. Gunakan Kubernetes Gateway API untuk menerapkan resource GCPBackendPolicy dengan kebijakan keamanan Cloud Armor yang ditentukan. Jika Anda menggunakan Load Balancer Aplikasi eksternal regional, Cloud Armor mendukung kebijakan keamanan backend dengan aturan WAF, kontrol berbasis IP dan geografis, serta pembatasan kapasitas. Load Balancer Aplikasi eksternal global mendukung kebijakan keamanan backend dan kebijakan keamanan edge tambahan dengan Perlindungan Adaptif Google Cloud Armor dan Google Threat Intelligence.

Secure Web Proxy

Secure Web Proxy adalah layanan terkelola regional yang di-deploy dalam jaringan VPC untuk memfilter traffic HTTP/S yang berasal dari dalam jaringan VPC atau dalam jaringan yang terhubung. Layanan ini berfungsi sebagai proxy terpusat dan titik penerapan keamanan untuk memberikan kontrol dan visibilitas terperinci untuk traffic internet keluar. Selain itu, proxy ini berfungsi sebagai proxy eksplisit untuk komunikasi layanan internal.

Secure Web Proxy mendukung tiga mode deployment: mode perutean proxy eksplisit, mode lampiran layanan Private Service Connect, dan mode hop berikutnya. Sebaiknya gunakan Secure Web Proxy dalam mode perutean proxy eksplisit, yang menjadi fokus dokumen ini. Dalam mode ini, klien HTTP harus dikonfigurasi secara eksplisit untuk mengarah langsung ke alamat IP atau nama host Secure Web Proxy.

Untuk men-deploy Secure Web Proxy di jaringan VPC, Anda harus mengonfigurasi subnet frontend dan subnet khusus proxy. Secure Web Proxy adalah layanan yang terkelola sepenuhnya. Saat di-deploy, Secure Web Proxy akan otomatis men-deploy dan mengonfigurasi Cloud Router dan Cloud NAT di jaringan VPC Anda untuk integrasi tertentu dengan resource proxy. Konfigurasi ini mewajibkan semua permintaan keluar harus melewati Secure Web Proxy sebelum keluar ke internet.

Menggunakan Secure Web Proxy sebagai proxy eksplisit mendukung permintaan agen yang berasal dari antarmuka Private Service Connect Vertex AI Agent Engine, egress VPC Langsung Cloud Run, dan cluster GKE native VPC. Saat mengirim permintaan ke Secure Web Proxy menggunakan metode HTTP CONNECT, traffic sesi TCP akan di-tunnel ke proxy tempat aturan kebijakan keamanan diterapkan. Jika traffic diizinkan, Secure Web Proxy akan mengirimkan traffic ke egress internet yang dikontrol atau ke tujuan jaringan pribadi yang dapat dirutekan oleh jaringan VPC.

Perutean proxy eksplisit

Traffic keluar Vertex AI Agent Engine mengharuskan Anda menggunakan konfigurasi proxy eksplisit agar agen dapat menjangkau tujuan internet atau rentang alamat IP yang tidak dapat dirutekan di jaringan VPC. Untuk interoperabilitas Vertex AI Agent Engine, sebaiknya konfigurasi resource Secure Web Proxy dengan alamat IP RFC 1918 dari subnet frontend di jaringan VPC. Dengan konfigurasi ini, Secure Web Proxy dapat dijangkau langsung dari Vertex AI Agent Engine. Kemudian, proxy ini dapat memproksi koneksi apa pun ke tujuan alamat IP yang tidak dapat dirutekan yang berada di jaringan VPC atau di jaringan yang terhubung.

Untuk mendukung penggunaan Secure Web Proxy oleh platform hosting agen dalam mode perutean eksplisit, konfigurasi resource jaringan berikut:

  1. Buat atau identifikasi subnet RFC 1918 di jaringan VPC untuk menghosting resource Secure Web Proxy.
  2. Buat data Cloud DNS untuk nama host Secure Web Proxy (misalnya, swp.example.com) yang di-resolve ke alamat IP resource Secure Web Proxy.
  3. Untuk interoperabilitas Vertex AI Agent Engine, buat peering DNS dari Vertex AI Agent Engine ke zona pribadi Cloud DNS yang terkait dengan jaringan VPC Anda. Saat membuat permintaan ke Secure Web Proxy, Cloud DNS akan me-resolve permintaan nama host ke alamat IP resource Secure Web Proxy di jaringan VPC. Langkah ini tidak diperlukan untuk agen yang dihosting di Cloud Run dan GKE.

Setelan proxy agen

Cara standar untuk mengonfigurasi aplikasi agen agar menggunakan proxy HTTP(S) adalah dengan menyetel variabel lingkungan ini:

  • HTTP_PROXY: URL server proxy eksplisit untuk traffic HTTP (misalnya, http://swp.example.com:8888). Penyiapan ini menggunakan metode CONNECT HTTP dari klien ke proxy. Meskipun HTTP ditentukan, enkripsi TLS dipertahankan end-to-end melalui proxy dari runtime agen ke endpoint target.
  • HTTPS_PROXY: URL server proxy eksplisit untuk traffic HTTPS (misalnya, https://swp.example.com:8888). Seperti setelan HTTP_PROXY, setelan HTTPS_PROXY menggunakan TLS secara default. Namun, Anda dapat menyediakan lapisan enkripsi tambahan dengan mengaktifkan enkripsi TLS Anda sendiri di atas TLS default. Untuk mengetahui informasi selengkapnya, lihat Certificate Authority Service.
  • NO_PROXY: Daftar nama host atau alamat IP yang dipisahkan koma yang tidak boleh melalui proxy. Misalnya, jika Anda menambahkan metadata.google.internal dan 169.254.169.254 ke daftar NO_PROXY, maka beban kerja dapat langsung mengakses layanan metadata untuk autentikasi dan otorisasi ke API dan layanan Google.

Saat Anda menggunakan argumen env_vars untuk menyetel variabel selama deployment, variabel tersebut akan tersedia dalam lingkungan runtime agen (misalnya, saat Anda menggunakan os.environ di Python). Sebagian besar library klien HTTP standar secara otomatis menemukan dan menggunakan variabel lingkungan ini untuk merutekan traffic melalui proxy yang ditentukan. Pendekatan ini umum untuk aplikasi Python dan library klien HTTP seperti requests. Saat men-deploy agen, tentukan variabel lingkungan untuk menggunakan Secure Web Proxy untuk domain pribadi yang perlu dijangkau agen. Pastikan semua tujuan domain pribadi juga disertakan di Cloud DNS.

Contoh berikut menunjukkan deployment proxy Vertex AI Agent Engine dari objek agen:

## specify environment variables (dictionary)
env_vars = {
    "OTHER_VARIABLE": "OTHER_VALUE",
    "HTTP_PROXY": "http://swp.example.com:8888",
    "HTTPS_PROXY": "http://swp.example.com:8888",
    "NO_PROXY": "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"
}

remote_agent = aiplatform.agent_engines.create(
    agent=local_agent,
    config={
        "display_name": "Example agent using proxy",
        "env_vars": env_vars,
        ## ... other configs
    },
)

Cloud Run mendukung penetapan variabel lingkungan di tingkat revisi layanan. Pendekatan ini menggantikan variabel lingkungan dengan nama yang sama yang ditetapkan dalam image container. Pendekatan ini berguna untuk menetapkan parameter operasional seperti variabel proxy saat instance layanan dimulai.

Contoh berikut menunjukkan perintah untuk menyetel variabel lingkungan saat Anda men-deploy layanan Cloud Run:

gcloud run deploy SERVICE_NAME \
--image=IMAGE_URL \
--set-env-vars="HTTP_PROXY=http://swp.example.com:8888,HTTPS_PROXY=http://swp.example.com:8888,NO_PROXY=localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

Untuk menerapkan konfigurasi proxy eksplisit di pod GKE, tentukan resource ConfigMap yang menentukan variabel proxy:

apiVersion: v1
kind: ConfigMap
metadata:
  name: agent-proxy-config
  namespace: ai-apps
data:
  HTTP_PROXY: "http://swp.example.com:8888"
  HTTPS_PROXY: "http://swp.example.com:8888"

  NO_PROXY: "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

Untuk menerapkan kunci ConfigMap ke Pod, gunakan kolom envFrom dalam manifes penampung. Spesifikasi ini memasukkan variabel lingkungan ke dalam container saat runtime.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: subagent-app
spec:
  template:
    spec:
      containers:
      -   name: my-container
        image: my-agent-app:latest
        envFrom:
        -   configMapRef:
            name: agent-proxy-config

CA Service

CA Service (CA Service) diperlukan saat Secure Web Proxy atau Cloud NGFW dikonfigurasi untuk pemeriksaan TLS. Jika pemeriksaan TLS diaktifkan dan tujuan beban kerja menggunakan TLS, Layanan CA akan membuat dan menandatangani sertifikat untuk tujuan tersebut. Saat traffic terenkripsi untuk tujuan sebenarnya tiba di Secure Web Proxy atau Cloud NGFW, traffic tersebut akan didekripsi, diperiksa, lalu kebijakan akan diterapkan. Jika kebijakan mengizinkan paket, layanan akan mengenkripsi ulang paket untuk tujuan akhir. Anda juga dapat menggunakan CA Service untuk menyediakan sertifikat ke layanan lain yang dikelola Google.

CA Service adalah layanan terkelola. Setelah Layanan CA dikonfigurasi, layanan ini akan menangani penandatanganan sertifikat leaf hingga sertifikat CA root berakhir. Sertifikat CA root harus diperbarui untuk memastikan sertifikat tersebut tidak kedaluwarsa.

CA Service mendukung kemampuan ini untuk memungkinkan pemeriksaan traffic dan pengelolaan sertifikat dalam skala besar dalam arsitektur AI multi-agen:

  • Pemeriksaan TLS: Penggunaan CA pribadi diperlukan untuk pemeriksaan TLS penuh. Untuk mendekripsi dan menganalisis payload HTTPS sepenuhnya, perangkat proxy perantara (Secure Web Proxy atau Cloud NGFW) perlu menghentikan sesi TLS dengan klien. Proxy harus memberikan sertifikat valid yang diterima klien sebagai tepercaya untuk domain yang diminta.

    Layanan CA dapat membuat dan menandatangani sertifikat peniruan identitas khusus situs secara dinamis untuk situs yang diminta. Jika sertifikat CA root pribadi telah diinstal di trust store klien, klien akan menerima sertifikat yang dibuat secara dinamis ini sebagai valid. Klien memercayai sertifikat yang dikirim oleh proxy, sehingga klien mengirimkan permintaan. Proxy mengakhiri sesi TLS, mendekripsi paket, memeriksa konten, dan kemudian menerapkan kebijakan.

  • Distribusi sertifikat: Resource klien internal seperti agen AI yang berjalan di Vertex AI Agent Engine, Cloud Run, atau GKE memerlukan sertifikat CA root pribadi yang ditambahkan ke trust store lokalnya. Dengan menyimpan kunci publik sertifikat CA root di Secret Manager, agen AI dapat menarik sertifikat saat startup dan menambahkannya ke trust store sistem mereka.

    Resource server internal seperti Load Balancer Aplikasi internal memerlukan sertifikat yang diterbitkan oleh CA pribadi untuk bertindak sebagai endpoint server yang tepercaya dan menghentikan sesi TLS klien. Load Balancer Aplikasi terintegrasi dengan konfigurasi penerbitan Certificate Manager untuk mengotomatiskan penandatanganan permintaan sertifikat oleh CA Service dan men-deploy-nya ke load balancer.

Untuk mengetahui informasi selengkapnya tentang operasi sertifikat, lihat referensi berikut:

Keamanan koneksi A2A

Agen root berkomunikasi dengan berbagai subagen dan server MCP yang di-deploy di berbagai platform hosting runtime. Setiap lingkungan memperkenalkan persyaratan jaringan dan keamanan unik yang harus diabstraksi oleh lapisan A2A atau MCP.

Diagram berikut menunjukkan komponen dan jalur koneksi yang mungkin didukung oleh panduan desain ini:

Pola konektivitas Agent2Agent (A2A) antara berbagai platform hosting, termasuk GKE, Cloud Run, dan Vertex AI Agent Engine, serta koneksi ke server MCP dan internet.

Diagram sebelumnya merangkum kemungkinan koneksi ini:

  • Pengguna berinteraksi dengan sistem agentik melalui aplikasi Gemini Enterprise.
  • Aplikasi Gemini Enterprise menggunakan infrastruktur Google untuk terhubung ke agen root yang berjalan di GKE, Cloud Run, atau Vertex AI Agent Engine.
  • Aplikasi Gemini Enterprise dan agen root menggunakan infrastruktur Google untuk terhubung ke Model Armor dan LLM Gemini di Vertex AI.
  • Agen root dapat menggunakan infrastruktur Google untuk terhubung ke subagen yang berjalan di Cloud Run atau Vertex AI Agent Engine.
  • Agen root dapat menggunakan alamat IP pribadi untuk terhubung ke subagen yang berjalan di Vertex AI Agent Engine, Cloud Run, dan GKE. Koneksi ini harus dirutekan melalui jaringan VPC.
  • Agen root dan subagen dapat terhubung ke server MCP yang berjalan di Cloud Run atau GKE. Agen yang terhubung ke server MCP dapat menggunakan infrastruktur Google atau jaringan VPC. Server MCP menyediakan akses ke alat yang dihosting di Google Cloud, di infrastruktur lokal, di cloud lain, atau di internet.
  • Layanan yang dihosting di internet dapat dijangkau langsung melalui Secure Web Proxy.

Bagian berikut menyediakan referensi untuk jalur data runtime dan kontrol keamanan yang diperlukan untuk interaksi A2A yang aman. Informasi ini berfungsi sebagai standar arsitektur untuk membuat konektivitas pribadi dan menerapkan pertahanan berlapis yang diperlukan untuk melindungi jalur data end-to-end antar-agen.

Agen sumber GKE

Tabel berikut menyediakan referensi untuk membantu Anda melindungi traffic saat GKE adalah agen sumber. Traffic ini melewati jaringan VPC yang menghosting cluster GKE.

Agen tujuan (jalur data) Kontrol keamanan
Vertex AI Agent Engine (internal)
Cloud Run (internal)
Cloud Run (Private Service Connect untuk Google API)
Akses Cloud Run (NEG serverless)
GKE
Internet melalui jaringan VPC

Agen sumber Vertex AI Agent Engine (internal)

Tabel berikut menyediakan referensi untuk membantu Anda melindungi traffic saat Vertex AI Agent Engine menjadi agen sumber dan traffic berjalan langsung melalui infrastruktur Google. Dalam jalur ini, tidak ada jaringan VPC yang terlibat.

Agen tujuan (jalur data) Kontrol keamanan
Vertex AI Agent Engine (internal)
Cloud Run (internal)

Agen sumber Vertex AI Agent Engine (antarmuka Private Service Connect)

Tabel berikut menyediakan referensi untuk membantu Anda melindungi traffic saat Vertex AI Agent Engine adalah agen sumber dan traffic menggunakan antarmuka Private Service Connect untuk melewati jaringan VPC.

Agen tujuan (jalur data) Kontrol keamanan
Cloud Run (Private Service Connect GoogleAPIs)
Akses Cloud Run (NEG serverless)
GKE
Internet melalui jaringan VPC

Agen sumber Cloud Run (internal)

Tabel berikut menyediakan referensi untuk membantu Anda melindungi traffic saat Cloud Run menjadi agen sumber dan traffic berjalan langsung melalui infrastruktur Google. Dalam jalur ini, tidak ada jaringan VPC yang terlibat.

Agen tujuan (jalur data) Kontrol keamanan
Vertex AI Agent Engine (internal)
Cloud Run (internal)

Agen sumber Cloud Run (Traffic keluar VPC langsung)

Tabel berikut menyediakan referensi untuk membantu Anda melindungi traffic saat Cloud Run menjadi agen sumber dan traffic menggunakan traffic keluar VPC Langsung untuk melewati jaringan VPC.

Agen tujuan (jalur data) Kontrol keamanan
Cloud Run (Private Service Connect untuk Google API)
Akses Cloud Run (NEG serverless)
GKE
Internet melalui jaringan VPC
Vertex AI Agent Engine Private Service Connect untuk Google API

Keamanan koneksi MCP

Daftar berikut menguraikan platform hosting dan kontrol pertahanan mendalam yang terlibat dalam mengamankan jalur data antara runtime agen dan server MCP. Untuk agen sumber di Vertex AI Agent Engine, di Cloud Run, atau di GKE, gunakan kontrol keamanan berikut bergantung pada server MCP tujuan:

  • Internet:
    • Kontrol Layanan VPC
    • Model Armor
    • Cloud NGFW
    • Secure Web Proxy
  • Google MCP:
    • Kontrol Layanan VPC
    • Model Armor

Langkah berikutnya

Kontributor

Penulis:

  • Deepak Michael | Networking Specialist Customer Engineer
  • Michael Larson | Customer Engineer, Networking Specialist
  • Victor Moreno | Product Manager, Cloud Networking

Kontributor lainnya: