Выход Agent Gateway из среды выполнения агента в сеть VPC

1. Введение

В этом практическом занятии рассматривается управление исходящим трафиком Agent Gateway для агентов ИИ, обращающихся к удаленным конечным точкам через частную сеть VPC. Agent Gateway, работающий в режиме исходящего трафика ( агент-в-любое место ), поддерживает частное подключение к сети VPC с использованием интерфейсов Private Service Connect (PSC) . В этом сценарии Agent Runtime использует Agent Gateway для доступа к удаленному потоковому HTTP MCP-серверу, размещенному на Cloud Run, используя конечную точку Private Service Connect (PSC) для API Google в сети VPC.

Приложения искусственного интеллекта, от автономных чат-ботов до автономных систем с многоагентными рабочими процессами, могут динамически вызывать внешние инструменты. Предоставление агентам контролируемого доступа к запросам к базам данных, получению веб-контента и выполнению действий имеет важное значение для безопасной и продуктивной работы агентов. Однако в корпоративных средах обеспечение безопасности выполнения инструментов агентами представляет собой сложную задачу. Если агент имеет прямой доступ к сети, атаки с внедрением импульсов или имитация моделей могут привести к утечке конфиденциальных данных или выполнению деструктивных команд.

Для управления автономными агентами в масштабе предприятия Agent Gateway предоставляет централизованную точку обеспечения принципа нулевого доверия, непосредственно интегрированную в архитектуру платформы агентов . Вместо того чтобы полагаться на пользовательские реализации, уникальные для каждого приложения или кода агента, Agent Gateway обеспечивает маршрутизацию сети, управление агентами и безопасность во время выполнения на уровне платформы.

Когда Agent Gateway работает в режиме исходящего трафика ( агент — куда угодно ), он перенаправляет все исходящие запросы от агентов, настроенных на использование шлюза. Каждый запрос рабочей нагрузки агента аутентифицируется с использованием уникального идентификатора агента и авторизуется с помощью политик Identity-Aware Proxy (IAP) . Вызовы инструментов MCP динамически декодируются и проверяются на предмет применения политик. Администраторы безопасности могут централизованно устанавливать детальные разрешения, чтобы гарантировать, что агенты могут вызывать только утвержденные конечные точки и методы.

Что вы строите

  • Шлюз агентов в режиме исходящего трафика ( агент — куда угодно ).
  • Расширение авторизации Identity-Aware Proxy (IAP)
  • Агент Agent Runtime ADK с идентификацией агента
  • Облачный потоковый HTTP MCP-сервер
  • Реестр агентов с использованием Google API и пользовательских конечных точек MCP.
  • Политики авторизации с контролем доступа IAM
  • Ресурсы сети VPC, зона Cloud DNS и конечная точка PSC для API Google.
  • Подключение сети PSC для выхода Agent Gateway
  • Правила политики межсетевого экрана Cloud Next Generation Firewall (NGFW)

рисунок1

Рис. 1. Архитектура Codelab

Чему вы научитесь

  • Как развернуть Agent Gateway в структурированной последовательности конфигурации
  • Как настроить Agent Gateway с подключением к частной сети VPC.
  • Как перевести политики авторизации из тестового режима в режим принудительного применения.
  • Как зарегистрировать конечные точки Google API и серверы MCP в реестре агентов.
  • Как проводить аудит журналов Agent Gateway для проверки управления исходящим трафиком.
  • Как проверить исходящий трафик Agent Gateway с помощью журналов Cloud NGFW

Что вам нужно

  • Проект Google Cloud с включенной функцией выставления счетов.
  • Права доступа IAM для предоставления сетевых сервисов, наборов данных BigQuery и ресурсов платформы агентов.
  • POSIX-совместимая оболочка ( bash или zsh ) с установленным Google Cloud CLI (компоненты gcloud и bq ).
  • Инструменты командной строки: git , curl , jq (процессор JSON), Python 3 и uv (менеджер пакетов Python).

2. Понятия

Последовательность развертывания

Данный практический пример использует структурированную последовательность настройки, благодаря чему агенты получают доступ к необходимым ресурсам на этапе инициализации, а возможность проверки подключения подтверждается до применения политик принудительного доступа.

В этом практическом занятии используется следующая последовательность развертывания:

  1. Запуск в режиме DRY_RUN : Убедитесь, что запросы агента успешно поступают на шлюз и проходят через него (режим только аудита).
  2. Зарегистрируйте все сервисы: зарегистрируйте все компоненты агента в реестре агентов и подтвердите доступ к инструментам агента. Используйте Cloud Logging и панель мониторинга Agent Gateway для просмотра запросов к реестру агентов.
  3. Создание политик авторизации: Создайте и примените политики авторизации, разрешающие исходящий трафик от агентов к серверам и конечным точкам MCP.
  4. Переключитесь в режим ENFORCED : обновите политику расширения авторизации, чтобы обеспечить соблюдение правил и заблокировать несанкционированный исходящий трафик.

рисунок 2

Рис. 2. Последовательность развертывания

Топология исходящей маршрутизации

Agent Gateway egress ( от агента к любому месту ) действует как централизованный прокси-сервер с нулевым доверием для исходящих запросов к агентским рабочим нагрузкам. Когда агент отправляет запрос к внешнему инструменту или API, исходящий запрос перехватывается Agent Gateway и оценивается на соответствие политикам управления, прежде чем быть направленным к месту назначения. В архитектуре Google Cloud Agent Platform Agent Gateway обеспечивает подключение к плоскости данных для:

  • Частные сети (VPC): исходящий трафик, ориентированный на внутренние корпоративные API, микросервисы, базы данных, размещенные в частных VPC, а также локальные или межоблачные сети, доступные через гибридное соединение.
  • Внешние сети (Интернет): Исходящий трафик, направленный на сторонние веб-сервисы, API SaaS или общедоступные конечные точки.
  • Сервисы ИИ и платформа агентов: исходящий трафик, ориентированный на управляемые API Google Cloud, базовые модели, конечные точки Google MCP (например, BigQuery) и сервисы управления платформой (реестр агентов и политики IAP).

рисунок3

Рис. 3. Топология маршрутизации исходящего трафика шлюза агента.

В центре внимания этого практического занятия — исходящий трафик от пользовательского агента в Agent Runtime, нацеленный на конечную точку PSC для Google API, развернутую в сети VPC. Эта архитектура обеспечивает частный доступ к серверу MCP, размещенному в Cloud Run, за счет использования сетевого подключения PSC для исходящего трафика через Agent Gateway.

Подключение VPC

Исходящий трафик Agent Gateway ( агент-в-любое место ) может подключаться к сети VPC, указав параметр networkConfig: egress: networkAttachment: [URI] в конфигурационном файле развертывания YAML. Этот параметр настраивает правила маршрутизации на Agent Gateway для отправки трафика, который разрешается в частные IP-адреса через сетевое подключение PSC, в сеть VPC.

рисунок4

Рис. 4. Подключение Agent Gateway к VPC.

Agent Gateway способен разрешать частные DNS-имена хостов, используя пиринг Cloud DNS с указанным целевым проектом и сетью VPC. Любые частные зоны, перечисленные в конфигурации dnsPeeringConfig: domains: [NAME] , будут использовать записи Cloud DNS в целевом проекте. Любые другие DNS-запросы будут использовать публичный DNS-сервер Cloud DNS по умолчанию в VPC.

На этом завершается раздел, посвященный концепциям... далее переходим к разделу «Настройка» .

3. Настройка

Необходимые роли IAM

Для создания ресурсов в этом практическом занятии необходимы следующие роли:

Категория

Требуемая роль IAM (ID)

Описание

управление API

roles/serviceusage.serviceUsageAdmin

Включите сервисы Google Cloud API

Сетевые устройства и шлюзы

roles/networkservices.admin

Шлюз агента предоставления услуг

Расширения сервисов

roles/serviceextensions.admin

