Pola jaringan pribadi multi-agen di Google Cloud

Last reviewed 2026-11-09 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, sub-agen, dan alat. Desain jaringan menyediakan koneksi pribadi untuk agen yang dihosting di Agent Runtime di Gemini Enterprise Agent Platform, 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 eksposur traffic ini ke internet publik. Desain ini menggunakan infrastruktur jaringan Google Cloud , 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 masuk dan keluar dari jaringan VPC, desain ini menggunakan kombinasi endpoint Private Service Connect, antarmuka Private Service Connect, dan egress Direct VPC Cloud Run. Cloud Next Generation Firewall (Cloud NGFW) mengatur traffic yang melewati jaringan VPC. Lapisan keamanan tambahan menyediakan egress internet yang terkontrol menggunakan Secure Web Proxy dan menyediakan kebijakan akses layanan API menggunakan perimeter Kontrol Layanan VPC.

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

Pola desain multi-agen

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

  1. Aplikasi Gemini Enterprise yang berinteraksi dengan agen root kustom. Aplikasi Gemini Enterprise menghadirkan antarmuka pengguna terkelola dengan fungsi keamanan bawaan yang mengekspos fungsionalitas agen kustom. Agen root yang dibuat khusus didaftarkan ke Gemini Enterprise dan tersedia di aplikasi untuk pengguna akhir. Agen root kustom bertindak sebagai orchestrator alur kerja tingkat atas dan mendelegasikan tugas khusus ke subagen. Arsitektur ini menggunakan agen root kustom yang dihosting di Agent Runtime, Cloud Run, atau GKE.
  2. Agen utama yang berinteraksi dengan sub-agen dan alat. Inti dari alur kerja sistem AI dan logika bisnis berada di agen root dan di sub-agen khusus. Fleksibilitas dalam framework agen, runtime, dan platform hosting memungkinkan berbagai opsi untuk menghubungkan agen root ke sub-agen 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 umum 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 ke Gemini Enterprise dan dihosting di Agent Runtime, Cloud Run, atau GKE. Agen root ini berfungsi sebagai orchestrator yang mendelegasikan tugas ke subagen.
  • 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 lain.
  • Sub-agen: 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 serta berinteraksi dengan alat menggunakan spesifikasi MCP.

Pola desain multi-agen tingkat tinggi ini menyoroti komponen jaringan yang ada dalam sistem AI multi-agen. Alat ini dapat mendukung berbagai jenis pola pemilihan rute agen ke 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 Agent Runtime, Cloud Run, GKE, Gemini Enterprise, dan load balancer khusus aplikasi.

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

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

Saat Anda memusatkan deployment jaringan dan keamanan dalam project host, Anda membuat satu titik pengelolaan untuk komunikasi agen ke agen dan 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 Cross-Cloud Network dengan menggunakan spoke VPC Network Connectivity Center (NCC) untuk menambahkan jaringan VPC Bersama sebagai jaringan VPC workload. Implementasi ini memberi VPC Bersama keterjangkauan penuh 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 sub-agen, 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 hal berikut:

  • 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.
  • Front end load balancer internal dan resource Compute Engine.
  • Google API melalui Akses Google Pribadi atau melalui Private Service Connect.
  • Internet, yang dikontrol melalui Secure Web Proxy.
  • Tujuan hybrid dan lintas cloud menggunakan Cloud Interconnect, Cloud VPN, router appliance, atau SD-WAN.
  • Setiap tujuan endpoint yang dapat dijangkau melalui perutean IP jaringan VPC.
  • Agen, alat, dan layanan pendukung AI lainnya.

Untuk mengetahui informasi selengkapnya tentang VPC Bersama, lihat referensi berikut:

Jaringan Gemini Enterprise

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

Percakapan pengguna ke aplikasi Gemini Enterprise

