能否创建采用排除权限模式的Kubernetes角色？

核心前提说明 #

Kubernetes 原生 RBAC 体系只支持显式允许的授权逻辑，没有内置的"拒绝某类操作"的语法字段，根本不存在直接把参考示例里的verbs改成deny就能生效的快捷写法。RBAC 的鉴权逻辑是"默认拒绝、只要匹配到任意一条允许规则就放行"，所有规则最终生效的权限是取并集，不会因为写了多条规则就自动做权限排除。

分场景实现方法 #

场景1：角色仅需要Pod的部分操作权限，明确排除get/list/watch #

这种场景完全不需要额外组件，配置成本极低：

• 不要预先给Pod的全量权限，在写规则的时候，只列清楚你要允许的操作动词，把get、list、watch从允许列表里剔除就行。
• 可以直接用kubectl create role命令快速生成规则，不用手动敲完整YAML。比如要给角色授予Pod的创建、删除、更新权限，同时排除查询类的get/list/watch操作，直接执行命令：
  kubectl create role pod-manager --verb=create,delete,patch,update --resource=pods

生成的规则和参考示例结构一致：

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "delete", "patch", "update"]

这种配置天生就不包含Pod的get、list、watch权限，没有任何额外开销。

场景2：角色需要拥有全量集群权限，仅单独拦截Pod的get/list/watch操作 #

这种场景靠纯RBAC规则是实现不了排除的——只要给了resources: ["*"]、verbs: ["*"]的全量权限规则，就已经覆盖了所有对Pod的操作，靠修改单条规则根本做不到精准排除。这个时候可以用策略拦截组件快速实现：

• 用Kyverno、OPA Gatekeeper这类云原生策略引擎，导入预置的拦截规则模板，配置匹配逻辑：当请求发起者绑定的角色属于要限制的范围，且请求的操作是Pod的get/list/watch类型时，直接拦截请求返回拒绝。
• 这类组件都提供了开箱即用的规则模板，不需要从零编写拦截逻辑，导入就能用。

常见踩坑提醒 #

• 别尝试在Role的verbs字段里加类似"deny"的自定义值，apiserver根本不会解析这类自定义语义，写了也不会产生任何拒绝效果。
• 别靠多条重叠的RBAC规则做权限排除，因为RBAC的规则是取并集生效，不是取交集——哪怕你写了一条看起来像"禁止get/list/watch Pod"的规则，只要有另一条规则允许这类操作，请求照样会被放行。

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