Настройка расширений маршрутизации

Сетевая безопасность

roles/networksecurity.admin

Разверните политики авторизации.

Реестр агентов

roles/agentregistry.admin

Каталог разрешенных хостов

Vertex AI и агенты

roles/aiplatform.admin

Развертывание рабочих нагрузок среды выполнения агента

Политика выхода

roles/iap.admin

Применить политики roles/iap.egressor

Облачное хранилище

roles/storage.admin

Управление тестовыми хранилищами для развертывания

Журналы и аудит

roles/logging.viewer

Проверьте трассировки и журналы аудита.

Разработчик Cloud Run

roles/run.developer

Развертывание сервисов Cloud Run

Считыватель реестра артефактов

roles/artifactregistry.reader

изображения контейнеров для вытягивания

Администратор вычислительной сети

roles/compute.networkAdmin

Управление сетевыми ресурсами VPC

Администратор DNS

roles/dns.admin

Управление зонами и записями Cloud DNS

В качестве альтернативы можно использовать общую базовую роль, например, roles/admin или устаревшую роль roles/owner .

Получите доступ к своему проекту

В этом практическом занятии используется один проект Google Cloud. Шаги настройки выполняются с помощью командной строки gcloud и команд оболочки Linux.

Для начала откройте командную строку вашего проекта Google Cloud:

Укажите идентификатор вашего проекта. 

gcloud config set project SET_YOUR_PROJECT_ID_HERE

Аутентификация сессии 

# login to gcloud cli
gcloud auth login

# login for gcloud api
gcloud auth application-default login

Установка переменных среды оболочки 

# set custom var for slug (eg, "foo") and region preference
export SLUG="foo"
export REGION="us-central1"
export MREGION="us"
echo ${SLUG}
echo ${REGION}
echo ${MREGION}

# create project vars (automatic)
export PROJ_ID=$(gcloud config list --format="value(core.project)")
export PROJ_NO=$(gcloud projects describe ${PROJ_ID} --format="value(projectNumber)")
export ORG_ID=$(gcloud projects get-ancestors ${PROJ_ID} --format="value(id)" | tail -n 1)
export USER_IDENTITY=$(gcloud config get-value account)
echo ${PROJ_ID}
echo ${PROJ_NO}
echo ${ORG_ID}
echo ${USER_IDENTITY}

# create resource vars (automatic)
export AGW_NAME="agw-${SLUG}-${REGION}-ata"
export AGW_URI="projects/${PROJ_ID}/locations/${REGION}/agentGateways/${AGW_NAME}"
export RE_AGENT_NAME="agent-weather"
export RE_AGENT_ID_SET="principalSet://agents.global.org-${ORG_ID}.system.id.goog/attribute.platformContainer/aiplatform/projects/${PROJ_NO}"
export STAGING_BUCKET="agent-staging-${PROJ_NO}"
export MCP_NAME="mcp-weather"
export MCP_DISPLAY_NAME="${MCP_NAME}-${PROJ_NO}.${REGION}.run.app"
export MCP_URL="https://${MCP_DISPLAY_NAME}/mcp"
echo ${AGW_NAME}
echo ${AGW_URI}
echo ${RE_AGENT_NAME}
echo ${RE_AGENT_ID_SET}
echo ${STAGING_BUCKET}
echo ${MCP_NAME}
echo ${MCP_DISPLAY_NAME}
echo ${MCP_URL}

# create local dir for config files
mkdir -p cfg

Если вы используете самостоятельную установку Google Cloud SDK (т.е. вне Cloud Shell), обновите компоненты до последней версии.

# update gcloud cli
gcloud components update

Включить API-сервисы 

# enable google apis (agent platform bundle, part 1)
gcloud services enable \
  agentregistry.googleapis.com \
  aiplatform.googleapis.com \
  apphub.googleapis.com \
  apptopology.googleapis.com \
  cloudapiregistry.googleapis.com \
  cloudtrace.googleapis.com \
  compute.googleapis.com \
  dataform.googleapis.com \
  iam.googleapis.com \
  iamconnectors.googleapis.com \
  iap.googleapis.com \
  logging.googleapis.com \
  modelarmor.googleapis.com \
  monitoring.googleapis.com \
  networksecurity.googleapis.com \
  networkservices.googleapis.com \
  notebooks.googleapis.com \
  observability.googleapis.com

# enable google apis (agent platform bundle, part 2)
gcloud services enable \
  securitycenter.googleapis.com \
  saasservicemgmt.googleapis.com \
  storage.googleapis.com \
  telemetry.googleapis.com \
  texttospeech.googleapis.com

# enable google apis (all the rest)
gcloud services enable \
  run.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  dns.googleapis.com

На этом завершается этап настройки... далее переходим к разделу «Сеть» .

4. Сеть

Сеть VPC развертывается в пользовательском режиме для создания обычных подсетей , поддерживающих подключение к сети PSC для Agent Gateway и прямого исходящего трафика VPC в Cloud Run.

Конечная точка PSC для API Google развернута с использованием единого глобального внутреннего IPv4-адреса /32 для обеспечения частного внутреннего доступа к Cloud Run. Этот IP-адрес не назначается ни одной региональной подсети.

Создавайте сети

Создайте глобальную сеть VPC. 

# create vpc network
gcloud compute networks create vnet-${SLUG} --subnet-mode=custom

Создайте подсети для подключения к сети Agent Gateway PSC и прямого исходящего трафика VPC в Cloud Run. 

# create subnet for agent gateway psc na
gcloud compute networks subnets create subnet-${REGION}-agw \
  --network=vnet-${SLUG} \
  --range=192.168.10.0/28 \
  --region=${REGION} \
  --enable-private-ip-google-access

# create subnet for cloud run dvpc egress
gcloud compute networks subnets create subnet-${REGION}-crun \
  --network=vnet-${SLUG} \
  --range=10.10.10.0/24 \
  --region=${REGION} \
  --enable-private-ip-google-access

Создание правил брандмауэра

Создайте политику и правило брандмауэра, разрешающие весь исходящий трафик с включенным логированием. Это будет использоваться для мониторинга трафика, исходящего из Agent Gateway в сеть VPC. 

# create fw policy
gcloud compute network-firewall-policies create fw-policy-${SLUG} --global

# create fw policy rule
gcloud compute network-firewall-policies rules create 1001 \
  --description="allow all out and log" \
  --firewall-policy=fw-policy-${SLUG} \
  --global-firewall-policy \
  --action=allow \
  --direction=EGRESS \
  --layer4-configs=all \
  --dest-ip-ranges=0.0.0.0/0 \
  --enable-logging

# associate fw policy to vpc network
gcloud compute network-firewall-policies associations create \
  --name=fw-policy-bind-${SLUG} \
  --firewall-policy=fw-policy-${SLUG} \
  --network=vnet-${SLUG} \
  --global-firewall-policy

Создать сетевое подключение PSC

Создайте сетевое подключение PSC, настроенное на автоматическое принятие новых подключений от производителей. 

# create psc network attachment
gcloud compute network-attachments create psc-na-${REGION}-agw \
  --region=${REGION} \
  --subnets=subnet-${REGION}-agw \
  --connection-preference=ACCEPT_AUTOMATIC

Проверьте подключение к сети PSC. 

# show psc network attachment details
gcloud compute network-attachments describe psc-na-${REGION}-agw --region=${REGION}

# fetch psc na uri
export PSC_NA_URI=$(gcloud compute network-attachments describe psc-na-${REGION}-agw \
  --region=${REGION} \
  --format="value(selfLink.scope(v1))")
echo ${PSC_NA_URI}

Создать конечную точку PSC

Создайте резервирование IP-адреса для глобальной конечной точки PSC. Используемый здесь адрес не может принадлежать существующей подсети или совпадать с ней. 

# set env var for psc ep ip address
export PSC_EP_IP="240.0.0.10"
echo ${PSC_EP_IP}

