Bedrock AgentCore Identity 现可引用自有 Secrets Manager 密钥：把密钥治理权留在你手里

预计阅读时间：9 分钟

过去在 Bedrock AgentCore Identity 中配置 credential provider，密钥的生命周期多少有些"托管化"——你创建它、AgentCore 管它，但组织内部已有的轮换策略、加密配置、跨账号复制规则很难直接延伸进来。现在 AWS 放开了这个限制：你可以直接引用一个已经存在于 Secrets Manager 中的密钥，AgentCore 只读取、不代管，治理权完全留在你手上。

为什么这值得关注

很多组织在 Secrets Manager 上已经建立了成熟的密钥治理流程：自动轮换 Lambda、跨账号复制、基于 resource policy 的访问控制、标签驱动的审计检索。如果 AgentCore 强制你新建一个"内部密钥"，这些流程就断了——同一个 API key 出现两份，轮换只覆盖其中一份，审计盲区就此产生。

引用自有密钥后，问题迎刃而解：

轮换：你现有的 rotation Lambda 继续生效，AgentCore 每次读取拿到的始终是最新值。
加密：你选的 KMS key、你定的加密策略，AgentCore 不干预。
复制：跨账号复制规则照常运行。
标签与 policy：ABAC/RBAC 策略、成本标签、合规标签全部保留。

一句话：密钥只有一份，治理只有一套。

工作机制

AgentCore Identity 的 credential provider resource 新增了一个参数，允许你指定一个已有的 Secrets Manager secret ARN，而非让 AgentCore 自动创建。AgentCore 在运行时通过 IAM 权限去读取该 secret 的值，不会修改或删除它。

几个关键约束：

能做	不能做
同 Region 内跨账号引用	跨 Region 引用（Region 必须一致）
引用通过外部 connector 导入的 secret	引用不在同一 Region 的 secret
保留自有轮换、加密、复制、标签配置	让 AgentCore 替你轮换或管理该 secret

跨账号场景的典型做法：目标账号的 secret 配置 resource policy 允许 AgentCore 所在账号读取，AgentCore 端 IAM role 拥有 secretsmanager:GetSecretValue 权限，两者配合完成授权。

实操：从创建到引用

下面给出一个完整流程——先在 Secrets Manager 中创建并配置密钥，再在 AgentCore Identity 中引用它。

1. 创建密钥并配置轮换

# 在账号 A（密钥所属账号）中创建 secret
aws secretsmanager create-secret \
    --name "my-agentcore-api-key" \
    --description "External API key referenced by Bedrock AgentCore" \
    --secret-string '{"api_key":"sk-xxxx-initial-value"}' \
    --kms-key-id "arn:aws:kms:us-east-1:111111111111:key/my-cmk" \
    --tags Key=Environment,Value=Production Key=Compliance,Value=SOC2

# 启用自动轮换（30 天周期，指向你已有的轮换 Lambda）
aws secretsmanager rotate-secret \
    --secret-id "my-agentcore-api-key" \
    --rotation-lambda-arn "arn:aws:lambda:us-east-1:111111111111:function:MySecretRotationLambda" \
    --rotation-rules AutomaticallyAfterDays=30

如果你已有轮换 Lambda，直接挂上去；如果没有，Secrets Manager 也提供内置模板可一键生成。

2. 跨账号授权（如需）

如果 AgentCore 运行在账号 B，需要在账号 A 的 secret 上附加 resource policy：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222222222222:role/AgentCoreExecutionRole"
      },
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "secretsmanager:SecretId": "my-agentcore-api-key"
        }
      }
    }
  ]
}

# 在账号 A 中附加上述 policy
aws secretsmanager put-resource-policy \
    --secret-id "my-agentcore-api-key" \
    --resource-policy file://cross-account-policy.json

同时在账号 B 的 AgentCore execution role 上确保有如下 IAM 权限：

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:us-east-1:111111111111:secret:my-agentcore-api-key-*"
}

3. 在 AgentCore Identity 中引用该密钥

# 创建 credential provider resource，引用已有 secret
aws bedrock-agentcore create-credential-provider \
    --name "my-api-credential" \
    --type "API_KEY" \
    --credential-provider-method "SECRETS_MANAGER_REFERENCE" \
    --secrets-manager-reference-configuration \
        secretArn="arn:aws:secretsmanager:us-east-1:111111111111:secret:my-agentcore-api-key-AbCdEf"

# 输出中会返回 credential provider 的 ARN，后续在 agent 配置中引用即可

SECRETS_MANAGER_REFERENCE 和具体的参数名基于 AWS 已发布的 API 模式推断。实际参数名请以正式 SDK/CLI 文档为准，部署前先用 aws bedrock-agentcore help 确认。

4. 验证读取链路

# 在账号 B 中，用 AgentCore execution role 模拟读取
aws secretsmanager get-secret-value \
    --secret-id "arn:aws:secretsmanager:us-east-1:111111111111:secret:my-agentcore-api-key-AbCdEf" \
    --profile agentcore-env

# 如果返回 secret-string，说明授权链路完整

第三方密钥管理器的接入路径

AWS Secrets Manager 的 external connector 功能允许你将 HashiCorp Vault、CyberArk、1Password 等第三方系统中的密钥映射为 Secrets Manager 中的对象。AgentCore 引用自有密钥的能力同样适用于这些 connector 导入的 secret——这意味着你不必把密钥迁移到 Secrets Manager 的原生存储中，只需确保 connector 正常同步，AgentCore 就能通过标准 ARN 读取。

典型流程：

在 Secrets Manager 中配置 external connector，指向你的 Vault 实例。
Connector 自动在 Secrets Manager 中创建对应 secret 对象（值仍存储在 Vault 中）。
在 AgentCore Identity 中引用该 secret 的 ARN。
AgentCore 运行时通过 connector 间接从 Vault 读取密钥值。

这样，Vault 侧的 policy、审计日志、动态 secret 生成能力全部保留，AgentCore 只是一个标准消费者。

采用前要想清楚的事

Region 一致性：AgentCore 和 secret 必须在同一 Region。如果你的 AgentCore 部署在 us-east-1，secret 也必须在 us-east-1。跨 Region 复制的 secret 副本不能被引用——你只能引用主 secret 或同 Region 内的 replica。
轮换窗口的短暂不一致：轮换过程中 secret 值会经历一个短暂的"旧值→新值"过渡期。如果你的 agent 对密钥变更敏感（比如长连接 token），需要确认应用层有重试或刷新逻辑。
connector 的可用性依赖：引用第三方 connector secret 时，AgentCore 的读取链路多了一层依赖——Vault 或 CyberArk 的服务可用性直接影响 agent 能否拿到密钥。建议对 connector 做可用性监控。
IAM 与 resource policy 双向对齐：跨账号场景下，secret 端的 resource policy 和 AgentCore 端的 IAM policy 必须同时放行，缺一不可。排查问题时先分别验证两端。

快速检查清单

检查项	确认
Secret 与 AgentCore 在同一 Region	☐
KMS key 授权 AgentCore role 解密（如使用自定义 CMK）	☐
跨账号场景：resource policy + IAM policy 双向放行	☐
轮换 Lambda 正常运行且覆盖该 secret	☐
Connector 场景：第三方服务可用性监控已配置	☐
Secret 标签与组织治理规则一致	☐

这项改动看似只是"多了一个参数"，实质上把密钥治理的选择权交回了你手里。如果你的组织已经在 Secrets Manager 上投入了轮换、审计、跨账号复制等基础设施，现在可以直接把它们延伸到 AgentCore，不必再为同一个密钥维护两套流程。