Google Cloud의 다중 에이전트 비공개 네트워킹 패턴

Last reviewed 2026-04-16 UTC

이 문서에서는 에이전트, 하위 에이전트, 도구 간의 비공개 연결을 통해 공개적으로 액세스할 수 있는 다중 에이전트 Gemini Enterprise 앱을 지원하는 비공개 네트워킹 인프라를 설계하는 데 도움이 되는 안내를 제공합니다. 네트워크 설계는 Vertex AI Agent Engine, Cloud Run, Google Kubernetes Engine (GKE), 온프레미스 데이터 센터 또는 기타 클라우드에서 호스팅되는 에이전트에 비공개 연결을 제공합니다. 또한 이 설계는 인터넷 위치에서 실행되는 에이전트에 대한 연결을 지원합니다.

멀티 에이전트 AI 시스템에는 조직적으로 민감하거나 독점적인 데이터가 포함되는 경우가 많습니다. 비공개 네트워킹을 사용하면 이 트래픽이 공개 인터넷에 노출되지 않습니다. 이 설계에서는 Google Cloud 네트워크 인프라, 가상 프라이빗 클라우드 (VPC) 네트워크 리소스, 온프레미스 환경 또는 크로스 클라우드 네트워크에 대한 비공개 연결을 사용합니다.

이 문서에서 설명하는 설계에서 에이전트는 Agent2Agent (A2A) 프로토콜과 모델 컨텍스트 프로토콜 (MCP)을 사용하여 다른 에이전트 및 도구와 통신합니다. 통신은 VPC 네트워크를 통해 라우팅되어 비공개로 설정됩니다. VPC 네트워크로 트래픽을 이동하거나 VPC 네트워크에서 트래픽을 이동하기 위해 이 설계에서는 Private Service Connect 엔드포인트, Private Service Connect 인터페이스, Cloud Run 직접 VPC 이그레스의 조합을 사용합니다. Cloud Next Generation Firewall (Cloud NGFW)은 VPC 네트워크를 통과하는 트래픽을 관리합니다. 추가 보안 레이어는 Secure Web Proxy를 사용하여 제어된 인터넷 이그레스를 제공하고 VPC 서비스 제어 경계를 사용하여 API 서비스 액세스 정책을 제공합니다.

이 문서의 주요 대상에는 클라우드 AI 인프라와 앱을 빌드하고 관리하는 설계자, 개발자, 관리자가 포함됩니다. 이 문서에서는 사용자가 AI 에이전트 및 모델에 대한 기본적인 이해가 있고 Google Cloud 네트워킹 개념에 익숙하다고 가정합니다.

멀티 에이전트 설계 패턴

멀티 에이전트 Gemini Enterprise 앱에는 도구 및 하위 에이전트 연결을 위한 오케스트레이터 또는 루트 에이전트 역할을 하는 맞춤 에이전트가 필요합니다. Google Cloud 또는 온프레미스에서 호스팅되는 도구 및 하위 에이전트에 대한 비공개 연결을 구현하기 위해 설계에서는 비공개 IP 주소가 있는 VPC 네트워크를 사용합니다. 루트 에이전트는 Agent Engine, Cloud Run 또는 GKE를 사용하여 Google 인프라 내에서 호스팅됩니다. 멀티 에이전트 설계 패턴은 다음과 같은 상호작용을 강조합니다.

  1. 맞춤 루트 에이전트와 상호작용하는 Gemini Enterprise 앱 Gemini Enterprise 앱은 맞춤 에이전트 기능을 노출하는 기본 제공 보안 기능이 있는 관리 사용자 인터페이스를 제공합니다. 맞춤 빌드 루트 에이전트는 Gemini Enterprise에 등록되며 최종 사용자가 앱에서 사용할 수 있습니다. 맞춤 루트 에이전트는 최상위 워크플로 오케스트레이터 역할을 하며 전문 작업을 하위 에이전트에게 위임합니다. 이 아키텍처는 Vertex AI Agent Engine, Cloud Run 또는 GKE에서 호스팅되는 맞춤 루트 에이전트를 사용합니다.
  2. 하위 에이전트 및 도구와 상호작용하는 루트 에이전트 AI 시스템 워크플로와 비즈니스 로직의 핵심은 루트 에이전트와 전문 하위 에이전트에 있습니다. 에이전트 프레임워크, 런타임, 호스팅 플랫폼의 유연성 덕분에 VPC 네트워크를 통해 루트 에이전트를 하위 에이전트 및 도구에 연결하는 다양한 옵션을 사용할 수 있습니다. 아키텍처의 이 부분에 VPC 네트워킹을 사용하면 에이전트가 다른 비공개 엔드포인트, 엔터프라이즈 보안 제어, 광범위한 네트워크 도달 가능성을 노출하는 사용자가 정의한 비공개 네트워킹 경로를 사용할 수 있습니다.

다중 에이전트 네트워킹 아키텍처에 대한 대략적인 개요

아키텍처에는 다음 구성요소가 포함됩니다.

  • Gemini Enterprise 앱: 사용자가 인앱 채팅 인터페이스에 액세스하고 멀티 에이전트 AI 시스템과 상호작용할 수 있는 프런트엔드입니다. 사용자는 공개 인터넷을 통해 또는 하이브리드 연결을 통해 비공개로 Gemini Enterprise 앱에 액세스할 수 있습니다.
  • 커스텀 에이전트: Gemini Enterprise로 빌드 및 등록되고 Vertex AI Agent Engine, Cloud Run 또는 GKE에서 호스팅되는 루트 에이전트입니다. 이러한 루트 에이전트는 하위 에이전트에게 작업을 위임하는 오케스트레이터 역할을 합니다.
  • VPC 네트워크: 에이전트에 비공개 엔드포인트에 대한 IP 네트워크 연결과 더 넓은 네트워크 도달 범위를 제공하기 위해 제어하는 리소스입니다. VPC 네트워크는 다른 에이전트 및 도구에 대한 에이전트 요청에 대해 비공개 연결 및 네트워크 보안 제어를 구현하는 플랫폼을 제공합니다.
  • 하위 에이전트: 루트 에이전트 워크플로에 의해 트리거되는 전문 에이전트입니다. 하위 에이전트는 프로그래밍 언어와 런타임에 관계없이 에이전트 간 상호 운용성을 지원하는 A2A 프로토콜을 사용하여 통신합니다.
  • 도구: API, 데이터 소스, 워크플로 함수와 같은 서비스를 노출하는 원격 시스템입니다. 이러한 도구는 데이터를 가져오고 상담사를 위해 작업이나 거래를 실행합니다. 도구는 에이전트 외부에 있으며 에이전트는 MCP 사양을 사용하여 도구와 연결하고 상호작용합니다.

이 상위 수준 멀티 에이전트 설계 패턴은 멀티 에이전트 AI 시스템에 있는 네트워킹 구성요소를 강조합니다. 다양한 유형의 에이전트 간 라우팅 패턴을 지원할 수 있습니다. 다른 AI 시스템 설계 패턴에 대한 자세한 내용은 에이전트 AI 시스템의 설계 패턴 선택을 참고하세요.

공유 VPC

다중 에이전트 설계 패턴은 공유 VPC를 사용하여 네트워킹 및 보안 권한과 책임을 중앙 집중화합니다. 이 설계는 개발자에게 조직의 보안 요구사항을 충족하는 데 도움이 되는 환경을 제공합니다. 공유 VPC를 사용하여 네트워크 및 보안 구성을 중앙 집중화하여 간소화하는 것이 좋습니다.

공유 VPC 아키텍처에서 호스트 프로젝트에는 VPC 네트워크, Cloud Router, 서브넷, 방화벽, Cloud DNS를 비롯한 공유 네트워크 리소스가 포함됩니다. 관리자는 이러한 리소스를 사용할 수 있는 액세스 권한을 서비스 프로젝트에 부여할 수 있습니다. 서비스 프로젝트에는 Vertex AI Agent Engine, Cloud Run, GKE, Gemini Enterprise, 앱별 부하 분산기 등 에이전트 런타임 리소스가 포함됩니다.

공유 VPC는 네트워크 및 보안 관리자 페르소나와 AI 앱 개발자 페르소나 간의 명확한 경계를 적용합니다.

  • 네트워크 및 보안 관리자는 VPC 라우팅, 서브넷, DNS 피어링, 방화벽 정책과 같은 핵심 인프라를 제어합니다.
  • AI 앱 개발자는 기본 네트워크 인프라를 수정할 권한이 없어도 연결된 서비스 프로젝트에서 에이전트를 빌드합니다.

호스트 프로젝트 내에서 네트워크 및 보안 배포를 중앙 집중화하면 에이전트 간 통신 및 에이전트-서비스 통신을 위한 단일 관리 지점이 생성됩니다. 이 설계는 일관된 연결을 보장하면서 다양한 서비스 프로젝트 전반에서 보안 정책의 시행을 간소화합니다.

Network Connectivity Center (NCC) VPC 스포크를 사용하여 공유 VPC 네트워크를 워크로드 VPC 네트워크로 추가하면 공유 VPC 네트워크를 크로스 클라우드 네트워크에 통합할 수 있습니다. 이 구현은 NCC 허브 경로에 대한 완전한 연결 가능성과 다른 스포크의 서비스 액세스 포인트에 대한 연결을 공유 VPC에 제공합니다.

맞춤 루트 에이전트에서 시작된 요청은 비공개 고객 관리 VPC 네트워크를 사용하여 하위 에이전트, 도구, 서비스에 대한 보안 네트워크 경로를 제공합니다. VPC 네트워크 라우팅은 비공개 엔드포인트에 대한 연결 가능 여부를 관리합니다. VPC 네트워크에 적용되는 Cloud NGFW 정책은 네트워크 액세스를 관리합니다.