# reserve internal global ipv4 address
gcloud compute addresses create ip-psc2gapis \
  --global \
  --purpose=PRIVATE_SERVICE_CONNECT \
  --addresses=${PSC_EP_IP} \
  --network=vnet-${SLUG}

Создайте конечную точку PSC для API Google, используя пакет all-apis , который включает Cloud Run ( run.app ). 

# create psc endpoint for google apis
gcloud compute forwarding-rules create psc2gapis \
  --global \
  --network=vnet-${SLUG} \
  --address=ip-psc2gapis \
  --target-google-apis-bundle=all-apis

Проверьте конечную точку PSC. 

# show psc endpoint details
gcloud compute forwarding-rules describe psc2gapis --global

Создайте зону DNS и записи.

Создайте частную зону управления Cloud DNS для домена run.app . 

# create private dns zone
gcloud dns managed-zones create priv-zone-run \
  --description="private zone for cloud run" \
  --dns-name="run.app." \
  --visibility=private \
  --networks=vnet-${SLUG}

Создайте запись DNS A с подстановочным знаком для *.run.app. , указывающую на IP-адрес конечной точки PSC. 

# create dns record
gcloud dns record-sets create *.run.app \
  --zone=priv-zone-run \
  --type=A \
  --ttl=300 \
  --rrdatas=${PSC_EP_IP}

Создайте политику Cloud DNS для включения регистрации DNS-запросов. 

# create dns policy (logging)
gcloud dns policies create dns-policy-${SLUG} \
  --description="dns logging for vnet-${SLUG}" \
  --networks=vnet-${SLUG} \
  --enable-logging

Создать облачный NAT

Создайте облачный маршрутизатор и облачный NAT для поддержки прямого исходящего трафика из VPC в Cloud Run, чтобы сервер MCP мог получать доступ к внешним данным о погоде через сеть VPC. 

# create router for nat
gcloud compute routers create cr-nat-${SLUG}-${REGION} \
  --network=vnet-${SLUG} \
  --asn=16550 \
  --region=${REGION}

# create nat gateway
gcloud compute routers nats create nat-${SLUG}-${REGION} \
  --router=cr-nat-${SLUG}-${REGION} \
  --region=${REGION} \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

На этом завершается раздел, посвященный сети... далее переходим к разделу «Шлюз» .

5. Шлюз

Перед применением контроля доступа разверните Agent Gateway и настройте расширение авторизации в режиме DRY_RUN . Это позволит успешно выполнять исходящие вызовы инструментов, одновременно регистрируя результаты оценки для целей аудита.

Здесь Agent Gateway использует региональный реестр для поддержки региональных ресурсов Agent Runtime и указывает поля networkConfig для подключения сети VPC, сети PSC и конфигурации DNS-пиринга.

Создать шлюз

# create new agent gateway config file (with network settings)
cat > cfg/${AGW_NAME}-networkConfig.yaml << EOF
name: ${AGW_NAME}
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
registries:
  - "//agentregistry.googleapis.com/projects/${PROJ_ID}/locations/${REGION}"
networkConfig:
  egress:
    networkAttachment: ${PSC_NA_URI}
  dnsPeeringConfig:
    domains:
      - run.app.
    targetProject: ${PROJ_ID}
    targetNetwork: projects/${PROJ_ID}/global/networks/vnet-${SLUG}
EOF

# import agent gateway config file (create gateway)
gcloud network-services agent-gateways import ${AGW_NAME} \
  --source="cfg/${AGW_NAME}-networkConfig.yaml" \
  --location=${REGION}

Проверьте шлюз 

# show agent gateway details
gcloud network-services agent-gateways describe ${AGW_NAME} \
  --location=${REGION}

# show psc network attachment details
gcloud compute network-attachments describe psc-na-${REGION}-agw --region=${REGION}

Убедитесь, что существует разрешенная точка подключения. 

connectionEndpoints:
- ipAddress: 192.168.10.2
  projectIdOrNum: '[AGW_PROJECT_NO]'
  status: ACCEPTED
  subnetwork: https://www.googleapis.com/compute/v1/projects/${PROJ_ID}/regions/${REGION}/subnetworks/subnet-${REGION}-agw

На этом завершается раздел, посвященный шлюзу... далее переходим к разделу «Авторизация» .

6. Авторизация

Расширение авторизации Agent Gateway для Identity-Aware Proxy (IAP) — это тип расширения службы , используемый для делегирования решений по авторизации для всех коммуникаций Agent Platform .

  1. Процесс делегирования: Когда агент пытается вызвать внешнюю конечную точку или сервер MCP, он перенаправляет запрос в Agent Gateway. Вместо локальной оценки доступа шлюз использует расширение авторизации для отправки вызова в службу оценки IAP. IAP оценивает идентификатор агента ( на основе SPIFFE ) в соответствии с политикой IAM целевого ресурса в реестре агентов. IAP возвращает шлюзу решение ALLOW или DENY , после чего шлюз либо перенаправляет трафик дальше, либо блокирует его с кодом состояния HTTP 403 Forbidden .
  2. Режимы принудительного применения: В режиме DRY_RUN IAP оценивает запросы и регистрирует решения в Cloud Logging, не блокируя трафик. В режиме ENFORCE любой запрос от неавторизованного агента или к незарегистрированному целевому объекту немедленно блокируется.
  3. Уровень привязки: Расширение сервиса подключается к Agent Gateway с помощью политики авторизации , настроенной с использованием профиля REQUEST_AUTHZ .

Расширение авторизации

Расширение авторизации указывает службу поставщика безопасности с настройками подключения и другими параметрами, определяющими, как служба будет работать и интегрироваться с Agent Gateway.

Создать расширение авторизации 

# create authz extension config file (dry run mode)
cat > cfg/${AGW_NAME}-svc-ext-authz-iap-dryrun.yaml << EOF
name: ${AGW_NAME}-svc-ext-authz-iap-dryrun
service: iap.googleapis.com
failOpen: true
timeout: 1s
metadata:
  iamEnforcementMode: "DRY_RUN"
  iapPolicyVersion: "V1"
EOF

Импорт расширения авторизации 

# import authz extension file (create extension)
gcloud service-extensions authz-extensions import ${AGW_NAME}-svc-ext-authz-iap-dryrun \
  --source=cfg/${AGW_NAME}-svc-ext-authz-iap-dryrun.yaml \
  --location=${REGION}

Проверить расширение авторизации 

# show authz extension details
gcloud service-extensions authz-extensions describe ${AGW_NAME}-svc-ext-authz-iap-dryrun \
  --location=${REGION}

Политика авторизации

Политика авторизации привязывает поставщика безопасности (IAP) к целевому ресурсу шлюза и определяет профиль перехвата ( REQUEST_AUTHZ ).

Создать политику авторизации 

# create authz policy config file (attach dry-run authz extension)
cat > cfg/${AGW_NAME}-authz-policy-profile-iap.yaml << EOF
name: ${AGW_NAME}-authz-policy-profile-iap
target:
  resources:
    - "projects/${PROJ_ID}/locations/${REGION}/agentGateways/${AGW_NAME}"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/${PROJ_ID}/locations/${REGION}/authzExtensions/${AGW_NAME}-svc-ext-authz-iap-dryrun"
EOF

Политика авторизации привязки 

# import authz policy config file (enable authz policy)
gcloud beta network-security authz-policies import ${AGW_NAME}-authz-policy-profile-iap \
  --source=cfg/${AGW_NAME}-authz-policy-profile-iap.yaml \
  --location=${REGION}

Проверить политику авторизации 

# show authz policy details
gcloud beta network-security authz-policies describe ${AGW_NAME}-authz-policy-profile-iap \
  --location=${REGION}

На этом завершается раздел, посвященный авторизации... далее переходим к разделу «Кодовая база» .

7. Кодовая база

