如何为正则匹配的K8s test-*命名空间批量分配RBAC权限？

原生K8s RBAC本身不支持基于正则/通配符匹配命名空间范围的ClusterRoleBinding，你担心的CI runner权限提权问题完全可以通过合理的权限设计规避，不需要退而求其次用全集群生效的ClusterRoleBinding。

两个核心问题的明确答复 #

• 不存在原生支持正则匹配命名空间集合的ClusterRoleBinding能力。K8s RBAC的资源匹配逻辑仅支持指定具体资源名、或留空匹配全部资源两种模式，没有内置按命名空间名正则过滤的规则配置项。
• 完全可以限制Gitlab-CI runner仅能在安全范围内创建RoleBinding，不会出现权限提升风险，具体实现方式见下文方案。

推荐落地方案（按优先级从高到低） #

方案1：准入控制器自动同步权限（零RBAC权限给runner，最安全）

如果你的集群部署了通用准入控制器（绝大多数生产集群都会部署这类组件做策略管控），这是成本最低、风险最小的方案：

1. 先创建全局固定的低权限ClusterRole，存放你要给开发的所有权限。注意你之前写的权限规则里有个小错误：apps API组下部署资源的正确名称是deployments，不是deploys，配置错误会导致权限不生效。参考配置：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: test-namespace-developer
   rules:
   - apiGroups: ["apps"]
     resources: ["deployments"]
     verbs: ["get", "list"]
   - apiGroups: [""]
     resources: ["pods", "pods/log"]
     verbs: ["get", "list"]
   - apiGroups: [""]
     resources: ["pods/exec"]
     verbs: ["create"]
   

2. 写一条准入策略，规则非常简单：所有名称匹配test-*前缀的命名空间创建时，自动在该命名空间下生成RoleBinding，将开发用户组绑定到上面的test-namespace-developer ClusterRole，命名空间删除时RoleBinding同步清理。

   这个方案下，Gitlab-CI runner完全不需要被授予任何RBAC类资源的操作权限，只需要保留创建命名空间、部署测试环境workload的权限即可，从根源上消除了runner操作RBAC带来的提权可能。所有test开头的命名空间会自动带上开发需要的权限，非test前缀的命名空间完全不受影响。

方案2：收敛runner的RBAC操作权限（无额外组件依赖）

如果你不想部署准入控制器，也可以直接给runner授予最小必要的RBAC操作权限，完全堵死提权路径：

1. 和方案1一样，先创建全局固定的test-namespace-developer低权限ClusterRole，绝对不要给runner创建/修改Role/ClusterRole的权限，从根源上防止它构造高权限角色。
2. 给runner绑定的ClusterRole按如下规则配置，仅授予必要权限：

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: ci-test-ns-runner
   rules:
   # 按你的CI需求授予创建、删除test前缀命名空间、部署workload的权限即可
   - apiGroups: [""]
     resources: ["namespaces"]
     verbs: ["create", "delete"]
   # 允许runner操作RoleBinding，但通过bind动词限制它只能绑定固定的低权限ClusterRole
   - apiGroups: ["rbac.authorization.k8s.io"]
     resources: ["rolebindings"]
     verbs: ["create", "delete", "get", "list"]
   - apiGroups: ["rbac.authorization.k8s.io"]
     resources: ["clusterroles/test-namespace-developer"]
     verbs: ["bind"]
   

   这套配置下，runner就算被攻破，也只能创建绑定test-namespace-developer这个低权限角色的RoleBinding，根本无法绑定cluster-admin等高权限角色；就算它误在非test命名空间创建了RoleBinding，授予的也只是测试用的低权限，不会造成集群级风险。你可以再在CI流程里加一层简单的校验，确保创建RoleBinding的命名空间必须是test-前缀，就完全满足需求了。

不推荐的方案 #

不要直接给开发用户组绑定集群级ClusterRoleBinding，哪怕绑定的是低权限ClusterRole，也会导致开发在kube-system、生产环境等所有命名空间都拿到Pod查看、exec权限，存在极大的安全风险。

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