에이전트는 다음과의 연결을 비롯한 비공개 VPC 네트워크 경로에 안전하게 액세스할 수 있습니다.

  • VPC 네트워크 피어링, 다중 NIC 어플라이언스 또는 NCC를 통한 기타 VPC 네트워크
  • 프로듀서 서비스에 액세스하기 위한 Private Service Connect 엔드포인트입니다.
  • 비공개 IP 주소가 있는 관리형 서비스(예: Cloud SQL)
  • 내부 부하 분산기 프런트엔드 및 Compute Engine 리소스
  • 비공개 Google 액세스 또는 Private Service Connect를 통한 Google API
  • Secure Web Proxy를 통해 제어되는 인터넷
  • Cloud Interconnect, Cloud VPN, 라우터 어플라이언스 또는 SD-WAN을 사용하는 하이브리드 및 크로스 클라우드 대상
  • VPC 네트워크 IP 라우팅을 통해 연결할 수 있는 엔드포인트 대상
  • 기타 AI 에이전트, 도구, 지원 서비스

공유 VPC에 대한 자세한 내용은 다음 리소스를 참고하세요.

Gemini Enterprise 네트워킹

Gemini Enterprise 앱은 VPC 네트워크 외부이지만 Google 네트워크 내의 호스팅 환경에서 작동하는 관리 리소스입니다. 다음 섹션에서는 사용자와 Gemini Enterprise 앱 간의 네트워킹 구성과 앱과 에이전트 간의 네트워킹을 설명합니다.

사용자가 Gemini Enterprise 앱과 채팅

사용자는 Google API 및 서비스에 요청을 전송하는 브라우저 기반 앱을 사용하여 Gemini Enterprise 앱과 채팅합니다. 비공개 사용자 연결을 사용 설정하려면 VPC 네트워크를 통해 라우팅되는 비공개 IP 주소 범위로 확인되도록 Google API URL을 구성하면 됩니다. 자세한 내용은 비공개 UI 액세스 구성을 참고하세요.

Gemini Enterprise 앱을 커스텀 에이전트에 연결

Gemini Enterprise 검색 서비스에 커스텀 에이전트를 등록합니다. 에이전트를 등록하면 Gemini Enterprise가 에이전트 이름을 특정 타겟( Vertex AI Agent Engine 리소스 URI 또는 A2A 에이전트 URL)에 매핑합니다. Gemini Enterprise 앱에는 어시스턴트라는 채팅 인터페이스가 내장되어 있습니다. 사용자가 @agent_name를 사용하여 에이전트를 지정하거나 어시스턴트가 위임하기로 결정하면 앱은 레지스트리에서 에이전트를 조회하여 연결된 엔드포인트를 찾습니다.

루트 에이전트를 Gemini Enterprise에 등록하면 해당 에이전트를 어디에나 커스텀 에이전트로 배포할 수 있습니다. Vertex AI Agent Engine 및 Cloud Run의 맞춤 에이전트는 추가 네트워킹 리소스를 구성하지 않고 기존 비공개 네트워크 경로를 사용할 수 있습니다. GKE에 커스텀 에이전트를 배포하려면 외부 게이트웨이를 사용하여 서비스를 노출해야 합니다. 외부 게이트웨이를 더 안전하게 구성하는 방법에 관한 자세한 내용은 이 문서 뒷부분의 GKE 네트워킹을 참고하세요.

커스텀 에이전트에 요청을 전송하기 위해 Gemini Enterprise는 Vertex AI Discovery Engine 서비스 계정 ID를 사용합니다. 네트워크 경로와 승인 메커니즘은 사용하는 호스팅 플랫폼에 따라 다릅니다.

  • Vertex AI Agent Engine의 맞춤 에이전트: Vertex AI Discovery Engine 서비스 에이전트에는 Vertex AI Agent Engine 리소스를 내장 기능으로 호출하는 데 필요한 Vertex AI Identity and Access Management (IAM) 역할이 포함되어 있습니다. 시스템은 Google 네트워크를 통해 Vertex AI API 서비스에 이루어진 요청을 내부 API 호출로 라우팅합니다.
  • Cloud Run의 커스텀 에이전트: Gemini Enterprise 앱은 Vertex AI Discovery Engine 서비스 에이전트 ID를 사용하여 에이전트 카드에서 등록된 안정적인 run.app URL을 호출합니다. AI 에이전트 Cloud Run 서비스가 이러한 호출을 승인하려면 Discovery Engine 서비스 에이전트에 Cloud Run 호출자 IAM 역할 (roles/run.invoker)을 부여해야 합니다. Cloud Run에 대한 요청은 Google 프로덕션 네트워크를 통해 Cloud Run용 Google 프런트엔드 (GFE) 인그레스로 라우팅됩니다.

  • GKE의 맞춤 에이전트: Gemini Enterprise 앱은 Vertex AI Discovery Engine 서비스 에이전트 ID를 사용하여 에이전트 카드에서 등록된 URL을 호출합니다. 공개 DNS는 호스트 이름을 게이트웨이에서 관리하는 외부 IP 주소로 확인할 수 있어야 합니다. gke-l7-regional-external-managed 부하 분산기 또는 gke-l7-global-external-managed 부하 분산기를 사용하는 것이 좋습니다. 보안을 강화하려면 Gemini Enterprise가 Identity-Aware Proxy (IAP)를 사용하여 GKE 호스팅 A2A 에이전트를 호출하는 것이 좋습니다. IAP가 이러한 호출을 승인하려면 Discovery Engine 서비스 에이전트에 IAP 보안 웹 앱 사용자 IAM 역할(roles/iap.httpsResourceAccessor)을 부여해야 합니다. Google 프로덕션 네트워크는 외부 애플리케이션 부하 분산기 인그레스의 GFE에 GKE로 요청을 라우팅합니다.

    Gemini Enterprise에서 GKE 인그레스를 보호하려면 이 문서 뒷부분의 IAP 및 Google Cloud Armor 섹션을 참고하세요.

에이전트 호스팅 플랫폼을 위한 비공개 네트워킹

사용자가 Gemini Enterprise 앱에 요청을 시작하면 맞춤 루트 에이전트에서 하위 에이전트와 도구로 요청이 시작됩니다. 맞춤 에이전트 호스팅 플랫폼은 Gemini Enterprise와 VPC 네트워크 간의 인터페이스를 제공합니다. 컨테이너화된 에이전트 및 도구의 호스팅 플랫폼은 Vertex AI Agent Engine, Cloud Run, GKE입니다.

에이전트 호스팅 플랫폼을 선택할 때는 각 플랫폼의 비공개 네트워킹 패턴, 보안 제어, 관리 제어, 맞춤설정 수준, 보안 규정 준수를 고려해야 합니다. AI 에이전트 호스팅 플랫폼을 선택하는 방법에 대한 자세한 내용은 생성형 AI 애플리케이션을 위한 모델 및 인프라 선택 및 에이전트 AI 아키텍처 구성요소 선택을 참고하세요.

사용하는 에이전트 호스팅 플랫폼에 따라 다양한 메커니즘을 통해 비공개 VPC 연결을 설정합니다.

  • Vertex AI Agent Engine의 커스텀 에이전트: Private Service Connect 인터페이스는 Vertex AI Agent Engine 런타임을 VPC 네트워크에 연결합니다. VPC 네트워크의 서브넷에서 네트워크 연결을 만들고 Vertex AI Agent Engine에 연결 권한을 부여합니다. Vertex AI Agent Engine에서 전송된 트래픽은 연결의 서브넷 IP 주소에서 시작된 것처럼 VPC 네트워크에 표시됩니다. 그러면 VPC 네트워크에서 트래픽을 적절한 대상 IP 주소로 라우팅합니다.
  • Cloud Run의 커스텀 에이전트: Cloud Run 직접 VPC 이그레스는 Cloud Run 서비스 인스턴스를 VPC 네트워크에 연결합니다. Cloud Run 서비스가 배포될 때 지정된 VPC 네트워크는 Cloud Run 서비스 프로젝트 또는 공유 VPC 호스트 프로젝트에서 가져올 수 있습니다. Cloud Run에서 전송된 트래픽은 직접 VPC 이그레스의 서브넷 IP 주소에서 시작된 것처럼 VPC 네트워크에 표시됩니다. 그러면 VPC 네트워크에서 트래픽을 적절한 대상 IP 주소로 라우팅합니다.
  • GKE의 커스텀 에이전트: GKE 클러스터는 VPC 네트워크에 직접 상주하며 로컬 서브넷 IP 주소를 사용합니다. 기본적으로 GKE 이그레스 트래픽은 포드 IP 주소를 소스 IP 주소로 사용합니다. 매스커레이드를 구성하면 GKE 이그레스 트래픽은 노드 IP 주소를 소스 IP 주소로 사용합니다. 모든 GKE 이그레스 트래픽은 VPC 네트워크에 의해 라우팅됩니다.

다음 섹션에서는 각 에이전트 호스팅 플랫폼의 VPC 네트워크로 들어오고 나가는 인그레스 및 이그레스 요청을 관리하는 방법에 관한 추가 안내를 제공합니다. 네트워크 고려사항은 루트 에이전트와 하위 에이전트 기능 모두에 적용됩니다.

Vertex AI Agent Engine 네트워킹

이 섹션에서는 Vertex AI Agent Engine에서 호스팅되는 루트 에이전트 및 하위 에이전트의 비공개 네트워킹을 설명합니다. Vertex AI Agent Engine을 사용하여 루트 에이전트를 호스팅하는 경우 Gemini Enterprise와 Vertex AI Agent Engine을 동일한 프로젝트에 배포해야 합니다.

Vertex AI Agent Engine은 VPC 네트워크 외부의 Google 인프라에서 컨테이너를 호스팅합니다. 다른 에이전트에 대한 비공개 연결을 사용 설정하려면 다음 방법을 사용하여 에이전트를 VPC 네트워크에 연결하면 됩니다.