Код агента, сервера MCP и регистрации конечной точки, используемый в этом практическом занятии, хранится в удаленном репозитории Google Cloud GitHub . Следующие шаги клонируют репозиторий локально, скопируют необходимые файлы в текущую структуру рабочих каталогов, а затем очистят временные файлы.

Для загрузки, сборки и развертывания упакованного кода приложения агента и артефактов его зависимостей создается промежуточное хранилище.

Получение удаленных артефактов 

# clone remote repository to temp local dir
git clone https://github.com/GoogleCloudPlatform/cloud-networking-solutions.git ./temp_agw_cuj_arun_egress_vpc

# copy agent runtime and endpoint definitions to working project dir
cp -r temp_agw_cuj_arun_egress_vpc/codelabs/agw-cuj-arun-egress-vpc/agent-weather ./agent-weather
cp -r temp_agw_cuj_arun_egress_vpc/codelabs/agw-cuj-arun-egress-vpc/mcp-weather ./mcp-weather

# remove temporary directory
rm -rf temp_agw_cuj_arun_egress_vpc

Создать временный контейнер 

# create storage bucket for agent deployment artifacts
gcloud storage buckets create gs://${STAGING_BUCKET} --location=${REGION}

# verify staging bucket url
gcloud storage buckets list --format="value(storage_url)"

На этом завершается раздел, посвященный коду... далее переходим к разделу «Реестр» .

8. Реестр

Реестр агентов представляет собой централизованный каталог всех агентов, серверов MCP и конечных точек (API) в экосистеме ИИ. Он также служит каталогом, позволяющим перечислять, искать и находить другие зарегистрированные инструменты и сервисы для использования приложениями ИИ. Agent Gateway использует модель данных реестра в качестве основы управления для обеспечения контроля доступа к исходящему трафику. Предоставление ролей IAM для вызывающих агентов проверяется на соответствие политике, привязанной к ресурсу реестра.

Для инициализации среды и поддержки агента при использовании различных API и сервисов Google создайте единую конечную точку реестра, которая объединяет основные интерфейсы API, необходимые для этой лабораторной работы. Это упростит управление политиками управления для распространенных наборов инструментов, которые будут использовать большинство агентов.

Регистрация конечных точек 

# create endpoint service (with multiple entries)
gcloud agent-registry services create core-gapi-services \
  --location=${REGION} \
  --display-name="gapi.core.services" \
  --description="core apis and services" \
  --endpoint-spec-type=no-spec \
  --interfaces=protocolBinding=JSONRPC,url=https://telemetry.googleapis.com \
  --interfaces=protocolBinding=JSONRPC,url=https://${REGION}-aiplatform.googleapis.com \
  --interfaces=protocolBinding=JSONRPC,url=https://cloudresourcemanager.googleapis.com \
  --interfaces=protocolBinding=JSONRPC,url=https://iamcredentials.googleapis.com

Проверка регистрации конечной точки 

# list registry regional endpoints
gcloud agent-registry endpoints list --location=${REGION} \
  --flatten="interfaces[]" \
  --format="table(displayName, name.basename():label=ENDPOINT_ID, interfaces.url:label=URL)"

На этом завершается раздел, посвященный реестру... далее переходим к разделу, посвященному серверу MCP .

9. Сервер MCP

Предоставьте IAM разрешения для развертывания.

Предоставьте учетной записи вычислительной службы по умолчанию необходимые разрешения для поддержки развертывания служб Cloud Run из исходного кода. 

# grant cloud run builder role to default compute sa
gcloud projects add-iam-policy-binding ${PROJ_ID} \
  --member="serviceAccount:${PROJ_NO}-compute@developer.gserviceaccount.com" \
  --role="roles/run.builder"

Проверьте права доступа IAM. 

# show iam policy on project for default compute sa
gcloud projects get-iam-policy ${PROJ_ID} \
  --flatten="bindings[].members" \
  --filter="bindings.members=serviceAccount:${PROJ_NO}-compute@developer.gserviceaccount.com" \
  --format="table(bindings.role:label=ROLE, bindings.members:label=PRINCIPAL_IDENTITY)"

Развернуть сервер MCP 

# deploy cloud run service
gcloud -q run deploy ${MCP_NAME} \
  --source=mcp-weather/server \
  --region=${REGION} \
  --no-allow-unauthenticated \
  --min-instances=1 \
  --network=vnet-${SLUG} \
  --subnet=subnet-${REGION}-crun \
  --vpc-egress=all-traffic \
  --startup-probe=httpGet.path=/warmup

Предоставьте IAM разрешения для входящего трафика.

Политика привязки для доступа пользователей

Предоставьте учетной записи пользователя (self) права на вызов размещенного в Cloud Run сервера MCP. Это необходимо для запуска скрипта генерации toolspec . 

# grant run invoker role to user account on cloud run service level
gcloud run services add-iam-policy-binding ${MCP_NAME} \
  --region=${REGION} \
  --member="user:${USER_IDENTITY}" \
  --role="roles/run.invoker"

Проверьте права доступа IAM. 

# show iam policy on cloud run service for invoker role
gcloud run services get-iam-policy ${MCP_NAME} \
  --region=${REGION} \
  --flatten="bindings[].members" \
  --filter="bindings.role=roles/run.invoker" \
  --format="table(bindings.members:label=PRINCIPAL_IDENTITY, bindings.role:label=ROLE)"

Создайте пользовательское SA для вызова MCP.

Создайте пользовательскую учетную запись службы для вызова сервера MCP, размещенного в Cloud Run. Эта учетная запись службы будет использоваться агентом для получения действительного токена OIDC ID, подписанного Google, для доступа к Cloud Run. 

# create custom sa for mcp server invocation
gcloud iam service-accounts create sa-${MCP_NAME}-invoker \
  --display-name="custom sa to invoke ${MCP_NAME}"

# set env var for service account identity
export MCP_INVOKER_SA="sa-${MCP_NAME}-invoker@${PROJ_ID}.iam.gserviceaccount.com"
echo ${MCP_INVOKER_SA}

Политика привязки для учетной записи службы 

# grant run invoker role to custom sa on cloud run service level
gcloud run services add-iam-policy-binding ${MCP_NAME} \
  --role="roles/run.invoker" \
  --member="serviceAccount:${MCP_INVOKER_SA}" \
  --region=${REGION}

Проверьте права доступа IAM. 

# show iam policy on cloud run service for invoker role
gcloud run services get-iam-policy ${MCP_NAME} \
  --region=${REGION} \
  --flatten="bindings[].members" \
  --filter="bindings.role=roles/run.invoker" \
  --format="table(bindings.members:label=PRINCIPAL_IDENTITY, bindings.role:label=ROLE)"

Предоставьте IAM разрешения для аутентификации.

Предоставьте учетной записи службы роли для имитации учетной записи вычислительной службы по умолчанию . Это позволит агенту, работающему под учетными данными приложения по умолчанию (ADC), создавать токены OIDC ID, подписанные Google, от имени пользовательской учетной записи службы-вызывающего пользователя для аутентификации вызовов к Cloud Run.

Политика привязки для аутентификации 

# grant oidc token creator role to default compute service account
gcloud iam service-accounts add-iam-policy-binding ${MCP_INVOKER_SA} \
  --role="roles/iam.serviceAccountOpenIdTokenCreator" \
  --member="serviceAccount:${PROJ_NO}-compute@developer.gserviceaccount.com"

# grant service account token creator role to default compute service account
gcloud iam service-accounts add-iam-policy-binding ${MCP_INVOKER_SA} \
  --role="roles/iam.serviceAccountTokenCreator" \
  --member="serviceAccount:${PROJ_NO}-compute@developer.gserviceaccount.com"

Проверьте права доступа IAM. 

# show iam policy for the custom service account
gcloud iam service-accounts get-iam-policy ${MCP_INVOKER_SA} \
  --flatten="bindings[].members" \
  --format="table(bindings.role:label=ROLE, bindings.members:label=PRINCIPAL_IDENTITY)"

