EC2部署K8S后遇STS:AssumeRole权限拒绝问题求助

执行kubectl get ns时出现权限错误：

kubectl get ns

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::00000000:user/NotRootAccount is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::000000000:user/NotRootAccount:role/DeveleapEksRole
E0807 13:35:32.960611    2137 memcache.go:265] couldn't get current server API group list: Get "https://55F0139D24BC8EE6FF9E008F6A817620.gr7.eu-north-1.eks.amazonaws.com/api?timeout=32s": getting credentials: exec: executable aws failed with exit code 254

注：ARN为伪造内容

相关配置信息 #

权限列表 #

AmazonEKS_CNI_Policy            AWS      managed    Directly
AmazonEKSClusterPolicy          AWS      managed    Directly
AmazonEKSServicePolicy          AWS      managed    Directly
AmazonEKSVPCResourceController  AWS      managed    Directly
AmazonEKSWorkerNodePolicy       AWS      managed    Directly
AWSQuickSightListIAM            AWS      managed    Directly
IAMFullAccess                   AWS      managed    Directly
IAMSelfManageServiceSpecificCredentials     AWS      managed    Directly

角色信任关系 #

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        },
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::0009:user/NotRootAccount"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

自定义策略 #

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::0600009:role/DeveleapEksRole"
        }
    ]
}

排查与解决步骤 #

1. 修正ARN格式错误
   错误信息中目标ARN格式异常：arn:aws:iam::000000000:user/NotRootAccount:role/DeveleapEksRole，正确的角色ARN格式应为arn:aws:iam::账号ID:role/角色名，检查kubeconfig中AssumeRole的resource配置，确保使用正确的角色ARN，而非用户ARN拼接角色名的错误格式。

2. 验证权限与信任关系的账号ID一致性

   • 自定义策略中指定的角色ARN账号ID为0600009，信任关系中用户ARN账号ID为0009，错误信息中用户ARN账号ID为00000000，需确保所有配置中的账号ID统一，且与实际AWS账号ID匹配。
   • 确认用户NotRootAccount已被正确授予自定义策略中的sts:AssumeRole权限，且策略中指定的角色ARN完全正确。

3. 检查kubeconfig配置
   查看EC2实例上的kubeconfig文件，确认exec部分的aws-cli命令参数正确，特别是--role-arn参数是否指向正确的DeveleapEksRole ARN，无多余或错误的路径拼接。

4. 验证角色权限
   确保DeveleapEksRole已被授予访问EKS集群的权限：

   • 为角色添加AmazonEKSClusterPolicy托管策略（若未添加）。
   • 通过aws-auth ConfigMap，将该角色映射到EKS集群的合适权限组（如system:masters或自定义权限组）。

5. 测试AssumeRole命令
   在EC2实例上直接执行aws sts assume-role --role-arn 正确的角色ARN --role-session-name test-session，验证是否能成功获取临时凭证，排查是否是aws-cli配置或权限问题导致的exec失败。

最终需求：访问EKS并配置ArgoCD，需先解决kubectl的权限连接问题。

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