상담사와 다른 상담사 간에 요청을 허용하려면 위의 두 연결을 모두 설정하세요.

VPC 네트워크로의 Vertex AI Agent Engine 이그레스

Vertex AI Agent Engine은 네트워크 이그레스에 Google 관리 테넌트 프로젝트를 사용합니다. 테넌트 네트워크는 에이전트가 Google API에 연결하고 공개 인터넷 이그레스를 제공하지만 기본적으로 고객 VPC 네트워크에 직접 연결되지는 않습니다.

VPC 네트워크 내에 있는 리소스에 에이전트를 연결하기 위해 Vertex AI Agent Engine은 Private Service Connect 인터페이스를 사용합니다. Vertex AI Agent Engine은 테넌트 프로젝트에 네트워크 인터페이스를 배포합니다. 이 인터페이스는 프로젝트의 네트워크 연결 리소스에 연결됩니다. 이 연결은 Vertex AI Agent Engine 런타임과 VPC 네트워크 간에 보안 데이터 경로를 만듭니다. Vertex AI Agent Engine 프로젝트에서 Private Service Connect 인터페이스를 구성하면 시스템에서 Google API로 향하지 않는 모든 에이전트 트래픽을 VPC 네트워크로 라우팅합니다.

Vertex AI Agent Engine VPC 네트워크 이그레스를 배포하려면 다음 리소스를 참고하세요.

Vertex AI Agent Engine 이그레스에 대한 에이전트와 VPC 네트워크를 추가로 보호하려면 이 문서의 다음 섹션을 참고하세요.

VPC 네트워크에서 Vertex AI Agent Engine 인그레스

Vertex AI Agent Engine에서 실행되는 에이전트에 대한 요청은 Vertex AI API 엔드포인트 (aiplatform.googleapis.com)를 사용하여 이루어집니다. VPC 네트워크의 비공개 네트워크 경로를 사용하여 Google API 엔드포인트에 도달하려면 비공개 Google 액세스를 사용하거나 Google API용 Private Service Connect 엔드포인트를 사용하세요.

에이전트에 쿼리를 실행하는 비공개 사용자는 Vertex AI API 엔드포인트 호스트 이름을 비공개 Google 액세스의 비공개 IP 주소 범위 또는 Google API용 Private Service Connect 엔드포인트의 IP 주소로 확인해야 합니다. Vertex AI API 요청은 비공개 관리형 Cloud DNS googleapis.com용 영역에서 해결합니다. VPC 네트워크는 Google 프로덕션 네트워크를 통해 요청을 직접 라우팅합니다.

Google API에 비공개 Google 액세스 또는 Private Service Connect를 사용하는 경우 다음 제품 및 기능을 사용하여 VPC 네트워크에서 Vertex AI Agent Engine으로의 트래픽을 보호할 수 있습니다.

Vertex AI Agent Engine 추가 네트워크 고려사항

Private Service Connect 인터페이스를 사용하는 Vertex AI Agent Engine 이그레스는 VPC 네트워크의 RFC 1918 IP 주소 범위로만 라우팅할 수 있습니다. Vertex AI Agent Engine 이그레스에서 라우팅할 수 없는 특정 대상 범위는 서브넷 IP 범위 요구사항을 참고하세요. 라우팅할 수 없는 IP 주소 범위 대상에 도달하려면 에이전트에서 명시적 프록시 구성을 사용하고 VPC 네트워크에서 라우팅할 수 있는 IP 주소를 사용하는 프록시 리소스를 배포하세요.

Vertex AI Agent Engine이 Private Service Connect 인터페이스 없이 배포되면 기본적으로 인터넷에 액세스할 수 있습니다. 데이터 무단 반출을 방지하려면 VPC 서비스 제어를 사용 설정하여 기본 액세스를 사용 중지하세요.

Vertex AI Agent Engine이 Private Service Connect 인터페이스와 함께 배포되면 VPC 서비스 제어와 관계없이 직접 인터넷 이그레스가 사용 중지됩니다. 에이전트가 Vertex AI Agent Engine에서 일반적으로 도달할 수 없는 대상(예: 인터넷)에 액세스해야 하는 경우 다음 단계를 따르세요.

  1. VPC 네트워크의 RFC 1918 서브넷에서 Secure Web Proxy를 구성합니다. 명시적 프록시 라우팅 모드에서 프록시를 구성해야 합니다.
  2. Secure Web Proxy 호스트 이름의 Cloud DNS 레코드를 만듭니다.
  3. Vertex AI Agent Engine이 VPC 네트워크의 Secure Web Proxy 비공개 주소에 대한 에이전트 DNS 쿼리 해결을 지원하도록 DNS 피어링을 구성합니다.
  4. 에이전트를 배포할 때는 다음을 수행하세요.
    1. 보안 웹 프록시 호스트 이름과 포트를 지정하여 명시적 프록시를 사용하도록 환경 변수를 정의합니다.
    2. 비공개 대상에 액세스하는 경우 해당 대상의 비공개 DNS 영역을 구성합니다.

Vertex AI Agent Engine 이그레스의 트래픽이 VPC 네트워크에 도달하면 VPC 네트워크에서 라우팅할 수 있는 모든 네트워크 대상에 도달할 수 있습니다. Vertex AI Agent Engine 에이전트에서 사용할 수 있는 네트워크 이그레스 대상의 범위를 제한하는 방법에 대한 자세한 내용은 이 문서의 뒷부분에 나오는 Cloud NGFW 섹션을 참고하세요.

Cloud Run 네트워킹

이 섹션에서는 Cloud Run에서 호스팅되는 루트 에이전트 및 하위 에이전트의 비공개 네트워킹을 설명합니다. Cloud Run은 VPC 네트워크 외부의 Google 인프라에서 컨테이너를 호스팅합니다. 다른 에이전트에 대한 비공개 연결을 사용 설정하려면 다음 방법을 사용하여 에이전트를 VPC 네트워크에 연결하면 됩니다.

상담사와 다른 상담사 간에 요청을 허용하려면 위의 두 연결을 모두 설정하세요.

VPC 네트워크로의 Cloud Run 이그레스

VPC 네트워크로의 Cloud Run 연결을 시작하려면 직접 VPC 이그레스를 사용하는 것이 좋습니다. 직접 VPC 이그레스를 사용하면 Cloud Run 인스턴스가 직접 VPC 이그레스를 배포할 때 지정한 서브넷의 IP 주소를 사용하여 공유 VPC 네트워크에 직접 연결됩니다.

직접 VPC 이그레스를 구성할 때는 다음을 수행하세요.

  1. 비공개 Google 액세스가 사용 설정된 타겟 서브넷을 구성합니다.
  2. 모든 트래픽을 VPC 네트워크로 라우팅하도록 트래픽 라우팅을 구성합니다.

이 구성은 개인 정보 보호를 위해 모든 트래픽을 VPC 네트워크를 통해 전송하고 Cloud Run에서 다른 Google API로의 요청을 Google 내부 네트워크를 통해 전송합니다.

Cloud Run의 모든 DNS 쿼리는 VPC 네트워크와 연결된 Cloud DNS 정책 및 영역을 사용합니다. 추가 DNS 피어링 구성은 필요하지 않습니다. Cloud Run에서 호스팅되는 에이전트는 모든 Cloud DNS 비공개 영역과 공개 호스트 이름을 확인합니다.

Cloud Run 이그레스의 에이전트와 VPC 네트워크를 추가로 보호하는 방법에 관한 자세한 내용은 이 문서의 다음 섹션을 참고하세요.

VPC 네트워크에서 Cloud Run 인그레스

Cloud Run은 VPC 네트워크 외부 환경에서 작동하는 Google 관리 플랫폼입니다. 이 환경은 AI 에이전트 또는 도구 워크로드를 실행하는 Cloud Run 서비스의 안정적인 *.run.app URL 엔드포인트를 호스팅합니다. 이러한 엔드포인트는 *.googleapis.com API 서비스를 제공하는 동일한 GFE 진입점에서 제공됩니다. Cloud Run은 비공개 Google 액세스 및 Google API용 Private Service Connect의 비공개 연결을 지원하는 동일한 기본 네트워크 경로를 사용합니다.

에이전트 또는 도구에 쿼리를 실행하는 VPC 네트워크의 비공개 사용자는 run.app 호스트 이름을 비공개 Google 액세스의 비공개 IP 주소 범위 또는 Google API용 Private Service Connect 엔드포인트의 IP 주소로 확인해야 합니다. run.app URL용 비공개 관리형 Cloud DNS 영역은 Cloud Run 서비스 요청을 확인합니다. VPC 네트워크는 Google 프로덕션 네트워크를 통해 요청을 직접 라우팅합니다.

Cloud Run 인그레스를 내부로 설정하면 인증된 내부 소스의 요청만 허용하여 서비스 액세스가 제한됩니다. 승인된 소스는 다음과 같습니다.

  • Cloud Run 서비스 프로젝트의 VPC 네트워크
  • 직접 VPC 이그레스 엔드포인트를 호스팅하는 공유 VPC 네트워크입니다.
  • 동일한 VPC 서비스 제어 경계 내에 있는 리소스
  • VPC 네트워크의 내부 애플리케이션 부하 분산기
  • 서비스 프로젝트 또는 VPC 서비스 제어 경계 내에 있는 Cloud Scheduler, Pub/Sub 등의 Google 서비스