Создать toolspec MCP

При ручной регистрации сервера MCP необходимо включить файл спецификации инструментов. Файл toolspec.json содержит список всех инструментов, предоставляемых сервером MCP, и позволяет другим пользователям обнаружить их после регистрации.

Скрипт test_mcp.py , входящий в состав кода mcp-weather/ , генерирует файл toolspec.json , подключаясь к целевому MCP-серверу (через SSE или HTTP) и вызывая функцию list_tools() для получения всех доступных инструментов, предоставляемых сервером. 

# fetch oidc token for cloud run authentication
export OIDC_TOKEN=$(gcloud auth print-identity-token)

# generate toolspec for registry ingestion
uv --directory mcp-weather run test_mcp.py --toolspec=include --token="${OIDC_TOKEN}"

Анализ сгенерированного toolspec показывает, какие атрибуты MCP может использовать Agent Gateway для оценки и применения политик исходящего трафика.

Проверьте toolspec MCP. 

# show toolspec mcp attributes
jq '.tools[] | {name, isReadOnly, isDestructive, isIdempotent, isOpenWorld}' mcp-weather/toolspec.json

Обновите входной поток Cloud Run

Измените настройки входящего трафика для сервиса Cloud Run таким образом, чтобы он принимал входящие запросы только из сети VPC. Это предотвратит прямой публичный доступ к конечной точке MCP и позволит использовать её только внутренним ресурсам. Трафик, предназначенный для конечной точки PSC для API Google в сети VPC, будет считаться внутренним входящим трафиком и будет разрешен.

# update cloud run service config
gcloud run services update ${MCP_NAME} \
  --region=${REGION} \
  --ingress=internal

Проверьте входящий трафик Cloud Run. 

# show cloud run service details
gcloud run services describe ${MCP_NAME} --region=${REGION} | grep -iE 'ingress|egress'

Зарегистрировать сервер MCP

Теперь, когда у вас есть toolspec , зарегистрируйте сервер MCP в региональном реестре агентов. 

# register mcp server
gcloud agent-registry services create ${MCP_NAME} \
  --location=${REGION} \
  --display-name="${MCP_DISPLAY_NAME}" \
  --description="mcp server for weather info" \
  --mcp-server-spec-type=tool-spec \
  --mcp-server-spec-content=mcp-weather/toolspec.json \
  --interfaces=url=${MCP_URL},protocolBinding=JSONRPC

Подтвердите регистрацию MCP. 

# list registry regional mcp servers
gcloud agent-registry mcp-servers list --location=${REGION} --format="table(displayName, interfaces.url)"

# show mcp server registry details
gcloud agent-registry services describe ${MCP_NAME} --location=${REGION}

# fetch mcp server registry id
export MCP_REGISTRY_ID=$(gcloud agent-registry services describe ${MCP_NAME} \
  --location=${REGION} \
  --format="value(registryResource.basename())")
echo ${MCP_REGISTRY_ID}

На этом завершается раздел, посвященный серверу MCP... далее переходим к разделу, посвященному агенту ADK .

10. Агент ADK

Агент agent-weather ADK, развернутый в Agent Runtime, настроен в скрипте развертывания со следующими параметрами для интеграции с Agent Platform:

  • "identity_type": types.IdentityType.AGENT_IDENTITY для предоставления уникального основного идентификатора на основе SPIFFE для агента
  • "agent_gateway_config": { "agent_to_anywhere_config": {"agent_gateway": } } для направления всего исходящего трафика, инициированного агентом, на Agent Gateway для оценки и применения политик.

Агент также настроен на использование сервера MCP путем передачи URL-адреса и учетной записи службы для получения токена идентификатора OIDC.

Развернуть агент 

# deploy agent runtime workload
uv --directory agent-weather run python3 deploy_agent.py \
  --project=${PROJ_ID} \
  --region=${REGION} \
  --src-dir=./agent \
  --staging-bucket=${STAGING_BUCKET} \
  --display-name="${RE_AGENT_NAME}" \
  --description="agent for weather info" \
  --mcp-server-url="${MCP_URL}" \
  --mcp-invoker-sa="${MCP_INVOKER_SA}" \
  --enable-telemetry \
  --enable-agent-identity \
  --agent-gateway-egress=${AGW_URI} \
  --allow-token-sharing

Проверка развертывания

Получение основных параметров развертывания 

