无法通过Assume Role访问由Assume Role API创建的AWS EKS集群

aws-auth ConfigMap的ARN存储格式 #

aws-auth里存的就是标准完整的IAM角色ARN，比如你提到的arn:aws:iam::<账号ID>:role/k8s-cluster-role这种形式，没有特殊处理逻辑。

核心问题：混淆EKS服务角色与集群访问角色 #

你创建EKS时指定的Role C是EKS服务角色——这个角色是给EKS控制平面使用的，用来调用AWS API管理集群关联资源（如节点、VPC组件），它不会自动被加入aws-auth ConfigMap，也不是用于用户访问集群的身份凭证。

你用Role A扮演Role C访问集群被拒，本质是Role C的IAM身份未被添加到aws-auth的IAM-Kubernetes身份映射中，导致Kubernetes无法识别该身份的访问权限。

解决步骤 #

1. 验证角色扮演链路有效性
   检查Role A的权限策略是否包含sts:AssumeRole操作（目标为Role C的ARN），同时确认Role C的信任策略已将Role A的ARN列为允许的信任实体，确保Role A能正常获取Role C的临时凭证。

2. 手动配置aws-auth身份映射
   编辑kube-system命名空间下的aws-auth ConfigMap，添加Role C的ARN映射：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: aws-auth
     namespace: kube-system
   data:
     mapRoles: |
       - rolearn: arn:aws:iam::<你的AWS账号ID>:role/k8s-cluster-role
         username: eks-cluster-access-user
         groups:
           - system:masters
   

   • rolearn：填写Role C的完整ARN
   • username：自定义Kubernetes内部识别的用户名
   • groups：绑定Kubernetes权限组，比如system:masters对应集群管理员权限，可根据实际需求调整

3. 验证集群访问
   切换到Role A扮演Role C的身份后，执行kubectl get namespaces，确认是否能正常访问集群资源。

注意：不建议将EKS服务角色（Role C）同时用作集群访问角色，最佳实践是分开创建两个独立角色，避免权限过度集中。

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