Kubernetes如何基于资源标签实现ABAC细粒度权限管控

完全可以实现，不需要依赖额外自研ABAC系统，目前原生K8s已经提供了稳定的支持能力。

• 关于原生RBAC的粒度问题：1.31版本之前的K8s RBAC确实仅支持命名空间级、或指定具体资源名称的权限划分，做不到同命名空间内按标签切分应用级、团队级权限，过去很多团队为了做权限隔离只能拆分大量细粒度命名空间，或者引入第三方鉴权插件，维护成本很高。
• 原生标签级权限的正式支持：K8s 1.31版本正式将RBAC的资源选择器特性迭代至稳定版，你可以直接在Role/ClusterRole的规则中配置resourceSelectors字段，通过匹配资源标签划定权限范围，完全满足“特定团队仅能访问同命名空间下带自身所属标签资源”的管控需求。
• 配置示例参考：

# 给team-a分配business-prod命名空间下、带owner-team: team-a标签资源的操作权限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: business-prod
  name: team-a-workload-access
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services", "configmaps"]
  verbs: ["get", "list", "watch", "update", "patch"]
  resourceSelectors:
  - matchLabels:
      owner-team: team-a

将上述Role绑定到team-a对应的用户、用户组或ServiceAccount后，该团队成员即使在同一个命名空间内，也无法操作不带owner-team: team-a标签的资源，会直接返回权限拒绝。

• 低版本集群的注意事项：如果你的集群版本低于1.31，不建议启用原生ABAC模式做管控——老版本ABAC需要静态修改API Server启动参数加载权限策略，不支持动态更新，排障和维护成本极高。这种场景下要么升级集群版本用原生RBAC标签选择器能力，要么通过准入控制器扩展自定义鉴权逻辑，优先选前者。

注意：不要用网络策略替代资源访问管控，网络策略仅能控制集群内网络流量的连通性，无法限制用户通过K8s API对资源发起的操作请求。

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