K8s下gitlab-admin SA访问services命名空间serviceaccounts权限报错排查

• 第一版配置的核心匹配错误
  报错里实际发起请求的权限主体是system:serviceaccount:management:gitlab-admin，但第一版ClusterRoleBinding的授权对象只包含kube-system/gitlab、services/gitlab两个ServiceAccount，从始至终没有把management命名空间下的gitlab-admin纳入授权范围，权限主体完全错位。
• 第二版调整配置的两层无效问题
  1. 自定义规则完全悬空：你在配置里定义的、专门列举serviceaccounts等资源操作权限的名为gitlab-admin的ClusterRole，从头到尾没有被任何ClusterRoleBinding/命名空间级RoleBinding引用——你的ClusterRoleBinding的roleRef指向的是K8s内置的cluster-admin ClusterRole，和自定义的那个规则毫无关联，写了等于白写，完全不参与权限校验。
  2. 通配符规则的固有缺陷：就算把自定义的这个ClusterRole正确绑定，很多K8s版本中apiGroups: ["*"]的通配符写法不会覆盖核心API组（apiGroup为空字符串），而serviceaccounts刚好属于核心API组资源，哪怕规则里写了要管理serviceaccounts，也会因为apiGroup不匹配导致权限失效，必须显式把空字符串加入apiGroups列表才能生效。
• 绑定内置cluster-admin仍报权限不足的常见诱因
  内置cluster-admin集群角色本身具备全资源全操作权限，如果绑定后依然提示无权限，通常是两个场景：
  • GitLab侧配置使用的ServiceAccount token和刚创建的management命名空间下gitlab-admin的token不匹配，实际发起请求的是其他未授权SA的身份
  • 集群存在前置的deny类准入规则（比如OPA Gatekeeper、命名空间级的强制拒绝策略），优先级高于授权规则

• 先执行权限校验命令直接验证绑定是否生效：kubectl auth can-i get serviceaccounts -n services --as=system:serviceaccount:management:gitlab-admin
• 如果返回no，说明权限绑定根本没匹配到请求主体，需要重新检查ClusterRoleBinding的subjects字段：确认subjects里的name、namespace和报错里的主体字符串完全一致，没有拼写错误
• 清理无效悬空配置：要么删除没被引用的自定义gitlab-admin ClusterRole，要么把ClusterRoleBinding的roleRef指向这个自定义角色，同时把自定义角色的apiGroups字段改成["", "*"] 显式覆盖核心API组
• 确认GitLab侧的身份配置：核对GitLab Runner/API服务挂载的SA token secret，是否对应management命名空间下gitlab-admin的合法token，避免用错其他低权限SA的凭证
• 排查冲突规则：检查是否存在针对该SA的其他低权限绑定、或者集群全局的拒绝策略，确保授权规则优先级最高

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