호출 서비스와 호출된 서비스를 모두 포함하는 공통 VPC 서비스 제어 경계를 사용하지 않으면 Cloud Run 서비스 프로젝트 또는 공유 VPC 환경 외부에서 발생하는 트래픽이 외부 트래픽으로 처리됩니다. 이러한 트래픽에는 Vertex AI Agent Engine 및 기타 Cloud Run 서비스와 같은 다른 Google Cloud서비스의 트래픽이 포함됩니다. Cloud Run 내부 인그레스 검사를 충족하려면 이 트래픽이 타겟 서비스의 VPC 네트워크 내에서 시작된 것처럼 보이도록 라우팅되어야 합니다.

필요한 내부 네트워크 기여 분석을 제공하려면 다음 중 하나를 수행하면 됩니다.

  • Private Service Connect 엔드포인트를 사용하여 다른 VPC 또는 프로젝트의 서비스가 VPC 네트워크 내의 비공개 IP 주소를 사용하여 Cloud Run 서비스를 비롯한 Google API 및 서비스에 연결하도록 허용합니다.
  • Cloud Run 서비스 앞에 있는 VPC 네트워크 내에 배치된 내부 애플리케이션 부하 분산기를 통해 트래픽을 라우팅합니다. 부하 분산기는 다른 서비스의 요청을 VPC 네트워크를 통해 전달하여 내부 인그레스 기준을 충족합니다.

서버리스 네트워크 엔드포인트 그룹 (NEG) 백엔드가 있는 내부 애플리케이션 부하 분산기는 Cloud Run 서비스에 직접 매핑되는 VPC 리소스를 만듭니다. 이 모델에서 부하 분산기는 신뢰할 수 있는 인증서로 클라이언트 TLS 연결을 종료합니다. 내부 애플리케이션 부하 분산기는 Cloud Armor 백엔드 보안 정책 및 추가 승인 정책을 비롯한 추가 보안 제어를 지원합니다.

기본적으로 모든 Cloud Run 서비스에 액세스하려면 IAM 인증이 필요합니다. 서비스별로 ID를 사용하고 보안 주체에 Cloud Run 호출자 IAM 역할 (roles/run.invoker)을 부여하는 것이 좋습니다.

Cloud Run 인그레스 제어를 구성하는 방법에 대한 자세한 내용은 다음 리소스를 참고하세요.

비공개 Google 액세스 또는 Google API용 Private Service Connect 엔드포인트를 사용하여 VPC 네트워크에서 Cloud Run으로 트래픽을 전송하는 경우 다음 제품과 기능을 사용하여 해당 트래픽을 보호할 수 있습니다.

내부 애플리케이션 부하 분산기를 사용하여 VPC 네트워크에서 Cloud Run으로 트래픽을 전송하는 경우 다음 제품과 기능을 사용하여 트래픽을 보호할 수 있습니다.

GKE 네트워킹

이 섹션에서는 GKE 기반 에이전트의 네트워킹을 설명합니다.

GKE 및 Gemini Enterprise

GKE는 AI 에이전트 및 도구의 호스트로서 네트워크 및 보안 제어를 위한 맞춤설정 가능한 플랫폼을 제공합니다. GKE에 배포된 멀티 에이전트 AI 시스템은 대규모로 운영 효율성을 제공할 수 있습니다. 다른 Kubernetes 앱 및 더 큰 마이크로서비스 아키텍처와 긴밀하게 통합할 수 있습니다.

GKE 클러스터는 VPC 네트워크의 서브넷 내에서 실행되는 Compute Engine VM 노드입니다. Gemini Enterprise 앱은 VPC 네트워크 외부의 호스팅 환경에서 작동하는 관리형 리소스입니다. Gemini Enterprise 앱이 GKE에서 호스팅되는 맞춤 에이전트를 호출할 수 있도록 하려면 공개 IP 주소와 DNS 이름이 있는 외부 게이트웨이를 안전하게 노출해야 합니다. 트래픽은 Gemini Enterprise 이그레스에서 Google 에지 네트워크로 흐르며, 여기에서 GKE 외부 부하 분산기로 최적화된 경로를 사용합니다.

강력한 인증 및 승인, Cloud Armor, 제한된 권한을 사용하여 GKE 엔드포인트를 보호하는 것이 중요합니다. GKE에서 실행되는 AI 에이전트를 보호하는 포괄적인 심층 방어 모델을 제공하려면 다음 섹션에 설명된 보안 제어를 고려하세요.

GKE 작업 모드

GKE는 관리와 제어의 균형을 맞추기 위해 다음과 같은 작업 모드를 제공합니다.

  • Autopilot: Google에서 컨트롤 플레인, 노드 프로비저닝, 보안 강화, 확장 등 전체 GKE 클러스터 인프라를 자동화합니다.
  • Standard: Google에서 컨트롤 플레인을 관리합니다. 머신 유형 선택, OS 이미지 관리, 수동 확장과 같은 노드 풀 구성에 대한 모든 책임은 사용자에게 있습니다.
인프라 및 컨트롤 플레인 강화
  • 비공개 GKE 클러스터: 공개 IP 주소 없이 노드를 프로비저닝하여 런타임 환경이 직접적인 인터넷 노출로부터 격리되도록 합니다.
  • 마스터 승인 네트워크: Kubernetes API에 대한 관리 액세스를 신뢰할 수 있는 특정 IP 주소 범위로 제한하여 무단 구성 변경에 대해 컨트롤 플레인을 강화합니다. Google Cloud의 IAM 및 VPC 서비스 제어를 사용하여 Kubernetes API의 DNS 엔드포인트를 보호합니다.
ID 및 액세스 (제로 트러스트)
  • IAP: 부하 분산기 수준에서 게이트키퍼 역할을 합니다. 올바른 IAM 권한이 있는 인증된 사용자만 에이전트 엔드포인트에 액세스할 수 있습니다. 이 접근 방식은 보안 경계를 네트워크에서 개별 사용자 및 기기 컨텍스트로 효과적으로 전환합니다.
에지 보호 및 트래픽 관리
  • Cloud Armor: 악성 페이로드를 차단하는 데 도움이 되는 웹 애플리케이션 방화벽 (WAF) 규칙, 가동시간을 보장하는 데 도움이 되는 DDoS 보호, 서비스 소진을 방지하는 데 도움이 되는 비율 제한 등 강력한 에지 보안을 제공합니다.
  • Model Armor: LLM 안전을 위해 특별히 설계된 Model Armor는 프롬프트 인젝션과 데이터 무단 반출을 방지하기 위해 프롬프트와 대답을 실시간으로 검사하고 정리합니다.
내부 네트워크 격리
  • Kubernetes 네트워크 정책: 마이크로서비스 간의 세부적인 최소 권한 통신을 적용합니다. 기본적으로 정책은 명시적으로 허용하지 않는 한 모든 트래픽을 거부하므로 클러스터 내에서 측면 이동이 방지됩니다.

VPC 네트워크로의 GKE 이그레스

VPC 네트워크는 GKE에서 호스팅되는 에이전트의 아웃바운드 연결을 라우팅합니다. 기본 GKE 클러스터 네트워크 모드는 VPC 기반이며, 다음 속성을 제공합니다.

  • GKE 클러스터가 별칭 IP 주소 범위를 사용합니다.
  • 포드 IP 주소는 포드 IP 범위를 지정하여 예약됩니다.
  • 포드 IP 주소는 기본적으로 클러스터 VPC 네트워크와 연결된 기타 VPC 네트워크 내에서 라우팅됩니다.

에이전트 포드가 동일한 노드의 하위 에이전트 포드와 통신하는 경우 트래픽은 노드 네트워크 네임스페이스 내에서 로컬로 라우팅됩니다. 대상 에이전트 포드가 클러스터 내의 다른 노드에 있는 경우 VPC 네트워크 라우팅 테이블을 사용하여 트래픽이 라우팅됩니다. 에이전트 Pod가 부하 분산기 또는 Private Service Connect 엔드포인트와 같은 다른 VPC 리소스와 통신하려면 방화벽 규칙에 따라 동일한 표준 VPC 라우팅을 사용하여 대상에 도달할 수 있습니다.

다음 제품과 서비스를 사용하여 GKE 클러스터를 벗어나는 트래픽을 보호할 수 있습니다.

VPC 네트워크에서 GKE 인그레스

Kubernetes 서비스는 GKE 리소스에 대한 액세스를 제공합니다. 멀티 에이전트 AI 시스템의 경우 GKE 게이트웨이 또는 GKE 추론 게이트웨이를 사용하는 것이 좋습니다. 게이트웨이는 트래픽 제어, 리소스의 운영 분리, 보안 통합을 통해 향상된 기능을 제공합니다. 하지만 시스템 요구사항에 따라 다른 인그레스 서비스 옵션을 사용할 수 있습니다.

게이트웨이 리소스는 애플리케이션 부하 분산기를 만들고 필요한 모든 부하 분산 구성요소를 프로비저닝합니다. 서비스의 백엔드 네트워크 엔드포인트 그룹은 컨테이너에 직접 부하 분산을 제공하도록 연결됩니다. VPC 네트워크에서 소싱된 트래픽에 대해 서비스를 내부적으로 노출하려면 리전 내부 애플리케이션 부하 분산기(gke-l7-rilb) 또는 리전 간 내부 애플리케이션 부하 분산기(gke-l7-cross-regional-internal-managed-mc)의 게이트웨이 클래스를 사용하세요.

애플리케이션 부하 분산기는 GKE 클러스터에서 호스팅되는 AI 에이전트와 도구를 보호하기 위한 추가 보안 제어 포인트를 제공합니다.

  • Cloud Armor: 게이트웨이에서 관리하는 백엔드 서비스에 Cloud Armor 보안 정책을 연결하여 서비스를 보호합니다. 트래픽이 GKE 클러스터 또는 IAP에 도달하기 전에 WAF 스크리닝, IP 주소 및 지역 기반 필터링, DDoS 보호, 비율 제한을 제공합니다.
  • IAP: 백엔드 서비스에서 사용 설정되어 IAM 사용자 인증 정보를 사용하여 앱에 대한 액세스를 제어합니다. IAP는 제로 트러스트 액세스 정책을 적용합니다. IAP는 Gemini Enterprise 앱, 맞춤 에이전트, 외부 리소스를 비롯한 클러스터 리소스에 액세스하는 AI 에이전트를 인증하고 승인합니다. 호출자에게 IAM으로 인증된 ID가 있고 백엔드 서비스에 액세스할 수 있는 승인된 권한이 있어야 합니다.