# fetch agent runtime resource (reasoning engine) id
export RE_ENGINE_ID=$(curl -s -X GET "https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJ_ID}/locations/${REGION}/reasoningEngines" \
  -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" | \
  jq -r --arg name "${RE_AGENT_NAME}" '.reasoningEngines[] | select(.displayName==$name) | .name | split("/") | last')
echo ${RE_ENGINE_ID}

# fetch agent runtime (reasoning engine) agent identity
export RE_AGENT_IDENTITY=$(gcloud agent-registry agents list \
  --location=${REGION} --filter="displayName=${RE_AGENT_NAME}" \
  --format="value(attributes.'agentregistry.googleapis.com/system/RuntimeIdentity'.principal)")
echo ${RE_AGENT_IDENTITY}

# fetch agent registry uid for agent
export RE_AGENT_REGISTRY_ID=$(gcloud agent-registry agents list \
  --location=${REGION} \
  --filter="displayName=${RE_AGENT_NAME}" \
  --format="value(uid)")
echo ${RE_AGENT_REGISTRY_ID}

Проверьте запись в реестре. 

# show agent resource registry details
gcloud agent-registry agents describe ${RE_AGENT_REGISTRY_ID} --location=${REGION}

Проверьте конфигурацию шлюза. 

# show agent config details (gateway config)
curl -s -X GET "https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJ_ID}/locations/${REGION}/reasoningEngines/${RE_ENGINE_ID}" \
  -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
  | jq '{displayName: .displayName, name: .name, effectiveIdentity: .spec.effectiveIdentity, agentGatewayConfig: .spec.deploymentSpec.agentGatewayConfig}'

Предоставьте IAM разрешения для аутентификации.

Когда агент настроен на использование Agent Identity , он получает токен (в формате JWT-SVID) от федеративной службы токенов безопасности (STS), подписанный sts.googleapis.com (поставщиком идентификационных данных SPIFFE).

Однако встроенная проверка вызывающего объекта Cloud Run IAM доверяет и может проверять только стандартные токены OIDC ID, подписанные основным эмитентом OIDC от Google ( accounts.google.com ).

Таким образом, для обмена федеративного токена STS (JWT-SVID), полученного с помощью идентификатора агента, на стандартный токен Google (OIDC), полученный с помощью имитации учетной записи службы во время выполнения, используется пользовательская учетная запись службы.

Создайте необходимые привязки ролей для пользовательской учетной записи службы.

Политика привязки для аутентификации (имитации личности) 

# grant service account token creator role to agent principal identity
gcloud iam service-accounts add-iam-policy-binding ${MCP_INVOKER_SA} \
  --role="roles/iam.serviceAccountTokenCreator" \
  --member="${RE_AGENT_IDENTITY}"

# grant service account openid token creator role to agent principal identity
gcloud iam service-accounts add-iam-policy-binding ${MCP_INVOKER_SA} \
  --role="roles/iam.serviceAccountOpenIdTokenCreator" \
  --member="${RE_AGENT_IDENTITY}"

Проверьте права доступа IAM. 

# show iam policy for custom service account
gcloud iam service-accounts get-iam-policy ${MCP_INVOKER_SA} \
  --flatten="bindings[].members" \
  --format="table(bindings.members.sub('^.*locations/', '.../locations/'):label=PRINCIPAL_IDENTITY, bindings.role:label=ROLE)"

Предоставьте IAM-права для среды выполнения.

Предоставление разрешений IAM для выполнения позволяет агенту получать доступ к сервисам платформы ИИ и другим основным API и сервисам Google, используя свою идентификацию основного агента на основе SPIFFE . Эти политики применяются с помощью IAM на уровне ресурсов .

Создайте необходимые привязки ролей для идентификации агента.

Привязывайте политики для доступа агентов. 

# grant ai platform user role
gcloud projects add-iam-policy-binding ${PROJ_ID} \
  --member="${RE_AGENT_IDENTITY}" \
  --role="roles/aiplatform.user"

# grant agent default access role
gcloud projects add-iam-policy-binding ${PROJ_ID} \
  --member="${RE_AGENT_IDENTITY}" \
  --role="roles/aiplatform.agentDefaultAccess"

# grant agent registry viewer role
gcloud projects add-iam-policy-binding ${PROJ_ID} \
  --member="${RE_AGENT_IDENTITY}" \
  --role="roles/agentregistry.viewer"

# grant cloud logging writer role
gcloud projects add-iam-policy-binding ${PROJ_ID} \
  --member="${RE_AGENT_IDENTITY}" \
  --role="roles/logging.logWriter"

# grant cloud monitoring writer role
gcloud projects add-iam-policy-binding ${PROJ_ID} \
  --member="${RE_AGENT_IDENTITY}" \
  --role="roles/monitoring.metricWriter"

# grant browser role for resource manager lookup
gcloud projects add-iam-policy-binding ${PROJ_ID} \
  --member="${RE_AGENT_IDENTITY}" \
  --role="roles/browser"

Проверьте права доступа IAM. 

# show iam policy on project for agent identity
gcloud projects get-iam-policy ${PROJ_ID} \
  --flatten="bindings[].members" \
  --filter="bindings.members:${RE_AGENT_IDENTITY}" \
  --format="table(bindings.members.sub('^.*locations/', '.../locations/'):label=PRINCIPAL_IDENTITY, bindings.role:label=ROLE)"

На этом завершается раздел, посвященный агентам ADK... далее переходим к разделу «Политики» .

11. Политика

Политики авторизации управления агентом позволяют направлять трафик от агента ИИ через Agent Gateway к конечному целевому ресурсу (например, к частной конечной точке сервера MCP для получения данных). После достижения пункта назначения доступ к данным предоставляется на основе стандартных разрешений уровня службы или приложения.

Предоставление ролей IAM для исходящего трафика Agent Gateway включает политики доступа, которые позволяют субъекту-агенту получать доступ к зарегистрированным целевым ресурсам через Agent Gateway. Политики применяются на уровне Agent Gateway и проверяются с помощью политик IAM Identity-Aware Proxy (IAP).

Предоставьте роли IAM для исходящего трафика Agent Gateway.

Agent Gateway проверяет входящие запросы, чтобы убедиться, что у вызывающего агента есть разрешение iap.webServiceVersions.egressViaIAP (предоставляемое ролью roles/iap.egressor ) на целевой ресурс.

Предоставление roles/iap.egressor идентификатору агента или набору субъектов среды выполнения агента для выбранного целевого ресурса разрешает исходящий трафик. В этом практическом задании роль применяется к основному агенту , предоставляя разрешение конкретному идентификатору агента среды выполнения агента.

Политики IAM привязаны к целевым ресурсам, определенным в модели данных Agent Registry. Ресурс iap_web/agentRegistry представляет собой уровень в иерархии IAM , охватывающий весь реестр . agentRegistry служит родительским ресурсом для отдельных дочерних ресурсов для agents , mcpServers и endpoints . В этом практическом задании политика IAM привязана к уровням mcpServer и конечных точек , которые применяют разрешения к конкретным дочерним ресурсам.

Настройка политики агента для сервера MCP.

Создание политики для агента на сервере MCP. 

# fetch active etag on policy for mcp server
export IAP_ETAG=$(gcloud beta iap web get-iam-policy \
  --resource-type=agent-registry --region=${REGION} \
  --mcp-server=${MCP_REGISTRY_ID} --format="value(etag)")
echo ${IAP_ETAG}

ПРИМЕЧАНИЕ: etag: должен возвращать ACAB по умолчанию, поскольку политики еще не определены. 

# create policy config file
cat > cfg/iap-policy-agent-to-mcp.json << EOF
{
  "bindings": [
    {
      "role": "roles/iap.egressor",
      "members": [
        "${RE_AGENT_IDENTITY}"
      ]
    }
  ],
  "etag": "${IAP_ETAG}"
}
EOF

Политика привязки агента к MCP-серверу 

# import policy file
gcloud beta iap web set-iam-policy cfg/iap-policy-agent-to-mcp.json \
  --resource-type=agent-registry \
  --mcp-server=${MCP_REGISTRY_ID} \
  --region=${REGION}

Проверьте права доступа IAM. 

# show iap iam policy on mcp server for agent
gcloud beta iap web get-iam-policy \
  --region=${REGION} \
  --resource-type=agent-registry \
  --mcp-server=${MCP_REGISTRY_ID}

На этом завершается раздел, посвященный политике компании... далее переходим к разделу «Аудит» .

12. Аудит

Расширение авторизации Agent Gateway работает в режиме DRY_RUN . Исходящие запросы отслеживаются и регистрируются, но не блокируются. Анализ журналов перед переключением в режим ENFORCED позволит подтвердить, какие политики необходимо настроить для разрешения целевого трафика.

Запросы тестового агента

Откройте окно браузера с пользовательским интерфейсом консоли Google Cloud и перейдите по следующей ссылке:

  • Платформа агентов → Агенты → Развертывания → agent-weather
  • Выберите вкладку «Игровая площадка» .

Или введите эту команду в терминале и щелкните ссылку, чтобы перейти к среде разработки агента: 

# playground
echo "https://console.cloud.google.com/agent-platform/runtimes/locations/${REGION}/agent-engines/${RE_ENGINE_ID}/playground?project=${PROJ_ID}"

Отправьте несколько тестовых запросов...

  • What is the weather like in London?
  • How warm is it in New York?

Убедитесь, что запросы возвращают корректные ответы.

Анализ журналов аудита

Просмотрите журналы и изучите результаты оценки политики в ходе пробного запуска. 

# show gateway logs for endpoints and authz status (duplicates removed)
gcloud logging read \
  "resource.type=\"networkservices.googleapis.com/Gateway\" \
  AND httpRequest.requestUrl:*" \
  --project=${PROJ_ID} \
  --limit=50 \
  --freshness=24h \
  --format="table( \
    timestamp.date(tz=LOCAL):label=TIMESTAMP, \
    httpRequest.status:label=STATUS, \
    jsonPayload.authzPolicyInfo.result:label=AUTHZ, \
    httpRequest.requestUrl.sub('(https?://[^/:]+).*', '\1'):label=ENDPOINT \
  )" | awk 'NR==1 {print; next} ! seen[$2,$3,$4]++'

TIMESTAMP            STATUS  AUTHZ    ENDPOINT
YYYY-MM-DDTHH:MM:SS  200     ALLOWED  https://cloudresourcemanager.googleapis.com
YYYY-MM-DDTHH:MM:SS  200     ALLOWED  https://${REGION}-aiplatform.googleapis.com
YYYY-MM-DDTHH:MM:SS  200     ALLOWED  https://iamcredentials.googleapis.com
YYYY-MM-DDTHH:MM:SS  200     ALLOWED  https://mcp-weather-${PROJ_NO}.${REGION}.run.app
YYYY-MM-DDTHH:MM:SS  200     ALLOWED  https://telemetry.googleapis.com
YYYY-MM-DDTHH:MM:SS  202     ALLOWED  https://mcp-weather-${PROJ_NO}.${REGION}.run.app

Настройка политики агента для конечных точек

Поскольку основные API Google для agent-weather были зарегистрированы в реестре в рамках коллективной службы конечных точек ( gapi.core.services ), для предоставления агенту разрешений на исходящий трафик для доступа к конечным точкам требуется всего одна политика.

Создайте политику для агента, устанавливающую соединение с конечной точкой. 

# set var for endpoint display name
export ENDPOINT_DISPLAY_NAME="gapi.core.services"
echo ${ENDPOINT_DISPLAY_NAME}

# fetch endpoint registry id
export ENDPOINT_REGISTRY_ID=$(gcloud agent-registry services list \
  --location=${REGION} \
  --filter="displayName=${ENDPOINT_DISPLAY_NAME}" \
  --format="value(registryResource.basename())")
echo ${ENDPOINT_REGISTRY_ID}

# create policy config file
cat > cfg/iap-policy-agent-to-ep.json << EOF
{
  "bindings": [
    {
      "role": "roles/iap.egressor",
      "members": [
        "${RE_AGENT_IDENTITY}"
      ]
    }
  ]
}
EOF

Политика привязки агента к конечной точке 

# import policy file (bind iam policy)
gcloud -q beta iap web set-iam-policy cfg/iap-policy-agent-to-ep.json \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_REGISTRY_ID} \
  --region=${REGION}

Проверьте права доступа IAM. 

# show iap iam policy on endpoint for agent
gcloud beta iap web get-iam-policy \
  --region=${REGION} \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_REGISTRY_ID}

На этом завершается раздел аудита... далее переходим к разделу «Принудительное исполнение» .

13. Принудить к исполнению

Агент смог успешно отправлять запросы через шлюз в режиме DRY_RUN . Журналы доступа и конечные точки были проанализированы для создания набора политик управления, разрешающих необходимый исходящий трафик от агента. Теперь переведите расширение авторизации IAP шлюза агента в режим ENFORCE , обновив политику авторизации.

Обновить расширение авторизации

Создать расширение авторизации 

# create authz extension config file (enforced mode)
cat > cfg/${AGW_NAME}-svc-ext-authz-iap-enforced.yaml << EOF
name: ${AGW_NAME}-svc-ext-authz-iap-enforced
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V1"
EOF

Импорт расширения авторизации 

# import authz extension file (create extension)
gcloud service-extensions authz-extensions import ${AGW_NAME}-svc-ext-authz-iap-enforced \
  --source=cfg/${AGW_NAME}-svc-ext-authz-iap-enforced.yaml \
  --location=${REGION}

Проверить расширение авторизации 

# list authz extensions (imported configs)
gcloud service-extensions authz-extensions list --location=${REGION}

Обновить политику авторизации

Создать политику авторизации 

# re-write authz policy config file (pointing to enforced authz extension)
cat > cfg/${AGW_NAME}-authz-policy-profile-iap.yaml << EOF
name: ${AGW_NAME}-authz-policy-profile-iap
target:
  resources:
    - "projects/${PROJ_ID}/locations/${REGION}/agentGateways/${AGW_NAME}"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/${PROJ_ID}/locations/${REGION}/authzExtensions/${AGW_NAME}-svc-ext-authz-iap-enforced"
EOF

Политика авторизации привязки 

# import authz policy config file (enable new authz policy)
gcloud beta network-security authz-policies import ${AGW_NAME}-authz-policy-profile-iap \
  --source=cfg/${AGW_NAME}-authz-policy-profile-iap.yaml \
  --location=${REGION}

Проверить политику авторизации 

# show authz policy details (verify enforced mode)
gcloud beta network-security authz-policies describe ${AGW_NAME}-authz-policy-profile-iap \
  --location=${REGION}

Проверка соблюдения законодательства

Вернитесь в среду разработки агентов в консольном интерфейсе.

  • Нажмите кнопку « + Новая сессия », чтобы создать новую сессию чата.

Отправьте дополнительный тестовый запрос...

  • What is the current temperature in Los Angeles?

Обратите внимание, что запросы агента к базовой модели Gemini ( ${REGION}-aiplatform.googleapis.com/... ) и конечной точке сервера MCP ( mcp-weather-${PROJ_NO}.${REGION}.run.app/mcp ) передаются со статусом HTTP 200 OK .

Анализ журналов шлюза 

# show gateway logs for http requests
gcloud logging read \
  "resource.type=\"networkservices.googleapis.com/Gateway\" \
  AND httpRequest.requestUrl:*" \
  --project=${PROJ_ID} \
  --limit=10 \
  --format="table(
    timestamp.date(tz=LOCAL):label=TIMESTAMP,
    httpRequest.requestMethod:label=METHOD,
    httpRequest.status:label=STATUS,
    jsonPayload.authzPolicyInfo.result:label=IAP_AUTHZ,
    jsonPayload.agentGatewayInfo.mcpInfo.method:label=MCP_METHOD,
    httpRequest.requestUrl:label=URL)"

Убедитесь, что никакие запросы не блокируются. Найдите в журналах аудита шлюза любые отклоненные исходящие попытки с кодом состояния HTTP 403 Forbidden . 

# show gateway logs for authz denies
gcloud logging read \
  "resource.type=\"networkservices.googleapis.com/Gateway\" \
  AND (jsonPayload.authzPolicyInfo.result=\"DENIED\" OR httpRequest.status=403)" \
  --project=${PROJ_ID} \
  --limit=10 \
  --format="table(
    timestamp.date(tz=LOCAL):label=TIMESTAMP,
    httpRequest.requestMethod:label=METHOD,
    httpRequest.status:label=STATUS,
    jsonPayload.enforcedGatewaySecurityPolicy.serverNameIndication:label=SNI,
    jsonPayload.authzPolicyInfo.result:label=AUTHZ_RESULT,
    jsonPayload.authzPolicyInfo.policies[0].name.basename():label=DENYING_POLICY
  )"

Просмотрите журналы Agent Gateway MCP и обратите внимание на то, как проверяется полезная нагрузка приложения MCP (JSON-RPC) для получения метаданных протокола, включая информацию о том, какие инструменты выполняются. 

# show gateway logs for mcp requests with method and tool name
gcloud logging read \
  "resource.type=\"networkservices.googleapis.com/Gateway\" \
  AND jsonPayload.agentGatewayInfo.mcpInfo.method:*" \
  --project=${PROJ_ID} \
  --limit=10 \
  --format="table(
    timestamp.date(tz=LOCAL):label=TIMESTAMP,
    httpRequest.status:label=STATUS,
    jsonPayload.authzPolicyInfo.result:label=IAP_AUTHZ,
    jsonPayload.agentGatewayInfo.mcpInfo.method:label=MCP_METHOD,
    jsonPayload.agentGatewayInfo.mcpInfo.parameter:label=TOOL_NAME,
    httpRequest.requestUrl:label=URL
  )"

Анализ журналов брандмауэра

Просмотрите журналы для правила политики сетевого брандмауэра с приоритетом 1001 . 

# show firewall logs for rule 1001
gcloud logging read \
  "jsonPayload.rule_details.priority=1001" \
  --project=${PROJ_ID} \
  --limit=10 \
  --format="table(
    timestamp.date(tz=LOCAL):label=TIMESTAMP,
    jsonPayload.disposition:label=ACTION,
    jsonPayload.connection.src_ip:label=SRC_IP,
    jsonPayload.connection.dest_ip:label=DEST_IP,
    jsonPayload.connection.dest_port:label=DEST_PORT,
    jsonPayload.vpc.subnetwork_name:label=SUBNET
  )"

Обратите внимание на представление различных маршрутов трафика на уровне сети:

  • Agent Gateway взаимодействует с внутренними сетевыми ресурсами VPC, используя subnet-${REGION}-agw
  • Сервер MCP, размещенный в Cloud Run, выполняет вызовы к внешним API погоды, используя subnet-${REGION}-crun 
