跨AWS账号访问SecretsManager时External-Secret报AccessDeniedException

核心原因分析 #

从错误信息和测试结果来看，直接通过Pod使用同一IAM角色能成功访问，但ESO同步失败，说明问题出在ESO配置或IAM策略的细节匹配上，而非跨账号权限的核心逻辑。

排查与修复步骤 #

1. 验证Secret ARN与IAM策略资源匹配 #

Secrets Manager创建密钥时会自动添加随机后缀（例如appsecret/test/new-test-abc123），请登录账号2的Secrets Manager，复制目标密钥的完整ARN，确认账号1角色策略中的资源路径是否能覆盖它：

• 当前策略中的资源是arn:aws:secretsmanager:us-east-2:AWSACCOUNT2ID:secret:appsecret/test/*，如果实际ARN是arn:aws:secretsmanager:us-east-2:AWSACCOUNT2ID:secret:appsecret/test/new-test-xxxxxx，该路径是匹配的；如果不匹配，调整策略资源为更精确的路径，或临时改为arn:aws:secretsmanager:us-east-2:AWSACCOUNT2ID:secret:*做测试。

2. 检查ClusterSecretStore配置 #

确认ClusterSecretStore的AWS Provider配置正确：

• 指定正确的区域us-east-2
• 关联的ServiceAccount与实际使用的一致
  示例配置：

apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: aws-cross-account
spec:
  provider:
    aws:
      region: us-east-2
      serviceAccountRef:
        name: external-secrets
        namespace: external-secrets

3. 确认ServiceAccount配置 #

• 检查ServiceAccount是否添加了正确的eks.amazonaws.com/role-arn注解，指向账号1的EKSSecretsReaderRole：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: external-secrets
  namespace: external-secrets
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::AWSACCOUNT1ID:role/EKSSecretsReaderRole

• 验证ESO的Deployment使用的serviceAccountName是否为该ServiceAccount。

4. 查看ESO Provider日志 #

获取external-secrets-provider-aws Pod的日志，排查是否有更详细的错误信息：

kubectl logs -n external-secrets -l app=external-secrets-provider-aws

日志可能会暴露KMS解密失败、角色凭证获取异常等细节问题。

5. 检查SCP限制 #

确认账号1和账号2的AWS组织SCP没有限制跨账号的secretsmanager:GetSecretValue操作，或其他相关权限。

6. 升级ESO版本 #

当前使用的ESO v0.8.3版本较旧，存在部分跨账号访问的已知问题，建议升级到最新稳定版（例如v0.9+）后重试。

验证修复 #

完成上述调整后，删除现有ExternalSecret对象重新创建，或手动触发ESO同步：

kubectl annotate externalsecret <your-es-name> -n <namespace> external-secrets.io/reconcile=true --overwrite

内容的提问来源于stack exchange，提问作者Majid Faridi