게이트웨이를 통해 VPC 네트워크에서 GKE 서비스로 트래픽을 전송하는 경우 다음 제품과 기능을 사용하여 트래픽을 보호할 수 있습니다.

게이트웨이를 사용하여 VPC 네트워크에서 GKE 서비스로 트래픽을 보내지 않는 경우 다음 제품 및 서비스를 사용하여 트래픽을 보호할 수 있습니다.

GKE 보안에 대한 자세한 내용은 네트워크 보안 권장사항 및 GKE의 네트워크 보안 이해를 참고하세요.

에이전트 네트워크 보안

다중 에이전트 AI 시스템의 네트워크를 보호하려면 VPC 네트워크와 API 노출 영역을 통해 통신을 보호해야 합니다. VPC 네트워크 데이터 영역은 에이전트와 도구가 안전하게 연결되는 방식을 다룹니다. API 노출 영역은 허용되는 ID와 데이터 교환 유형을 정의합니다. VPC 네트워크와 API 노출 영역 모두에 액세스 제어를 계층화하면 고도로 제어되고 복원력이 뛰어난 보안 태세를 적용할 수 있습니다.

Cloud NGFW

Cloud NGFW는 A2A 및 MCP 통신을 보호하는 네트워크 수준 게이트키퍼 역할을 합니다. 방화벽은 다른 에이전트 및 도구와의 모든 수신 또는 발신 연결을 확인하여 승인된 트래픽만 에이전트 엔드포인트에 도달할 수 있도록 합니다.

Cloud NGFW는 VPC 네트워크 패브릭에 내장된 분산형 방화벽 서비스입니다. 네트워크 스택의 서로 다른 계층에서 작동하는 다음과 같은 기능 등급을 제공합니다.

  • Cloud Next Generation Firewall Essentials: 스테이트풀 방화벽 패킷 필터링을 제공합니다. 정책 규칙은 IP 주소 (L3), 프로토콜, 포트(L4)를 기반으로 정의됩니다.
  • Cloud Next Generation Firewall Standard: 정규화된 도메인 이름 (FQDN) 객체, 위치정보 객체, Google Threat Intelligence의 피드를 사용하여 알려진 악성 주소를 차단하는 IP 기반 시행을 제공합니다.
  • Cloud Next Generation Firewall Enterprise: TLS 복호화 및 침입 감지 및 방지 시스템 (IDPS) 기능을 통해 페이로드를 고급 위협 서명과 비교하여 분석하는 진정한 앱 (L7) 검사 기능을 제공합니다.

Cloud NGFW는 VPC 네트워크에 적용하여 사용한 에이전트 호스팅 플랫폼을 타겟팅하는 데 필요한 규칙에 따라 방화벽 정책을 적용할 수 있습니다.

  • Vertex AI Agent Engine: Vertex AI Agent Engine에서 실행되는 에이전트는 Private Service Connect 네트워크 연결을 사용하여 VPC 네트워크에 연결됩니다. 이러한 연결로 인해 에이전트 네트워크 인터페이스가 VPC 네트워크의 서브넷 내에 표시됩니다. Cloud NGFW 네트워크 방화벽 정책은 VPC 네트워크에 적용됩니다. 정책은 Private Service Connect 네트워크 연결 전용 서브넷의 소스 IP 주소를 기반으로 트래픽을 필터링합니다. 트래픽 일치에는 소스 IP 주소와 대상 IP 주소 범위를 사용할 수 있습니다.
  • Cloud Run: 직접 VPC 이그레스를 사용하는 Cloud Run 서비스는 VPC 네트워크에 지정된 서브넷 내에서 실행되는 인스턴스에서 직접 트래픽을 전송합니다. Cloud NGFW 네트워크 방화벽 정책은 Cloud Run에서 트래픽을 필터링하는 데 사용하는 서브넷에 적용됩니다. 트래픽 일치의 경우 소스 IP 주소 및 대상 IP 주소 범위를 사용할 수 있습니다.
  • GKE: VPC 기반 GKE 클러스터는 VPC 네트워크 보조 IP 주소 범위에서 직접 가져온 포드 IP 주소를 제공합니다. 네트워크 방화벽 정책은 GKE 노드 및 포드의 IP 주소 범위를 기반으로 트래픽을 필터링할 수 있으며, 정책은 보안 태그 및 서비스 계정을 사용할 수 있습니다. 보안 태그는 GKE 노드 역할을 하는 VM 인스턴스에 바인딩됩니다. 그러면 방화벽 규칙이 특정 태그가 있는 노드의 트래픽을 타겟팅하거나 소싱할 수 있습니다. 방화벽 규칙은 노드 풀과 연결된 서비스 계정 ID를 기반으로 GKE 노드의 트래픽을 타겟팅하거나 소싱할 수도 있습니다.

기본 거부 이그레스 정책

기본 거부 전략을 구현하는 것은 최소 권한의 원칙을 준수하는 보안 권장사항입니다. 이 전략은 명시적으로 허용된 네트워크 트래픽만 허용하고 다른 모든 트래픽은 기본적으로 차단합니다. 이 구현은 알려진 합법적인 흐름을 위한 우선순위가 높은 ALLOW 규칙과 우선순위가 낮은 포괄적인 DENY 규칙을 사용하여 방화벽 규칙을 구조화하여 달성됩니다. Cloud NGFW의 모든 등급은 소스 및 대상 IP 주소 범위를 기반으로 하는 규칙을 허용합니다.

방화벽 정책 규칙은 Vertex AI Agent Engine 네트워크 연결 서브넷과 Cloud Run 직접 VPC 이그레스 서브넷의 소스 트래픽을 효과적으로 일치시킬 수 있습니다.

다음은 기본 거부 이그레스 정책의 예입니다.

  • 네트워크 방화벽 정책 및 규칙 만들기: 전역 또는 리전 방화벽 정책을 만들고 VPC 네트워크와 연결합니다. 소스 IP 주소 범위 (--src-ip-ranges=SRC_IP_RANGES)와 대상 IP 주소 범위 (--dest-ip-ranges=DEST_IP_RANGES)를 기반으로 이그레스 방향 (--direction=EGRESS)의 트래픽을 타겟팅하는 방화벽 정책 규칙을 만듭니다.
  • 특정 ALLOW 규칙: 우선순위 번호를 낮게 사용합니다(예: 100~1000). 이러한 규칙은 AI 에이전트가 작동하는 데 필요한 네트워크 트래픽을 정확하게 허용합니다. 이 트래픽에는 다른 내부 서비스, 부하 분산기, 필수 Google API 또는 합법적인 외부 엔드포인트와의 통신이 포함됩니다. Vertex AI Agent Engine 네트워크 연결 서브넷 또는 Cloud Run 직접 VPC 이그레스 서브넷의 소스 트래픽을 원하는 대상과 일치시키는 규칙을 만듭니다.
  • 일반 DENY 규칙: 규칙이 평가 순서에서 마지막에 오도록 하려면 가장 높은 우선순위 번호(예: 2147483647)를 사용합니다. 이 규칙은 앞의 ALLOW 규칙과 일치하지 않는 모든 목적지 (--dest-ip-ranges=0.0.0.0/0)로의 트래픽을 거부합니다.

기본 거부 송신 정책은 명시적으로 승인되지 않은 네트워크 연결을 AI 에이전트가 설정하지 못하도록 방지하고 잠재적인 데이터 무단 반출 또는 악성 사이트 액세스를 차단합니다. 이 정책은 호스팅된 에이전트가 승인된 엔드포인트와만 통신하도록 제한하므로 자율 워크로드에 대한 제어 기능을 유지하는 데 중요합니다.

Cloud NGFW 정책 추가 고려사항

모든 Cloud NGFW 등급에서 사용할 수 있는 기본 거부 전략 외에도 유료 등급 기능을 사용하여 멀티 에이전트 AI 네트워크 보안을 더욱 강화할 수 있습니다.

  • Cloud NGFW Standard 기능:
    • 동적 엔드포인트용 FQDN 객체: AI 에이전트는 IP 주소가 변경될 수 있는 외부 API, 모델 엔드포인트 또는 데이터 소스와 상호작용하는 경우가 많습니다. 도메인 이름으로 필요한 서비스에 일관적으로 액세스하려면 ALLOW 규칙에서 FQDN 객체를 사용하세요.
    • 위치정보 제어: AI 에이전트에 규정 준수 요구사항이 있거나 특정 지리적 지역의 서비스와 상호작용해서는 안 되는 경우 방화벽 규칙에서 위치정보 객체 (--src-region-codes=SRC_COUNTRY_CODES)를 사용하여 해당 위치로 향하거나 해당 위치에서 발생하는 트래픽을 제한합니다.
    • Google Threat Intelligence: 이그레스 필터에서 Google Threat Intelligence를 사용하여 에이전트가 명령 및 제어 (C2) 서버, Tor와 같은 익명화 도구, 멀웨어 배포 사이트와 같은 알려진 악성 대상에 연결되지 않도록 자동으로 차단합니다. Google Threat Intelligence를 사용하면 잠재적으로 도용된 에이전트의 영향을 억제할 수 있습니다. 이러한 대상 필터를 우선순위가 높은 번호 (평가 순서가 낮은) DENY 규칙에 포함하는 것이 좋습니다.
  • Cloud NGFW Enterprise 기능:
    • 레이어 7 검사: 민감한 정보를 처리하거나 위험에 더 많이 노출되는 에이전트의 경우 네트워크 계층 방화벽 규칙에서 분석하지 않는 멀웨어, 스파이웨어, 익스플로잇과 같은 위협이 있는지 패킷 페이로드를 검사합니다.
    • TLS 검사: 검사 엔진이 암호화된 트래픽을 분석하도록 허용하려면 TLS 검사를 사용 설정합니다. 최신 공격과 C2 통신의 대부분이 암호화되어 있으므로 TLS 검사를 사용하는 것이 중요합니다.