Pengguna melakukan chat dengan aplikasi Gemini Enterprise menggunakan aplikasi berbasis browser yang mengirimkan permintaan ke Google 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 akan memetakan nama agen ke target tertentu, baik URI resource Agent Runtime 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 ke Gemini Enterprise, Anda dapat men-deploy agen tersebut di mana saja sebagai agen kustom. Agen kustom di Agent Runtime 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 Layanan Discovery Engine Gemini Enterprise Agent Platform. Jalur jaringan dan mekanisme otorisasi berbeda-beda berdasarkan platform hosting yang Anda gunakan:

  • Agen kustom di Agent Runtime: Agen layanan Discovery Engine Agent Platform menyertakan peran Identity and Access Management (IAM) Agent Platform yang diperlukan untuk memanggil resource Agent Runtime sebagai fitur bawaan. Sistem akan merutekan permintaan yang dibuat ke layanan Agent Platform API melalui jaringan Google sebagai panggilan API internal.
  • Agen kustom di Cloud Run: Aplikasi Gemini Enterprise menggunakan identitas agen layanan Discovery Engine Agent Platform untuk melakukan panggilan ke URL .run.app default yang terdaftar dari kartu agen, dengan melampirkan token ID OIDC agen layanan di header autentikasi X-Serverless-Authorization. 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 ingress Google Front End (GFE) untuk Cloud Run.

  • Agen kustom di GKE: Aplikasi Gemini Enterprise menggunakan identitas agen layanan Agent Platform 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 load balancer gke-l7-regional-external-managed 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 Pengguna Aplikasi Web yang diamankan IAP (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 GKE Ingress dari Gemini Enterprise, lihat bagian IAP dan Google Cloud Armor nanti dalam dokumen ini.

Jaringan pribadi untuk platform hosting agen

Setelah pengguna memulai permintaan ke aplikasi Gemini Enterprise, permintaan akan 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 Agent Runtime, 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 agentic Anda.

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

  • Agen kustom di Agent Runtime: Antarmuka Private Service Connect menghubungkan runtime Agent Runtime ke jaringan VPC. Anda membuat lampiran jaringan di subnet jaringan VPC Anda dan memberikan izin kepada Agent Runtime untuk melampirkannya. Traffic yang dikirim dari Agent Runtime 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: Egress VPC Langsung 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-nya. 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 egress GKE menggunakan alamat IP Pod sebagai alamat IP sumber. Jika Anda mengonfigurasi penyamaran, traffic egress GKE akan menggunakan alamat IP node sebagai alamat IP sumber. Semua traffic egress GKE dirutekan oleh jaringan VPC.

Bagian berikut memberikan panduan tambahan untuk mengelola permintaan ingress dan egress ke dalam dan ke luar jaringan VPC untuk setiap platform hosting agen. Pertimbangan jaringan berlaku untuk fungsi agen root dan sub-agen.

Jaringan Agent Runtime

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

Agent Runtime 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 lain, siapkan kedua koneksi sebelumnya.

Egress Agent Runtime ke jaringan VPC

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

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

Untuk men-deploy egress jaringan VPC Agent Runtime, lihat referensi berikut:

Untuk lebih mengamankan agen dan jaringan VPC untuk egress Runtime Agen, lihat bagian berikut nanti dalam dokumen ini:

Ingress Agent Runtime dari jaringan VPC

Permintaan ke agen yang berjalan di Agent Runtime dibuat menggunakan endpoint Agent Platform 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 harus me-resolve nama host endpoint Agent Platform 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 Agent Platform API. Jaringan VPC merutekan permintaan langsung melalui jaringan produksi Google.

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

Pertimbangan jaringan Agent Runtime tambahan

Egress Agent Runtime 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 egress Agent Runtime, 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, Agent Runtime memiliki akses ke internet secara default. Untuk melindungi dari pemindahan data yang tidak sah, nonaktifkan akses default dengan mengaktifkan Kontrol Layanan VPC.

Saat Agent Runtime di-deploy dengan antarmuka Private Service Connect, egress internet langsung dinonaktifkan, terlepas dari Kontrol Layanan VPC. Jika Anda memerlukan agen untuk mengakses tujuan yang biasanya tidak dapat dijangkau oleh Agent Runtime, 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 Proxy Web Aman.
  3. Konfigurasikan peering DNS untuk Agent Runtime guna mendukung resolusi kueri DNS agen ke alamat pribadi Secure Web Proxy di jaringan VPC.
  4. Saat Anda 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, konfigurasikan zona DNS pribadi untuk tujuan tersebut.

Setelah traffic dari egress Agent Runtime mencapai jaringan VPC, traffic tersebut dapat menjangkau tujuan jaringan apa pun yang dapat dirutekan oleh jaringan VPC. Untuk mengetahui informasi tentang cara membatasi cakupan tujuan jaringan egress yang tersedia untuk agen Agent Runtime, lihat bagian Cloud NGFW nanti dalam dokumen ini.

Cloud Run networking

Bagian ini menjelaskan jaringan pribadi untuk agen root dan sub-agen 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 lain, siapkan kedua koneksi sebelumnya.

Egress 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. Konfigurasikan 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 zona pribadi Cloud DNS dan nama host publik.

Untuk mengetahui informasi tentang cara mengamankan agen dan jaringan VPC lebih lanjut untuk egress 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 workload alat atau agen AI. Endpoint ini disajikan oleh titik entri GFE yang sama yang menyajikan layanan API *.googleapis.com. Cloud Run menggunakan jalur jaringan dasar yang sama yang memungkinkan konektivitas pribadi untuk Akses Google Pribadi dan Private Service Connect untuk Google API.

Pengguna pribadi di jaringan VPC yang membuat kueri ke agen atau alat perlu me-resolve 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 URL run.app menyelesaikan permintaan untuk layanan Cloud Run. Jaringan VPC merutekan permintaan langsung melalui jaringan produksi Google.

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

  • Jaringan VPC dari project layanan Cloud Run.
  • Jaringan VPC Bersama yang menghosting endpoint egress 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 yang berasal dari luar project layanan Cloud Run atau lingkungan VPC Bersama akan diperlakukan sebagai eksternal. Traffic tersebut mencakup traffic dari layanan Google Cloud lain seperti Agent Runtime 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 Google, termasuk layanan Cloud Run Anda, menggunakan alamat IP pribadi dalam jaringan VPC Anda.
  • Rutekan traffic melalui Load Balancer Aplikasi internal yang ditempatkan dalam jaringan VPC 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 per layanan dan berikan peran IAM Invoker Cloud Run (roles/run.invoker) kepada principal.

Untuk mengetahui informasi tentang cara mengonfigurasi kontrol ingress 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 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 agen dan alat 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. Kueue dapat berintegrasi erat dengan aplikasi Kubernetes lainnya dan arsitektur microservice 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. Agar aplikasi Gemini Enterprise dapat memanggil agen kustom yang dihosting di GKE, Anda harus mengekspos Gateway eksternal dengan aman menggunakan alamat IP publik dan nama DNS. Traffic mengalir dari egress Gemini Enterprise ke jaringan edge Google, tempat traffic mengambil rute yang dioptimalkan ke load balancer eksternal GKE.

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

Mode operasi GKE

GKE menawarkan mode operasi berikut 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 bertanggung jawab penuh atas konfigurasi node pool, seperti memilih jenis mesin, mengelola OS image, dan penskalaan manual.
Hardening infrastruktur dan bidang kontrol
  • Cluster GKE pribadi: Menyediakan node tanpa alamat IP publik, yang memastikan lingkungan runtime terisolasi dari eksposur internet langsung.
  • Jaringan yang diizinkan master: Membatasi akses administratif ke Kubernetes API ke rentang alamat IP tertentu yang tepercaya, sehingga memperkuat bidang kontrol terhadap perubahan konfigurasi yang tidak sah. Amankan Endpoint DNS untuk Kubernetes API menggunakan IAM dan Kontrol Layanan VPC Google Cloud.
Identitas dan akses (zero trust)
  • IAP: Bertindak sebagai penjaga gerbang 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 setiap pengguna dan konteks perangkat mereka.
Perlindungan edge dan pengelolaan traffic
  • Cloud Armor: Memberikan keamanan edge yang tangguh, termasuk aturan Firewall Aplikasi Web (WAF) untuk membantu memblokir payload berbahaya, perlindungan DDoS untuk membantu memastikan waktu beroperasi, dan pembatasan kapasitas untuk membantu mencegah kehabisan 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 terperinci dengan hak istimewa terendah 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 menyediakan 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 lain yang terhubung.

Jika Pod agen berkomunikasi dengan Pod subagen di node yang sama, 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 agen dapat menjangkau tujuan menggunakan perutean VPC standar yang sama, sesuai dengan aturan firewall.

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

Traffic masuk GKE dari jaringan VPC

Service Kubernetes menyediakan akses ke resource GKE. Untuk sistem AI multi-agen, sebaiknya gunakan GKE Gateway atau GKE Inference Gateway. Gateway menyediakan 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 dihubungkan untuk menyediakan load balancing langsung ke container. Untuk mengekspos layanan secara internal untuk traffic yang bersumber 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 pemindaian WAF, pemfilteran berbasis alamat IP dan geografis, perlindungan DDoS, dan pembatasan kapasitas 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 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 menggunakan produk dan layanan berikut:

Untuk mengetahui informasi selengkapnya tentang cara 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 platform API. Dataplane jaringan VPC membahas cara agen dan alat terhubung dengan aman. Platform API menentukan identitas dan jenis pertukaran data yang diizinkan. Melapisi kontrol akses di seluruh jaringan VPC dan platform 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 diotorisasi yang dapat menjangkau endpoint agen dengan memverifikasi setiap koneksi masuk atau keluar ke dan dari agen dan alat lain.

Cloud NGFW adalah layanan firewall terdistribusi yang di-build ke dalam fabric jaringan VPC. Cloud Load Balancing menawarkan tingkat fitur berikut 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: Memberikan penegakan berbasis IP dengan objek Fully Qualified Domain Name (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 serta sistem deteksi dan pencegahan penyusupan (IDPS) untuk menganalisis payload terhadap signature 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.

  • Agent Runtime: Agen yang berjalan di Agent Runtime 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 ini 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 mengirimkan 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 alamat IP tujuan.
  • GKE: Cluster GKE VPC native memberi Pod alamat IP yang langsung berasal dari rentang alamat IP sekunder jaringan VPC. Kebijakan firewall jaringan dapat memfilter traffic berdasarkan rentang alamat IP untuk node dan Pod GKE, dan kebijakan tersebut dapat menggunakan tag aman dan akun layanan. Tag aman terikat ke instance VM yang bertindak sebagai node GKE. Aturan firewall kemudian dapat menargetkan atau mengambil traffic dari node yang memiliki tag tertentu. Aturan firewall juga dapat menargetkan atau mengambil sumber traffic dari node GKE berdasarkan identitas akun layanan yang terkait dengan node pool.

Kebijakan tolak egress default

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

Aturan kebijakan firewall dapat secara efektif mencocokkan traffic sumber dari subnet network attachment Agent Runtime dan dari subnet Direct VPC egress Cloud Run.

Berikut adalah contoh kebijakan egress tolak default:

  • Membuat kebijakan dan aturan firewall jaringan: Buat kebijakan firewall global atau regional dan kaitkan dengan jaringan VPC. Buat aturan kebijakan firewall yang menargetkan traffic ke arah egress (--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 ALLOW tertentu: Gunakan nomor prioritas yang lebih rendah, misalnya 100-1000. Aturan ini secara tepat mengizinkan traffic jaringan yang diperlukan agar agen AI Anda berfungsi. Traffic ini mencakup komunikasi ke layanan internal lainnya, load balancer, Google API yang diperlukan, atau endpoint eksternal yang sah. Buat aturan yang mencocokkan traffic sumber dari subnet network attachment Agent Runtime atau dari subnet Direct VPC egress Cloud Run ke tujuan yang Anda inginkan.
  • Aturan DENY umum: Untuk memastikan bahwa aturan berada di urutan 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 tolak egress default mencegah agen AI membuat koneksi jaringan apa pun yang tidak diizinkan secara eksplisit dan memblokir potensi pemindahan data atau akses ke situs berbahaya. Kebijakan ini membatasi agen yang dihosting untuk 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 di semua paket Cloud NGFW, Anda dapat lebih memperkuat keamanan jaringan AI multi-agen dengan menggunakan fitur paket 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 mungkin 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 mereka 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 egress untuk otomatis memblokir agen agar tidak terhubung ke tujuan berbahaya yang diketahui, seperti server perintah dan kontrol (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 Lapisan 7: Untuk agen yang menangani data sensitif atau yang terpapar risiko 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 pemeriksaan TLS sangat penting karena sebagian besar serangan modern dan komunikasi C2 dienkripsi.

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

IAP

IAP mengamankan permintaan ingress ke cluster GKE dengan menyediakan lapisan autentikasi dan otorisasi pusat untuk aplikasi AI. IAP menangkap semua permintaan HTTPS yang ditujukan untuk Gateway, dan memeriksa identitas serta izin pemanggil. IAP hanya mengizinkan permintaan yang diautentikasi dan diotorisasi untuk diteruskan ke workload 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 Pengguna Aplikasi Web yang diamankan IAP (roles/iap.httpsResourceAccessor) pada resource layanan backend yang dilindungi IAP. Sebaiknya konfigurasikan akun layanan kustom sebagai identitas untuk agen yang di-deploy. Dengan menggunakan akun layanan kustom, Anda dapat menetapkan izin secara lebih tepat sesuai dengan prinsip hak istimewa terendah.

Hanya berikan peran IAM IAP-secured aplikasi web User secara langsung ke akun layanan agen yang diizinkan untuk mengakses agen dan alat lain yang dihosting di layanan GKE yang ditargetkan oleh resource kustom GCPBackendPolicy (atau BackendConfig untuk Ingress). Untuk mengizinkan akses aplikasi Gemini Enterprise, berikan izin dengan mengikat peran IAM Discovery Engine Service Account (roles/discoveryengine.serviceAgent) untuk project Gemini Enterprise Anda.

Kontrol Layanan VPC

Kontrol Layanan VPC memitigasi 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 kuat terhadap pemindahan yang tidak sah. Untuk memastikan penegakan 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:

  • Men-deploy satu perimeter Kontrol Layanan VPC yang mencakup project Gemini Enterprise dan Cloud Run.
  • Tambahkan semua layanan Kontrol Layanan VPC yang didukung 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 Authorization (atau header X-Serverless-Authorization saat Gemini Enterprise memanggil URL .run.app default). 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 menetapkan ingress Cloud Run ke Internal. Tanpa perimeter ini, panggilan lintas project dari Gemini Enterprise akan diperlakukan sebagai traffic eksternal, sehingga Anda harus menyetel traffic masuk Cloud Run ke All—yang membuat layanan terekspos ke internet publik.

  • all traffic masuk Cloud Run didukung jika keduanya true:
    • 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 Kontrol Layanan VPC tambahan

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

  • Membatasi setelan traffic masuk yang diizinkan: Cegah developer men-deploy endpoint yang dapat diakses publik secara tidak sengaja dengan menetapkan batasan kebijakan organisasi run.allowedIngress. Batasan ini hanya berlaku untuk deployment baru. Deployment 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 hanya mengizinkan permintaan internal, tetapkan nilai ke internal.
    • Untuk mengizinkan permintaan melalui Load Balancer Aplikasi eksternal, tetapkan nilainya 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 mengharuskan setiap revisi Cloud Run menggunakan egress VPC Langsung atau konektor Akses VPC Serverless. Batasan ini hanya berlaku untuk deployment baru. Deployment 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 container dan layanan di lokasi yang sama: Repositori Artifact Registry yang berisi image container Anda harus berada dalam perimeter yang sama dengan layanan Cloud Run. Penarikan image lintas perimeter akan otomatis diblokir kecuali jika Anda menetapkan aturan ingress dan egress yang eksplisit.
  • Mengelola tingkat akses: Aturan kebijakan ingress dan tingkat akses Kontrol Layanan VPC yang mengandalkan identitas akun utama 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 lebih baik 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 memberikan titik kontrol untuk menerapkan standar AI yang bertanggung jawab. Sebaiknya gunakan 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 Agent Runtime, buat peering DNS dari Agent Runtime ke zona pribadi Cloud DNS yang terkait dengan jaringan VPC Anda. Saat agen membuat permintaan ke Model Armor, Cloud DNS melakukan resolusi DNS 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 antarlayanan bervolume tinggi yang menggunakan panggilan A2A, MCP, dan API. Perlindungan Cloud Armor memberikan lapisan ketahanan tambahan dalam desain keamanan dengan pembatasan kapasitas, penyaringan WAF, dan aturan kustom yang sesuai dengan permintaan agen yang diharapkan. Dengan melampirkan kebijakan keamanan Cloud Armor ke layanan backend Load Balancer Aplikasi, traffic dapat difilter untuk permintaan berbahaya dan diatur dengan pembatasan kapasitas, 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 menggunakan Load Balancer Aplikasi internal dengan backend NEG serverless. Terapkan kebijakan keamanan backend ke NEG serverless untuk menerapkan aturan WAF untuk 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 zona. 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, alamat IP dan kontrol berbasis 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. Secure Web Proxy bertindak sebagai proxy terpusat dan titik penerapan keamanan untuk memberikan kontrol dan visibilitas terperinci untuk traffic internet keluar. Layanan ini juga bertindak 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 next hop. 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 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 khusus dengan resource proxy. Konfigurasi ini mewajibkan setiap permintaan keluar harus melewati Secure Web Proxy sebelum keluar ke internet.

Penggunaan Secure Web Proxy sebagai proxy eksplisit mendukung permintaan agen yang berasal dari antarmuka Private Service Connect Agent Runtime, egress VPC Langsung Cloud Run, dan cluster GKE native VPC. Saat agen mengirim permintaan ke Secure Web Proxy menggunakan metode CONNECT HTTP, traffic sesi TCP 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.

Pemilihan rute proxy eksplisit

Egress Runtime Agen 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 Agent Runtime, sebaiknya konfigurasikan 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 Agent Runtime. Kemudian, proxy ini dapat mem-proxy 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 pemilihan rute eksplisit, konfigurasikan 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 Agent Runtime, buat peering DNS dari Agent Runtime ke zona pribadi Cloud DNS yang terkait dengan jaringan VPC Anda. Saat agen membuat permintaan ke Secure Web Proxy, Cloud DNS melakukan resolusi DNS 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 menetapkan variabel lingkungan berikut:

  • 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 secara menyeluruh 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 memberikan 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 melewati proxy. Misalnya, jika Anda menambahkan metadata.google.internal dan 169.254.169.254 ke daftar NO_PROXY, workload dapat langsung mengakses layanan metadata untuk autentikasi dan otorisasi ke Google API dan layanan Google.

Saat Anda menggunakan argumen env_vars untuk menetapkan 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 digunakan untuk aplikasi Python dan library klien HTTP seperti requests. Saat men-deploy agen, tentukan variabel lingkungan untuk menggunakan Secure Web Proxy untuk domain pribadi apa pun yang perlu dijangkau agen. Pastikan semua tujuan domain pribadi juga disertakan dalam Cloud DNS.

Contoh berikut menunjukkan deployment proxy Agent Runtime dari objek agen:

import agentplatform

client = agentplatform.Client(
    project="PROJECT_ID",
    location="LOCATION",
)

## 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 = client.runtimes.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 mengganti variabel lingkungan apa pun 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 menetapkan 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 container. 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 diperlukan saat Secure Web Proxy atau Cloud NGFW dikonfigurasi untuk pemeriksaan TLS. Saat pemeriksaan TLS diaktifkan dan tujuan workload menggunakan TLS, CA Service 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 mendekripsi paket, memeriksanya, lalu menerapkan kebijakan. Jika kebijakan mengizinkan paket, layanan akan mengenkripsi ulang paket untuk tujuan akhir. Anda juga dapat menggunakan CA Service untuk memberikan sertifikat ke layanan terkelola Google lainnya.

CA Service adalah layanan terkelola. Setelah dikonfigurasi, CA Service akan menangani penandatanganan sertifikat entitas akhir hingga masa berlaku Sertifikat CA root berakhir. Sertifikat root CA harus diperbarui untuk memastikan bahwa sertifikat tersebut tidak habis masa berlakunya.

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 lengkap. Untuk mendekripsi dan menganalisis payload HTTPS sepenuhnya, perangkat proxy perantara (Secure Web Proxy atau Cloud NGFW) harus menghentikan sesi TLS dengan klien. Proxy harus memberikan sertifikat valid yang diterima klien sebagai tepercaya untuk domain yang diminta.

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

  • Distribusi sertifikat: Resource klien internal seperti agen AI yang berjalan di Agent Runtime, Cloud Run, atau GKE memerlukan sertifikat root CA pribadi yang ditambahkan ke trust store lokal mereka. Dengan menyimpan kunci publik sertifikat root CA di Secret Manager, agen AI dapat mengambil sertifikat saat memulai 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 tepercaya dan menghentikan sesi TLS klien. Load Balancer Aplikasi terintegrasi dengan konfigurasi penerbitan Certificate Manager untuk mengotomatiskan CA Service yang menandatangani permintaan sertifikat dan men-deploy-nya ke load balancer.

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

Keamanan koneksi A2A

Agen root berkomunikasi dengan beragam 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 kemungkinan jalur koneksi yang didukung oleh panduan desain ini:

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

Diagram sebelumnya merangkum kemungkinan koneksi ini:

  • Pengguna berinteraksi dengan sistem agentic melalui aplikasi Gemini Enterprise.
  • Aplikasi Gemini Enterprise menggunakan infrastruktur Google untuk terhubung ke agen root yang berjalan di GKE, Cloud Run, atau Agent Runtime.
  • Aplikasi Gemini Enterprise dan agen root menggunakan infrastruktur Google untuk terhubung ke Model Armor dan LLM Gemini di Agent Platform.
  • Agen root dapat menggunakan infrastruktur Google untuk terhubung ke sub-agen yang berjalan di Cloud Run atau Agent Runtime.
  • Agen root dapat menggunakan alamat IP pribadi untuk terhubung ke sub-agen yang berjalan di Agent Runtime, Cloud Run, dan GKE. Koneksi ini harus dirutekan melalui jaringan VPC.
  • Agen root dan sub-agen 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 membangun 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
Agent Runtime (internal)
Cloud Run (internal)
Cloud Run (Private Service Connect untuk Google API)
Akses Cloud Run (NEG serverless)
GKE
Internet melalui jaringan VPC

Agen sumber Agent Runtime (internal)

Tabel berikut menyediakan referensi untuk membantu Anda melindungi traffic saat Agent Runtime adalah agen sumber dan traffic berpindah langsung melalui infrastruktur Google. Dalam jalur ini, tidak ada jaringan VPC yang terlibat.

Agen tujuan (jalur data) Kontrol keamanan
Agent Runtime (internal)
Cloud Run (internal)

Agen sumber Agent Runtime (antarmuka Private Service Connect)

Tabel berikut menyediakan referensi untuk membantu Anda melindungi traffic saat Agent Runtime adalah agen sumber dan traffic menggunakan antarmuka Private Service Connect untuk melakukan perjalanan melalui 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

Agen sumber Cloud Run (internal)

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

Agen tujuan (jalur data) Kontrol keamanan
Agent Runtime (internal)
Cloud Run (internal)

Agen sumber Cloud Run (Direct VPC egress)

Tabel berikut menyediakan resource untuk membantu Anda melindungi traffic saat Cloud Run adalah agen sumber dan traffic menggunakan traffic keluar VPC Langsung untuk melakukan perjalanan melalui 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
Agent Runtime (Private Service Connect untuk Google API)

Keamanan koneksi MCP

Daftar berikut menguraikan platform hosting dan kontrol defense in depth yang terlibat dalam mengamankan jalur data antara runtime agen dan server MCP. Untuk agen sumber di Agent Runtime, 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: