Как Amazon Bedrock научился работать с вашими секретами в AWS Secrets Manager

Что нового

Amazon добавила в Amazon Bedrock AgentCore Identity важную функцию: теперь для исходящей аутентификации (Outbound Auth) можно подключать уже существующие секреты в AWS Secrets Manager, а не только использовать секреты, которые AgentCore создаёт сам.

Конкретно появилось:

1. Поддержка ссылок на существующие секреты в AWS Secrets Manager при создании credential provider ресурсов (Outbound Auth):

   • можно указать ARN секрета;
   • можно задать JSON-ключ внутри секрета, где лежит нужное значение.

2. Полный контроль над управлением секретом остаётся у вас:

   • шифрование с помощью собственного customer managed AWS KMS ключа (CMK);
   • собственные политики ротации секретов;
   • репликация секретов;
   • любые теги для биллинга, комплаенса и аудита;
   • собственные resource policies на секрет.

3. Работа с секретами из других AWS-аккаунтов:

   • можно использовать секрет из другого AWS-аккаунта в той же Region;
   • кросс-региональная работа с секретами не поддерживается.

4. Интеграция с внешними менеджерами секретов через AWS Secrets Manager external connectors:

   • если вы уже подключили внешний менеджер секретов к Secrets Manager, AgentCore Identity может использовать эти секреты.

5. Поддержка двух типов исходящих credential provider ресурсов с внешними секретами:

   • API key;
   • OAuth2 client secret (например, GoogleOauth2).

Числовых бенчмарков по скорости или стоимости Amazon не приводит. Главное изменение — в управлении секретами и безопасности, а не в производительности.

Как это работает

Базовая схема

Раньше Amazon Bedrock AgentCore Identity для каждого Outbound credential provider сам создавал секрет в AWS Secrets Manager в вашем аккаунте. В этом секрете лежали:

• API-ключ или OAuth client secret;
• метаданные внешнего identity-провайдера.

AgentCore полностью управлял этими секретами, а вы не могли:

• задать свои теги при создании;
• включить свою политику ротации;
• зашифровать секрет своим KMS-ключом.

Теперь вместо автоматического создания секрета вы можете передать ARN уже существующего секрета в AWS Secrets Manager и указать JSON-ключ, где хранится нужное значение (API key или client secret).

На рантайме AgentCore Identity:

1. По ARN обращается к AWS Secrets Manager.
2. Выполняет secretsmanager:GetSecretValue.
3. Распарсивает JSON и достаёт значение по указанному JSON-ключу.
4. Использует это значение для вызова внешнего API.

Если вы обновляете секрет (например, ротация ключа), AgentCore Identity при следующем чтении просто получает новое значение — без изменения конфигурации credential provider ресурса.

Права доступа и шифрование

Чтобы AgentCore Identity смог прочитать секрет, нужно:

• дать сервисному принципалу AgentCore Identity право secretsmanager:GetSecretValue на этот секрет через resource policy секрета;
• если секрет зашифрован customer managed KMS ключом, дать этому же сервисному принципалу право kms:Decrypt на соответствующий ключ.

Само шифрование и ротация остаются под вашим контролем:

• вы создаёте секрет с нужным KMS-ключом;
• вы настраиваете rotation Lambda или managed rotation, если нужно;
• вы настраиваете репликацию и теги.

AgentCore Identity только читает значение на рантайме.

Поддерживаемые типы секретов

Функция работает для двух типов Outbound Auth ресурсов:

1. API key — простой ключ доступа к внешнему API.
2. OAuth2 client secret — секрет клиента для OAuth-провайдера (например, GoogleOauth2).

В обоих случаях вы указываете:

• ARN секрета в Secrets Manager;
• JSON-ключ внутри секрета, где лежит нужное значение.

Кросс-аккаунты и внешние менеджеры секретов

• Можно использовать секреты из другого AWS-аккаунта, если они в той же Region, и resource policy секрета даёт доступ сервисному принципалу AgentCore Identity.
• Можно использовать секреты, которые пришли через AWS Secrets Manager external connectors — то есть фактически секреты из внешних менеджеров, интегрированных с Secrets Manager.

Кросс-региональная работа с секретами не поддерживается: секрет и AgentCore Identity должны быть в одной AWS Region.

Что это значит для вас

Когда это полезно

1. У вас уже есть секреты для внешних API

Команда давно хранит API-ключи и OAuth client secrets в AWS Secrets Manager. Раньше AgentCore Identity создавал свои собственные секреты, и вы получали дублирование и хаос в управлении. Теперь можно:

• передать ARN уже существующего секрета;
• использовать один источник правды для всех систем.

2. Вы регулярно ротируете ключи и не хотите трогать конфигурацию агентов

Вы меняете API-ключ или client secret по политике безопасности. С новым режимом:

• вы просто обновляете значение в Secrets Manager;
• AgentCore Identity на следующем запросе читает новое значение;
• вам не нужно пересоздавать Outbound Auth или менять настройки агента.

3. Жёсткие требования по шифрованию и комплаенсу

Если вы работаете под регуляторикой, где нужно использовать только customer managed KMS ключи, и это проверяют через SCP/RCP:

• создаёте секрет с нужным CMK;
• настраиваете теги, политики, ротацию;
• передаёте ARN в AgentCore Identity.

AgentCore не меняет конфигурацию шифрования — вы сохраняете полный контроль.

4. Нужны теги и аудит на уровне секретов

Если финансы и безопасность требуют тегировать каждый секрет для:

• распределения затрат;
• трекинга по проектам;
• аудита и комплаенса,

то вы создаёте секрет заранее, размечаете его по своим правилам и только потом подключаете к AgentCore Identity.

5. Вы уже используете внешний менеджер секретов через Secrets Manager external connectors

Если организация держит секреты не только в AWS, но и во внешнем хранилище, интегрированном через AWS Secrets Manager external connectors, то AgentCore Identity может использовать эти секреты через стандартный механизм ARN + JSON-ключ.

Где это реально помогает

• Продакшн-агенты, которые зовут CRM, Slack, GitHub, платёжные системы и другие внешние API.
• Корпоративные внедрения LLM-агентов, где требования по безопасности ближе к банковским.
• Мультиаккаунтная инфраструктура AWS, где секреты централизованно живут в одном аккаунте, а агенты — в другом (но в той же Region).

Где использовать не стоит

• Если у вас нет AWS-инфраструктуры и вы не планируете её заводить.
• Если вы строите прототип на пару дней и не хотите тратить время на AWS Secrets Manager и KMS — в этом случае проще позволить AgentCore Identity самому создать секрет.
• Если вы работаете из регионов, где Amazon Bedrock недоступен, или доступ к AWS сильно ограничен (например, требуется VPN или обход блокировок) — интеграция будет сложной и может быть нецелесообразной.

Важно про доступность

Amazon Bedrock и AWS Secrets Manager официально не ориентированы на рынок России. Для работы может потребоваться:

• аккаунт AWS с поддерживаемым биллингом;
• стабильный доступ к AWS-регионам, где запущен Bedrock;
• в ряде случаев — VPN или другие способы выхода в нужный регион.

Если ваша инфраструктура и так живёт в AWS, новая функция логично вписывается в существующую схему безопасности. Если нет — это ещё один аргумент в пользу того, чтобы не тянуть Bedrock в изолированную среду ради одного агента.

Место на рынке

Эта функция касается не качества самих моделей, а уровня секьюрной интеграции агентов с внешними системами.

В экосистеме крупных вендоров уже есть похожие подходы:

• Azure даёт тесную связку AI-сервисов с Azure Key Vault.
• Google Cloud сочетает Vertex AI с Secret Manager.

Amazon делает то же самое для своего стека: Bedrock AgentCore Identity + AWS Secrets Manager + AWS KMS.

Прямых цифр по сравнению с конкурентами Amazon не приводит. Из описания видно, что ставка делается на:

• использование уже существующей инфраструктуры секретов;
• минимизацию дублирования секретов;
• упрощение комплаенса и аудита в средах, где AWS — основной облачный провайдер.

Если ваша основная платформа — AWS и вы строите агентов именно на Bedrock, логичнее всего завязывать их на Secrets Manager, а не на внешние хранилища. Если вы живёте в Azure или GCP, эта функция сама по себе не станет поводом мигрировать.

Как запустить: консоль

A. Подключить API key через существующий секрет

1. Откройте Amazon Bedrock AgentCore консоль.

2. В левом меню выберите Identity.

3. В секции Outbound Auth нажмите Add Outbound Auth.

4. Выберите Add API key.

5. Введите Name для ресурса Outbound Auth.

6. В блоке API key selection method выберите Provide API key via Secrets Manager.

7. В поле Secrets Manager ARN введите или выберите ARN существующего секрета. Например:

   arn:aws:secretsmanager:us-east-1:123456789012:secret:myApiKeySecret-AbCdEf

8. В поле JSON key укажите ключ внутри JSON-секрета, где лежит значение API-ключа.

9. Нажмите Add.

10. Убедитесь, что credential provider появился в списке Outbound Auth.

B. Подключить OAuth client secret через существующий секрет

1. На странице Identity нажмите Add Outbound Auth.
2. Выберите Add OAuth client.
3. Введите Name для OAuth-клиента, например google-oauth-client-v5fz5.
4. В поле Provider выберите нужного провайдера (встроенного или кастомного).
5. Введите Client ID, который вы получили от внешнего identity-провайдера.
6. В блоке Client secret выберите Provide Client secret via Secrets Manager.
7. В поле Secrets Manager ARN введите ARN секрета, который содержит ваш OAuth client secret.
8. В поле JSON key укажите ключ внутри секрета, где лежит значение client secret.
9. Нажмите Add OAuth Client.
10. Проверьте, что новый credential provider появился в списке Outbound Auth.

Как запустить: AWS CLI

Через AWS CLI можно создать Outbound Auth для OAuth2-клиента с внешним секретом. Пример команды из AWS:

aws bedrock-agentcore-control create-oauth2-credential-provider \
 --name "google-oauth-client-v5fz5" \
 --credential-provider-vendor "GoogleOauth2" \
 --oauth2-provider-config-input '{
   "googleOauth2ProviderConfig": {
     "clientId": "<clientId>",
     "clientSecretSource": "EXTERNAL",
     "clientSecretConfig": {
       "secretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:myGoogleKeySecret-AbCdEf",
       "jsonKey": "key"
     }
   }
 }'

Где:

• <clientId> — ваш реальный Client ID от Google или другого провайдера;
• secretId — ARN секрета в AWS Secrets Manager;
• jsonKey — ключ в JSON-секрете, где лежит client secret.

Не забудьте:

• дать сервисному принципалу AgentCore Identity доступ secretsmanager:GetSecretValue к этому секрету;
• если секрет шифруется вашим KMS-ключом — доступ kms:Decrypt к этому ключу.

Как запустить: через AI-агента на десктопе

Если вы пользуетесь AI-кодинг-агентом (например, Kiro или аналогом), можно просто описать задачу в виде промпта. Пример текста, который предлагает AWS:

“I have an existing secret in AWS Secrets Manager at ARN arn:aws:secretsmanager:us-east-1:123456789012:secret:my-api-key. Create an OAuth2 credential provider in Amazon Bedrock AgentCore Identity named <client-name>, using GoogleOauth2 as the vendor. The client ID is <clientId>, the client secret source is EXTERNAL, and the secret JSON key is key.”

Нужно заменить:

• <client-name> — на имя вашего OAuth-клиента;
• <clientId> — на реальный Client ID.

Агент сгенерирует нужные команды или Terraform/CloudFormation, если вы так попросите.

Безопасность: что не забыть настроить

1. Resource policy на секрет

Добавьте в политику секрета разрешение для сервисного принципала AgentCore Identity на действие secretsmanager:GetSecretValue.

2. Права на KMS-ключ

Если секрет зашифрован customer managed KMS ключом, добавьте для сервисного принципала право kms:Decrypt на этот ключ.

3. JSON-структура секрета

Убедитесь, что структура секрета в Secrets Manager соответствует тому, что вы указываете в поле jsonKey. Например, если секрет выглядит так:

{
  "key": "my-secret-api-key",
  "other": "value"
}

то jsonKey должен быть key.

4. Region и аккаунт

• AgentCore Identity и секрет должны находиться в одной AWS Region.
• Если секрет в другом аккаунте — проверьте, что resource policy секрета даёт доступ сервисному принципалу из аккаунта, где крутится AgentCore.

Вывод

Amazon подтянула Amazon Bedrock AgentCore Identity к реалиям продакшн-инфраструктуры: агенты теперь могут использовать те же секреты и те же правила управления, что и остальная часть ваших сервисов в AWS. Для команд, которые живут в AWS и серьёзно относятся к безопасности, это не косметическое улучшение, а заметное упрощение жизни: меньше дублирования, меньше ручной синхронизации и меньше шансов случайно оставить секрет в промпте или коде.

---

Читайте также

• Microsoft обновила Exposure Score в Defender: теперь важна реальная уязвимость, а не только CVSS
• PewDiePie выложил в open source Odysseus — локальный AI-хаб вместо ChatGPT и Claude
• Как Microsoft учит Copilot писать агентов за вас: SKILL, Agent Framework и Foundry