환경에 적용될 수 있는 추가 구현 고려사항 또는 제한사항은 다음 리소스를 참고하세요.

IAP

IAP는 AI 앱에 중앙 인증 및 승인 레이어를 제공하여 GKE 클러스터에 대한 인그레스 요청을 보호합니다. IAP는 게이트웨이로 향하는 모든 HTTPS 요청을 가로채고 호출자의 ID와 권한을 확인합니다. IAP는 인증되고 승인된 요청만 백엔드 서비스 워크로드로 전달하도록 허용합니다. 게이트웨이 부하 분산기의 IAP는 클러스터 외부에서 들어오는 트래픽만 보호합니다. 클러스터 내 통신은 IAP를 통과하지 않습니다.

GKE에서 호스팅되고 IAP로 보호되는 AI 앱에 액세스하려면 주 구성원 사용자에게 IAP로 보호되는 백엔드 서비스 리소스에 대한 IAP 보안 웹 앱 사용자 IAM 역할 (roles/iap.httpsResourceAccessor)이 부여되어야 합니다. 배포된 에이전트의 ID로 커스텀 서비스 계정을 구성하는 것이 좋습니다. 커스텀 서비스 계정을 사용하면 최소 권한의 원칙에 따라 권한을 더 정확하게 할당할 수 있습니다.

GKE BackendConfig 커스텀 리소스에 호스팅된 다른 에이전트 및 도구에 액세스할 수 있는 에이전트의 서비스 계정에만 IAP 보안 웹 앱 사용자 IAM 역할을 직접 부여합니다. Gemini Enterprise 앱 액세스를 허용하려면 Gemini Enterprise 프로젝트의 IAM 역할 Discovery Engine 서비스 계정(roles/discoveryengine.serviceAgent)을 바인딩하여 권한을 부여합니다.

VPC 서비스 제어

VPC 서비스 제어는 Google API에 대한 액세스를 엄격하게 제어하여 데이터 무단 반출 위험을 완화합니다. 지원되는 모든 서비스를 포함하는 단일 매크로 경계를 배포하는 것이 좋습니다. 이 접근 방식은 유출에 대한 가장 강력한 방어를 제공합니다. 공유 VPC 아키텍처의 일관된 정책 시행을 위해서는 호스트 프로젝트와 연결된 모든 서비스 프로젝트를 동일한 서비스 경계 내에 포함하는 것이 중요합니다.

프로젝트 경계를 넘어 Gemini Enterprise와 Cloud Run 간의 상호작용을 보호하려면 다음 권장사항을 고려하세요.

  • Gemini Enterprise 및 Cloud Run 프로젝트를 모두 포함하는 단일 VPC 서비스 제어 경계를 배포합니다.
  • 지원되는 모든 VPC 서비스 제어 서비스를 제한된 서비스 목록에 추가합니다. 이 방법을 사용하면 무단 관리 변경사항을 방지할 수 있습니다.
  • 내부 인그레스 및 승인 설정을 적용하여 Cloud Run 서비스에 대한 모든 공개 인터넷 액세스를 차단합니다.

Cloud Run 서비스는 IAM으로 보호됩니다. 호출자는 인증을 받아야 하며 대상 서비스에 대한 Cloud Run 호출자 IAM 역할(roles/run.invoker)이 있어야 합니다. 역할은 Authorization 헤더의 토큰을 검증하여 확인합니다. Cloud Run 서비스를 성공적으로 호출하려면 Gemini Enterprise에서 사용하는 서비스 계정과 같은 서비스 계정에도 Cloud Run 호출자 역할이 부여되어야 합니다.

Gemini Enterprise와 Cloud Run이 서로 다른 프로젝트에 배포된 경우 Cloud Run 인그레스를 '내부'로 설정하려면 VPC 서비스 제어 경계가 필요합니다. 이 경계가 없으면 Gemini의 교차 프로젝트 호출이 외부 트래픽으로 처리되므로 Cloud Run 인그레스를 '모두'로 설정해야 합니다. 그러면 서비스가 공개 인터넷에 노출됩니다.

  • 다음 두 조건이 모두 true인 경우 Cloud Run 인그레스 all가 지원됩니다.
    • VPC 서비스 제어가 사용 설정되어 있지 않습니다.
    • Cloud Run과 Gemini Enterprise가 동일한 프로젝트에 없습니다.
  • 다른 모든 구성에는 Cloud Run 인그레스 internal만 지원됩니다.

추가 VPC 서비스 제어 고려사항

Cloud Run이 VPC 서비스 제어 경계 내에 배포된 경우 포괄적인 보호를 보장하기 위해 다음 정책 가이드라인을 구현하는 것이 좋습니다.

  • 허용된 인그레스 설정 제한: run.allowedIngress 조직 정책 제약 조건을 설정하여 개발자가 실수로 공개 엔드포인트를 배포하지 못하도록 합니다. 이 제약 조건은 새 배포에만 적용됩니다. 이전 배포가 규정을 준수하지 않을 수 있습니다. 경계 내의 기존 Cloud Run 서비스를 감사하고 필요한 인그레스 및 이그레스 설정을 충족하지 않는 서비스를 재배포하거나 업데이트하는 것이 좋습니다.
    • 내부 요청만 허용하려면 값을 internal로 설정합니다.
    • 외부 애플리케이션 부하 분산기를 통한 요청을 허용하려면 값을 internal-and-cloud-load-balancing로 설정합니다.
  • 허용되는 VPC 이그레스 설정 제한: 경계 방화벽 규칙에서 검사할 수 있도록 모든 아웃바운드 요청을 VPC를 통해 라우팅하려면 run.allowedVPCEgress 조직 정책 제약 조건 값을 all-traffic로 설정합니다. 이 설정을 사용하려면 모든 Cloud Run 버전에서 직접 VPC 이그레스 또는 서버리스 VPC 액세스 커넥터를 사용해야 합니다. 이 제약 조건은 새 배포에만 적용됩니다. 이전 배포가 규정을 준수하지 않을 수 있습니다. 경계 내에 있는 기존 Cloud Run 서비스를 감사하고 필요한 인그레스 및 이그레스 설정을 충족하지 않는 서비스를 재배포하거나 업데이트하는 것이 좋습니다.
  • 컨테이너 이미지와 서비스 공동 배치: 컨테이너 이미지가 포함된 Artifact Registry 저장소가 Cloud Run 서비스와 동일한 경계 내에 있어야 합니다. 명시적인 인그레스 및 이그레스 규칙을 설정하지 않으면 경계 간 이미지 가져오기가 자동으로 차단됩니다.
  • 액세스 수준 관리: Cloud Run 호출에는 IAM 주 구성원 ID를 사용하는 VPC 서비스 제어 인그레스 정책 규칙 및 액세스 수준이 지원되지 않습니다. 대신 네트워크 기반 기준 또는 기기 기반 액세스 수준으로 액세스를 관리해야 합니다.

Model Armor

Model Armor는 AI 앱의 보안과 안전을 강화하는 API 기반 서비스입니다. AI 에이전트는 LLM으로 전송되기 전에 사용자 프롬프트를 정리하고 사용자에게 반환되기 전에 모델 응답을 정리하는 호출을 실행하여 Model Armor와 상호작용합니다. Model Armor는 LLM 프롬프트와 대답을 적극적으로 검사하여 새로운 위험을 감지하는 중요한 검사 지점을 제공하고 책임감 있는 AI 표준을 구현하는 제어 지점을 제공합니다. Model Armor를 사용하여 데이터 상주 요구사항과 데이터 주권 법규를 준수하는 것이 좋습니다. VPC 서비스 제어 경계 내에서 Model Armor를 사용하려면 VPC 네트워크 내에서 Model Armor 리전 엔드포인트의 Private Service Connect 엔드포인트를 구성해야 합니다.

Model Armor는 VPC 네트워크의 리전별 Private Service Connect 엔드포인트를 통해 비공개로 액세스하는 리전 서비스입니다. 예를 들어 us-central1 서비스는 리전 엔드포인트 modelarmor.us-central1.rep.googleapis.com를 사용하여 호출됩니다. 리전 엔드포인트는 데이터 상주를 보장하는 데 도움이 됩니다.

에이전트의 액세스를 사용 설정하려면 Model Armor 서비스가 필요한 모든 리전에서 다음 구성요소를 구성하세요.

  1. Model Armor 서비스가 상주하는 VPC 네트워크 리전에서 RFC 1918 서브넷을 만들거나 식별합니다.
  2. RFC 1918 서브넷에 리전 엔드포인트를 만듭니다.
  3. Cloud DNS 비공개 영역과 Model Armor 리전 엔드포인트 호스트 이름(예: modelarmor.us-central1.rep.googleapis.com)의 레코드를 만들어 리전 엔드포인트의 IP 주소로 확인합니다.
  4. Vertex AI Agent Engine 상호 운용성을 위해 Vertex AI Agent Engine에서 VPC 네트워크와 연결된 Cloud DNS 비공개 영역으로 DNS 피어링을 설정합니다. 에이전트가 Model Armor에 요청을 하면 Cloud DNS가 호스트 이름 요청을 VPC 네트워크의 Private Service Connect 리전 엔드포인트의 IP 주소로 확인합니다. Cloud Run 및 GKE에서 호스팅되는 에이전트에는 이 단계가 필요하지 않습니다.

