跨AWS账户执行eks:DescribeCluster操作的替代方案咨询

你当前采用的sts:AssumeRole链式调用方案是可行的，这里先给出该方案的优化建议，再提供其他替代方案：

现有AssumeRole方案的优化 #

• 最小权限约束：给账户A中被扮演的角色只分配eks:DescribeCluster权限，且限定到目标EKS集群的ARN，示例权限策略：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "eks:DescribeCluster",
        "Resource": "arn:aws:eks:<region>:<accountA-id>:cluster/<cluster-name>"
      }
    ]
  }
  

• 严格信任策略：将账户A角色的信任策略限定为仅允许账户B的Lambda执行角色ARN扮演，而非整个账户B，示例信任策略：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "AWS": "arn:aws:iam::<accountB-id>:role/<lambda-exec-role-name>"
        },
        "Action": "sts:AssumeRole"
      }
    ]
  }
  

替代方案1：账户A侧API Gateway代理 #

• 操作步骤：
  1. 在账户A创建一个Lambda，仅执行eks:DescribeCluster并返回所需的API端点和证书数据；
  2. 创建API Gateway，将后端集成到上述Lambda；
  3. 配置API Gateway的IAM授权，允许账户B的Lambda执行角色调用该API；
  4. 账户B的Lambda直接调用API Gateway端点获取数据。
• 优势：账户A可自定义返回数据（仅返回需要的字段），账户B无需处理STS角色切换逻辑，权限管理更集中。

替代方案2：AWS RAM共享EKS访问权限 #

• 操作步骤：
  1. 在账户A通过AWS Resource Access Manager（RAM），将目标EKS集群的eks:DescribeCluster权限共享给账户B的Lambda执行角色；
  2. 账户B的Lambda直接使用自身角色调用EKS的DescribeCluster API，无需AssumeRole。
• 优势：省去角色切换步骤，RAM自动处理跨账户权限映射，操作更简洁。

替代方案3：共享存储同步集群信息 #

• 操作步骤：
  1. 在账户A创建定时触发的Lambda（比如用CloudWatch Event），定期调用eks:DescribeCluster获取数据；
  2. 将数据存储到跨账户可访问的存储服务：
     • S3：给账户B的Lambda执行角色配置读取特定桶的权限，B侧Lambda直接从S3读取；
     • Secrets Manager：将集群信息作为Secret存储，并共享给账户B的角色，B侧Lambda拉取Secret。
• 优势：适合对数据实时性要求不高的场景，B侧Lambda无需调用EKS API，延迟更低。

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