TIMESTAMP            ACTION   SRC_IP        DEST_IP        DEST_PORT  SUBNET
YYYY-MM-DDTHH:MM:SS  ALLOWED  10.10.10.16   188.40.99.226  443        subnet-${REGION}-crun
YYYY-MM-DDTHH:MM:SS  ALLOWED  10.10.10.16   202.61.206.6   443        subnet-${REGION}-crun
YYYY-MM-DDTHH:MM:SS  ALLOWED  10.10.10.16   188.40.99.226  443        subnet-${REGION}-crun
YYYY-MM-DDTHH:MM:SS  ALLOWED  10.10.10.16   202.61.206.6   443        subnet-${REGION}-crun
YYYY-MM-DDTHH:MM:SS  ALLOWED  10.10.10.16   202.61.206.6   443        subnet-${REGION}-crun
YYYY-MM-DDTHH:MM:SS  ALLOWED  10.10.10.16   202.61.206.6   443        subnet-${REGION}-crun
YYYY-MM-DDTHH:MM:SS  ALLOWED  192.168.10.2  240.0.0.10     443        subnet-${REGION}-agw
YYYY-MM-DDTHH:MM:SS  ALLOWED  192.168.10.2  240.0.0.10     443        subnet-${REGION}-agw
YYYY-MM-DDTHH:MM:SS  ALLOWED  192.168.10.2  240.0.0.10     443        subnet-${REGION}-agw

Анализ журналов DNS

Просмотрите журналы DNS-запросов, разрешенных частной DNS-зоной ( priv-zone-run ). 

gcloud logging read \
  "resource.type=\"dns_query\" AND resource.labels.target_name=\"priv-zone-run\"" \
  --project=${PROJ_ID} \
  --limit=10 \
  --format="table(
    timestamp.date(tz=LOCAL):label=TIMESTAMP,
    jsonPayload.queryName:label=QUERY_NAME,
    jsonPayload.queryType:label=TYPE,
    jsonPayload.rdata:label=RESPONSE_RDATA,
    jsonPayload.sourceNetwork:label=NETWORK,
    resource.labels.source_type:label=SRC_TYPE
  )"

Обратите внимание, что DNS-запросы для сервиса Cloud Run ( mcp-weather...run.app ) выполняются из сети VPC с использованием DNS-пиринга и успешно разрешаются во внутреннюю конечную точку PSC для API Google ( 240.0.0.10 ). 

TIMESTAMP            QUERY_NAME                                     TYPE  RESPONSE_RDATA                                                     NETWORK   SRC_TYPE
YYYY-MM-DDTHH:MM:SS  mcp-weather-${PROJ_NO}.${REGION}.run.app.  A     mcp-weather-${PROJ_NO}.${REGION}.run.app. 300     IN      a       240.0.0.10  vnet-${SLUG}  peering-zone
YYYY-MM-DDTHH:MM:SS  mcp-weather-${PROJ_NO}.${REGION}.run.app.  A     mcp-weather-${PROJ_NO}.${REGION}.run.app. 300     IN      a       240.0.0.10  vnet-${SLUG}  peering-zone
YYYY-MM-DDTHH:MM:SS  mcp-weather-${PROJ_NO}.${REGION}.run.app.  A     mcp-weather-${PROJ_NO}.${REGION}.run.app. 300     IN      a       240.0.0.10  vnet-${SLUG}  peering-zone
YYYY-MM-DDTHH:MM:SS  mcp-weather-${PROJ_NO}.${REGION}.run.app.  A     mcp-weather-${PROJ_NO}.${REGION}.run.app. 300     IN      a       240.0.0.10  vnet-${SLUG}  peering-zone

На этом завершается раздел, посвященный применению мер принуждения... далее переходим к разделу «Уборка» .

14. Уборка 

# delete agent runtime
curl -s -X DELETE "https://${REGION}-aiplatform.googleapis.com/v1/projects/${PROJ_ID}/locations/${REGION}/reasoningEngines/${RE_ENGINE_ID}?force=true" \
  -H "Authorization: Bearer $(gcloud auth application-default print-access-token)"

# next

# delete agent resources
gcloud -q storage rm --recursive gs://${STAGING_BUCKET}

for ROLE in \
  "roles/aiplatform.user" \
  "roles/aiplatform.agentDefaultAccess" \
  "roles/agentregistry.viewer" \
  "roles/logging.logWriter" \
  "roles/monitoring.metricWriter" \
  "roles/browser"; do
  gcloud -q projects remove-iam-policy-binding ${PROJ_ID} \
    --member="${RE_AGENT_IDENTITY}" \
    --role="${ROLE}"
done

# next

# delete mcp (cloud run) resources
gcloud -q projects remove-iam-policy-binding ${PROJ_ID} \
  --member="serviceAccount:${PROJ_NO}-compute@developer.gserviceaccount.com" \
  --role="roles/run.builder"

gcloud -q run services delete ${MCP_NAME} --region=${REGION}

gcloud -q artifacts repositories delete cloud-run-source-deploy --location=${REGION}

gcloud -q iam service-accounts delete sa-${MCP_NAME}-invoker@${PROJ_ID}.iam.gserviceaccount.com

gcloud -q agent-registry services delete ${MCP_NAME} --location=${REGION}

# next

# delete gateway resources (policy binding must be deleted synchronously first)
gcloud -q beta network-security authz-policies delete ${AGW_NAME}-authz-policy-profile-iap --location=${REGION}

gcloud -q beta service-extensions authz-extensions delete ${AGW_NAME}-svc-ext-authz-iap-dryrun --location=${REGION} --async

gcloud -q beta service-extensions authz-extensions delete ${AGW_NAME}-svc-ext-authz-iap-enforced --location=${REGION} --async

gcloud -q network-services agent-gateways delete ${AGW_NAME} --location=${REGION} --async

# next

# remove policies
export IAP_ETAG=$(gcloud beta iap web get-iam-policy --resource-type=agent-registry --endpoint=${ENDPOINT_REGISTRY_ID} --region=${REGION} --format="value(etag)")
cat > cfg/iap-policy-empty.json << EOF
{
  "bindings": [],
  "etag": "${IAP_ETAG}"
}
EOF

gcloud -q beta iap web set-iam-policy cfg/iap-policy-empty.json \
  --resource-type=agent-registry \
  --endpoint=${ENDPOINT_REGISTRY_ID} \
  --region=${REGION}

# next

# delete dns resources
gcloud -q dns record-sets delete *.run.app --type=A --zone=priv-zone-run

gcloud -q dns managed-zones delete priv-zone-run

gcloud -q dns policies update dns-policy-${SLUG} --networks=""

gcloud -q dns policies delete dns-policy-${SLUG}

# next

# delete router (includes nat) and psc resources
gcloud -q compute routers delete cr-nat-${SLUG}-${REGION} --region=${REGION}

gcloud -q compute forwarding-rules delete psc2gapis --global

gcloud -q compute addresses delete ip-psc2gapis --global

# next

# delete firewall resources
gcloud -q compute network-firewall-policies associations delete --name=fw-policy-bind-${SLUG} --firewall-policy=fw-policy-${SLUG} --global-firewall-policy

gcloud -q compute network-firewall-policies rules delete 1001 --firewall-policy=fw-policy-${SLUG} --global-firewall-policy

gcloud -q compute network-firewall-policies delete fw-policy-${SLUG} --global

# next

# delete network resources
gcloud -q compute networks subnets delete subnet-${REGION}-agw --region=${REGION}

gcloud -q compute networks subnets delete subnet-${REGION}-crun --region=${REGION}

gcloud -q compute network-attachments delete psc-na-${REGION}-agw --region=${REGION}

gcloud -q compute networks delete vnet-${SLUG}

# next

# clean up local working directories and generated configs
rm -rf cfg agent-weather mcp-weather

# end

На этом завершается этап очистки... далее переходим к заключению !

15. Заключение

Поздравляем! Вы успешно развернули Agent Gateway и настроили управление исходящим трафиком от агентов ИИ!

космопап

Cosmopup считает, что Codelabs — это просто бомба!

Что дальше?

Пожалуйста, оставляйте свои комментарии, вопросы или замечания, используя эту форму обратной связи .

Спасибо!