Gemini Enterprise를 Model Armor와 통합하려면 Gemini Enterprise와 동일한 프로젝트에서 Model Armor 템플릿을 만드세요. 템플릿과 Gemini Enterprise 앱의 위치가 동일해야 합니다.

Model Armor 사용 설정에 관한 자세한 내용은 다음 리소스를 참고하세요.

Cloud Armor

Cloud Armor는 요청이 백엔드 서비스 런타임에 도달하기 전에 부하 분산기 뒤에 있는 앱과 서비스를 보호하는 분산 네트워크 보안 서비스입니다. AI 에이전트 워크로드에는 A2A, MCP, API 호출을 사용하는 서비스 간 통신이 많이 포함됩니다. Cloud Armor 보호는 예상되는 에이전트형 요청을 준수하는 비율 제한, WAF 스크리닝, 맞춤 규칙을 통해 보안 설계에 복원력을 추가합니다. Cloud Armor 보안 정책을 애플리케이션 부하 분산기 백엔드 서비스에 연결하면 악성 요청에 대해 트래픽을 필터링하고 비율 제한으로 관리할 수 있으며 DDoS 공격을 완화할 수 있습니다.

다음 시나리오에서는 에이전트 네트워크 아키텍처에 Cloud Armor를 배포할 수 있습니다.

  • 내부 애플리케이션 부하 분산기가 있는 Cloud Run: 서버리스 NEG 백엔드가 있는 내부 애플리케이션 부하 분산기를 사용하여 Cloud Run에서 실행되는 에이전트와 도구를 보호합니다. 서버리스 NEG에 백엔드 보안 정책을 적용하여 내부 트래픽 및 비율 제한에 WAF 규칙을 적용합니다. 에이전트 커뮤니케이션을 제어하려면 IP 주소와 헤더를 기반으로 추가 맞춤 규칙을 정의하면 됩니다.
  • 게이트웨이: 영역 NEG 백엔드가 있는 전역 또는 리전 외부 애플리케이션 부하 분산기의 게이트웨이 리소스 정의를 사용하여 GKE에서 실행되는 에이전트와 도구를 보호합니다. Kubernetes Gateway API를 사용하여 정의된 Cloud Armor 보안 정책으로 GCPBackendPolicy 리소스를 적용합니다. 리전 외부 애플리케이션 부하 분산기를 사용하는 경우 Cloud Armor는 WAF 규칙, IP 주소 및 지리적 위치 기반 제어, 비율 제한이 적용된 백엔드 보안 정책을 지원합니다. 전역 외부 애플리케이션 부하 분산기는 Google Cloud Armor 적응형 보호 및 Google 위협 인텔리전스를 사용하는 백엔드 보안 정책과 추가 에지 보안 정책을 지원합니다.

Secure Web Proxy

Secure Web Proxy는 VPC 네트워크 내에 배포되어 VPC 네트워크 또는 연결된 네트워크 내에서 시작되는 HTTP/S 트래픽을 필터링하는 리전 관리형 서비스입니다. 아웃바운드 인터넷 트래픽에 대한 세분화된 제어 및 가시성을 제공하기 위해 중앙화된 프록시 및 보안 시행 지점 역할을 합니다. 또한 내부 서비스 통신을 위한 명시적 프록시 역할도 합니다.

보안 웹 프록시는 명시적 프록시 라우팅 모드, Private Service Connect 서비스 연결 모드, 다음 홉 모드 등 세 가지 배포 모드를 지원합니다. 이 문서의 중점인 명시적 프록시 라우팅 모드에서 Secure Web Proxy를 사용하는 것이 좋습니다. 이 모드에서는 HTTP 클라이언트가 Secure Web Proxy IP 주소 또는 호스트 이름으로 직접 연결되도록 명시적으로 구성해야 합니다.

VPC 네트워크에 Secure Web Proxy를 배포하려면 프런트엔드 서브넷과 프록시 전용 서브넷을 구성해야 합니다. Secure Web Proxy는 완전 관리형 서비스입니다. 보안 웹 프록시가 배포되면 프록시 리소스와의 특정 통합을 위해 VPC 네트워크에 Cloud Router와 Cloud NAT가 자동으로 배포되고 구성됩니다. 이 구성에서는 아웃바운드 요청이 인터넷으로 이그레스되기 전에 Secure Web Proxy를 통과해야 합니다.

Secure Web Proxy를 명시적 프록시로 사용하면 Vertex AI Agent Engine Private Service Connect 인터페이스, Cloud Run 직접 VPC 이그레스, VPC 네이티브 GKE 클러스터에서 발생하는 에이전트 요청이 지원됩니다. 에이전트가 HTTP CONNECT 메서드를 사용하여 Secure Web Proxy에 요청을 보내면 TCP 세션 트래픽이 보안 정책 규칙이 적용되는 프록시로 터널링됩니다. 트래픽이 허용되면 보안 웹 프록시는 트래픽을 제어된 인터넷 이그레스 또는 VPC 네트워크에서 라우팅할 수 있는 비공개 네트워크 대상으로 전송합니다.

명시적 프록시 라우팅

Vertex AI Agent Engine 이그레스에서는 에이전트가 VPC 네트워크의 인터넷 대상 또는 라우팅 불가능한 IP 주소 범위에 도달할 수 있도록 명시적 프록시 구성을 사용해야 합니다. Vertex AI Agent Engine 상호 운용성을 위해서는 VPC 네트워크의 프런트엔드 서브넷에서 RFC 1918 IP 주소로 Secure Web Proxy 리소스를 구성하는 것이 좋습니다. 이 구성을 사용하면 Vertex AI Agent Engine에서 Secure Web Proxy에 직접 연결할 수 있습니다. 그런 다음 VPC 네트워크 또는 연결된 네트워크에 있는 라우팅할 수 없는 IP 주소 대상으로의 모든 연결을 프록시할 수 있습니다.

명시적 라우팅 모드에서 Secure Web Proxy의 에이전트 호스팅 플랫폼 사용을 지원하려면 다음 네트워킹 리소스를 구성하세요.

  1. 보안 웹 프록시 리소스를 호스팅할 VPC 네트워크에서 RFC 1918 서브넷을 만들거나 식별합니다.
  2. 보안 웹 프록시 리소스의 IP 주소로 확인되는 보안 웹 프록시 호스트 이름 (예: swp.example.com)의 Cloud DNS 레코드를 만듭니다.
  3. Vertex AI Agent Engine 상호 운용성을 위해 Vertex AI Agent Engine에서 VPC 네트워크와 연결된 Cloud DNS 비공개 영역으로 DNS 피어링을 설정합니다. 에이전트가 Secure Web Proxy에 요청을 하면 Cloud DNS는 호스트 이름 요청을 VPC 네트워크의 Secure Web Proxy 리소스 IP 주소로 변환합니다. Cloud Run 및 GKE에서 호스팅되는 에이전트에는 이 단계가 필요하지 않습니다.

상담사 프록시 설정

