EKS集群IRSA配置与aws-auth权限相关疑问咨询

问题场景 #

我在EKS集群内运行一个服务，需要跨多个命名空间对不同Kubernetes对象执行读、增、改、修补操作，操作步骤如下：

• 创建IAM角色：service_account_role
• 为该角色附加arn:aws:iam::aws:policy/AdministratorAccess策略
• 在集群内创建ServiceAccount，添加注解eks.amazonaws.com/role-arn: ${service_account_role}
• 创建包含所需操作权限规则的ClusterRole
• 创建ClusterRoleBinding绑定上述ClusterRole与ServiceAccount

运行应用时触发错误：User "system:anonymous" cannot patch resource (403)（当时调用Python Kubernetes客户端的read_namespaced_ingress方法修补Ingress对象更新注解）

之后将service_account_role添加到aws-auth ConfigMap并关联system:masters组，应用恢复正常。

疑问 #

1. 已通过ClusterRole绑定ServiceAccount权限，为何仍需用aws-auth ConfigMap映射角色？
2. 该映射不是仅用于访问集群外AWS资源吗？
3. system:anonymous组是什么？未找到权威说明。
4. 能否不修改aws-auth ConfigMap就将IRSA加入system:masters组？并发修补该映射难度大，且有多个服务/IRSA需此类权限。

解答 #

1. 为何仍需aws-auth ConfigMap映射角色？ #

核心问题是IRSA的身份认证环节未完成。ClusterRole和ClusterRoleBinding是Kubernetes内部的权限授权规则，但前提是服务账号能被正确识别为合法身份。

当应用通过IRSA访问K8s API时，EKS需要验证IAM角色的身份，并将其映射到对应的K8s服务账号或用户/组。如果aws-auth里没有该IAM角色的映射规则，EKS无法完成身份转换，应用请求会被当作匿名请求处理，自然触发system:anonymous的权限错误。

ClusterRoleBinding绑定的是K8s的ServiceAccount，但如果IAM角色无法关联到这个ServiceAccount，K8s API根本不知道请求来自这个ServiceAccount，授权规则也就无法生效。

2. aws-auth映射的作用不止于访问外部资源 #

aws-auth ConfigMap是EKS用来打通IAM身份与K8s身份体系的核心组件，它的作用包括：

• 将IAM用户/角色映射为K8s的用户、组或服务账号
• 控制哪些IAM身份能访问K8s集群（身份认证）
• 为映射后的K8s身份分配预定义权限（比如关联system:masters组获得集群管理员权限）

它不仅是用来让集群内应用访问AWS外部资源（那是IRSA的另一部分功能：通过IAM角色调用AWS API），更关键的是完成IAM到K8s的身份认证，让K8s能识别请求的合法身份。

3. system:anonymous组是什么？ #

system:anonymous是Kubernetes内置的匿名用户组，当K8s API Server无法识别请求的身份时，就会将该请求归为这个组。

出现这个标识，说明应用请求没有通过任何身份认证流程——要么是没有携带有效的认证凭证，要么是凭证无法被K8s API Server验证（比如IRSA的身份映射缺失）。此时请求只能使用system:anonymous的权限，而这个组默认只有极有限的权限（甚至没有修改资源的权限），所以触发403错误。

4. 不修改aws-auth ConfigMap能否将IRSA加入system:masters组？ #

不行，因为system:masters是K8s的内置集群管理员组，而aws-auth ConfigMap是EKS中唯一能将IAM角色映射到K8s组的机制。不过你可以优化映射方式来降低并发修改的风险：

• 批量映射：在aws-auth中添加一条规则，将某个IAM权限边界（比如特定IAM标签、特定路径下的IAM角色）批量映射到system:masters组，这样后续新增符合条件的IRSA角色时无需修改ConfigMap
• 使用声明式工具管理aws-auth：将aws-auth ConfigMap的配置纳入版本控制，通过Kustomize或Helm等工具进行声明式更新，避免手动修改的并发冲突
• 避免过度授权：system:masters权限过大，建议不要直接给服务账号这个权限。可以创建更精细的ClusterRole，包含你需要的所有跨命名空间操作权限，然后通过ClusterRoleBinding绑定到对应的ServiceAccount——前提是确保IRSA的身份映射正确完成（即aws-auth中存在该IAM角色到ServiceAccount的映射）

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