HTTP(S) 프록시를 사용하도록 에이전트 앱을 구성하는 표준 방법은 다음 환경 변수를 설정하는 것입니다.

  • HTTP_PROXY: HTTP 트래픽의 명시적 프록시 서버 URL입니다 (예: http://swp.example.com:8888). 이 설정은 클라이언트에서 프록시로 HTTP CONNECT 메서드를 사용합니다. HTTP가 지정되어 있어도 에이전트 런타임에서 타겟 엔드포인트까지 프록시를 통해 엔드 투 엔드 TLS 암호화가 유지됩니다.
  • HTTPS_PROXY: HTTPS 트래픽의 명시적 프록시 서버 URL입니다 (예: https://swp.example.com:8888). HTTP_PROXY 설정과 마찬가지로 HTTPS_PROXY 설정은 기본적으로 TLS를 사용합니다. 하지만 기본 TLS 외에 자체 TLS 암호화를 사용 설정하여 추가 암호화 레이어를 제공할 수 있습니다. 자세한 내용은 Certificate Authority Service를 참고하세요.
  • NO_PROXY: 프록시를 거치지 않아야 하는 호스트 이름 또는 IP 주소의 쉼표로 구분된 목록입니다. 예를 들어 metadata.google.internal 및 169.254.169.254를 NO_PROXY 목록에 추가하면 워크로드가 Google API 및 서비스에 대한 인증 및 승인을 위해 메타데이터 서비스에 직접 액세스할 수 있습니다.

배포 중에 env_vars 인수를 사용하여 변수를 설정하면 에이전트 런타임 환경 내에서 변수를 사용할 수 있습니다 (예: Python에서 os.environ 사용 시). 대부분의 표준 HTTP 클라이언트 라이브러리는 이러한 환경 변수를 자동으로 검색하고 사용하여 지정된 프록시를 통해 트래픽을 라우팅합니다. 이 접근 방식은 Python 앱과 requests 같은 HTTP 클라이언트 라이브러리에서 흔히 사용됩니다. 에이전트를 배포할 때 에이전트가 연결해야 하는 비공개 도메인에 Secure Web Proxy를 사용하기 위한 환경 변수를 정의합니다. 비공개 도메인 대상도 Cloud DNS에 포함되어 있는지 확인합니다.

다음 예에서는 에이전트 객체에서 Vertex AI Agent Engine 프록시 배포를 보여줍니다.

## 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은 서비스 버전 수준에서 환경 변수 설정을 지원합니다. 이 접근 방식은 컨테이너 이미지 내에 설정된 이름이 동일한 환경 변수를 재정의합니다. 이 접근 방식은 서비스 인스턴스가 시작될 때 프록시 변수와 같은 운영 매개변수를 설정하는 데 유용합니다.

다음 예에서는 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"

GKE 포드에서 명시적 프록시 구성을 구현하려면 프록시 변수를 지정하는 ConfigMap 리소스를 정의하세요.

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"

ConfigMap 키를 포드에 적용하려면 컨테이너 매니페스트에서 envFrom 필드를 사용합니다. 이 사양은 런타임에 환경 변수를 컨테이너에 삽입합니다.

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 서비스

TLS 검사를 위해 Secure Web Proxy 또는 Cloud NGFW를 구성할 때는 CA 서비스 (CA Service)가 필요합니다. TLS 검사가 사용 설정되어 있고 워크로드의 대상이 TLS를 사용하는 경우 CA 서비스는 해당 대상의 인증서를 생성하고 서명합니다. 실제 대상의 암호화된 트래픽이 Secure Web Proxy 또는 Cloud NGFW에 도착하면 패킷을 복호화하고 검사한 후 정책을 적용합니다. 정책에서 패킷을 허용하는 경우 서비스는 최종 목적지를 위해 패킷을 다시 암호화합니다. CA 서비스를 사용하여 다른 Google 관리 서비스에 인증서를 제공할 수도 있습니다.

CA 서비스는 관리형 서비스입니다. CA Service가 구성되면 루트 CA 인증서가 만료될 때까지 리프 인증서 서명을 처리합니다. 루트 CA 인증서가 만료되지 않도록 업데이트해야 합니다.

CA 서비스는 멀티 에이전트 AI 아키텍처에서 트래픽 검사와 인증서 관리를 대규모로 지원하기 위해 다음과 같은 기능을 지원합니다.

  • TLS 검사: 전체 TLS 검사를 위해서는 비공개 CA를 사용해야 합니다. HTTPS 페이로드를 완전히 복호화하고 분석하려면 중간 프록시 기기(보안 웹 프록시 또는 Cloud NGFW)가 클라이언트와의 TLS 세션을 종료해야 합니다. 프록시는 클라이언트가 요청된 도메인에 대해 신뢰할 수 있는 것으로 수락하는 유효한 인증서를 제공해야 합니다.

    CA 서비스는 요청된 사이트에 대해 사이트별 가장 인증서를 동적으로 생성하고 서명할 수 있습니다. 클라이언트의 트러스트 저장소에 비공개 루트 CA 인증서가 설치되어 있으면 동적으로 생성된 이 인증서를 유효한 것으로 간주합니다. 클라이언트는 프록시에서 보낸 인증서를 신뢰하므로 요청을 보냅니다. 프록시는 TLS 세션을 종료하고, 패킷을 복호화하고, 콘텐츠를 검사한 다음 정책을 시행합니다.

  • 인증서 배포: Vertex AI Agent Engine, Cloud Run 또는 GKE에서 실행되는 AI 에이전트와 같은 내부 클라이언트 리소스에는 로컬 트러스트 저장소에 추가된 비공개 루트 CA 인증서가 필요합니다. 루트 CA 인증서 공개 키를 Secret Manager에 저장하면 AI 에이전트가 시작 시 인증서를 가져와 시스템 트러스트 저장소에 추가할 수 있습니다.

    내부 애플리케이션 부하 분산기와 같은 내부 서버 리소스는 신뢰할 수 있는 서버 엔드포인트 역할을 하고 클라이언트 TLS 세션을 종료하기 위해 비공개 CA에서 발급한 인증서가 필요합니다. 애플리케이션 부하 분산기는 인증서 요청에 서명하고 부하 분산기에 배포하는 CA Service를 자동화하기 위해 인증서 관리자 발급 구성과 통합됩니다.

인증서 작업에 대한 자세한 내용은 다음 리소스를 참고하세요.

A2A 연결 보안

루트 에이전트는 다양한 런타임 호스팅 플랫폼에 배포된 다양한 하위 에이전트 및 MCP 서버와 통신합니다. 각 환경에는 A2A 또는 MCP 레이어에서 추상화해야 하는 고유한 네트워킹 및 보안 요구사항이 도입됩니다.

다음 다이어그램은 이 설계 가이드에서 지원하는 구성요소와 가능한 연결 경로를 보여줍니다.

GKE, Cloud Run, Vertex AI Agent Engine을 비롯한 다양한 호스팅 플랫폼 간의 Agent2Agent (A2A) 연결 패턴과 MCP 서버 및 인터넷에 대한 연결

위 다이어그램은 이러한 연결 가능성을 요약합니다.

  • 사용자는 Gemini Enterprise 앱을 통해 에이전트 시스템과 상호작용합니다.
  • Gemini Enterprise 앱은 Google 인프라를 사용하여 GKE, Cloud Run 또는 Vertex AI Agent Engine에서 실행되는 루트 에이전트에 연결합니다.
  • Gemini Enterprise 앱과 루트 에이전트는 Google 인프라를 사용하여 Vertex AI의 Model Armor 및 Gemini LLM에 연결됩니다.
  • 루트 에이전트는 Google 인프라를 사용하여 Cloud Run 또는 Vertex AI Agent Engine에서 실행되는 하위 에이전트에 연결할 수 있습니다.
  • 루트 에이전트는 비공개 IP 주소를 사용하여 Vertex AI Agent Engine, Cloud Run, GKE에서 실행되는 하위 에이전트에 연결할 수 있습니다. 이러한 연결은 VPC 네트워크를 통해 라우팅되어야 합니다.
  • 루트 에이전트와 하위 에이전트 모두 Cloud Run 또는 GKE에서 실행되는 MCP 서버에 연결할 수 있습니다. MCP 서버에 연결되는 에이전트는 Google 인프라 또는 VPC 네트워크를 사용할 수 있습니다. MCP 서버는Google Cloud, 온프레미스, 다른 클라우드 또는 인터넷에서 호스팅되는 도구에 대한 액세스를 제공합니다.
  • 인터넷에서 호스팅되는 서비스는 Secure Web Proxy를 통해 직접 연결할 수 있습니다.

다음 섹션에서는 안전한 A2A 상호작용에 필요한 런타임 데이터 경로와 보안 제어에 관한 리소스를 제공합니다. 이 정보는 비공개 연결을 설정하고 에이전트 간 엔드 투 엔드 데이터 경로를 보호하는 데 필요한 다중 계층 방어를 구현하기 위한 아키텍처 표준으로 사용됩니다.

GKE 소스 에이전트

다음 표에는 GKE가 소스 에이전트인 경우 트래픽을 보호하는 데 도움이 되는 리소스가 나와 있습니다. 이 트래픽은 GKE 클러스터를 호스팅하는 VPC 네트워크를 통해 이동합니다.

대상 에이전트 (데이터 경로) 보안 제어
Vertex AI Agent Engine (내부)
Cloud Run (내부)
Cloud Run (Google API용 Private Service Connect)
Cloud Run 액세스 (서버리스 NEG)
GKE
VPC 네트워크를 통한 인터넷

Vertex AI Agent Engine (내부) 소스 에이전트

다음 표에는 Vertex AI Agent Engine이 소스 에이전트이고 트래픽이 Google 인프라를 통해 직접 이동하는 경우 트래픽을 보호하는 데 도움이 되는 리소스가 나와 있습니다. 이러한 경로에는 VPC 네트워크가 포함되지 않습니다.

대상 에이전트 (데이터 경로) 보안 제어
Vertex AI Agent Engine (내부)
Cloud Run (내부)

Vertex AI Agent Engine (Private Service Connect 인터페이스) 소스 에이전트

다음 표에는 Vertex AI Agent Engine이 소스 에이전트이고 트래픽이 Private Service Connect 인터페이스를 사용하여 VPC 네트워크를 통과할 때 트래픽을 보호하는 데 도움이 되는 리소스가 나와 있습니다.

대상 에이전트 (데이터 경로) 보안 제어
Cloud Run (Private Service Connect Google API)
Cloud Run 액세스 (서버리스 NEG)
GKE
VPC 네트워크를 통한 인터넷

Cloud Run (내부) 소스 에이전트

다음 표에는 Cloud Run이 소스 에이전트이고 트래픽이 Google 인프라를 통해 직접 이동할 때 트래픽을 보호하는 데 도움이 되는 리소스가 나와 있습니다. 이러한 경로에는 VPC 네트워크가 포함되지 않습니다.

대상 에이전트 (데이터 경로) 보안 제어
Vertex AI Agent Engine (내부)
Cloud Run (내부)

Cloud Run (직접 VPC 이그레스) 소스 에이전트

다음 표에는 Cloud Run이 소스 에이전트이고 트래픽이 직접 VPC 이그레스를 사용하여 VPC 네트워크를 통과할 때 트래픽을 보호하는 데 도움이 되는 리소스가 나와 있습니다.

대상 에이전트 (데이터 경로) 보안 제어
Cloud Run (Google API용 Private Service Connect)
Cloud Run 액세스 (서버리스 NEG)
GKE
VPC 네트워크를 통한 인터넷
Google API용 Vertex AI Agent Engine Private Service Connect

MCP 연결 보안

다음 목록에서는 에이전트 런타임과 MCP 서버 간의 데이터 경로를 보호하는 데 사용되는 호스팅 플랫폼과 심층 방어 제어를 간략하게 설명합니다. Vertex AI Agent Engine, Cloud Run 또는 GKE의 소스 에이전트의 경우 대상 MCP 서버에 따라 다음 보안 제어를 사용합니다.

  • 인터넷:
    • VPC 서비스 제어
    • Model Armor
    • Cloud NGFW
    • Secure Web Proxy
  • Google MCP:
    • VPC 서비스 제어
    • Model Armor

다음 단계

참여자

저자:

  • Deepak Michael | 네트워킹 전문 고객 엔지니어
  • 마이클 라슨 | 고객 엔지니어, 네트워킹 전문가
  • 빅터 모레노 | Cloud Networking 제품 관리자

기타 참여자: