如何基于RBAC限制跨全命名空间查询Kubernetes资源的返回结果

核心实现原理 #

Kubernetes API服务器原生支持授权结果自动过滤机制：当发起跨所有命名空间的资源list请求时，只要请求方没有被授予集群级的对应资源list权限，API服务器会自动遍历所有命名空间，仅返回请求方具备访问权限的命名空间下的资源，无需对上层查询逻辑做任何修改，完全适配你无法调整openapi-to-graphql封装层逻辑的场景。

具体配置步骤 #

以给default命名空间下名为custom-sa的ServiceAccount授予ns1、ns2两个命名空间下Pod的全操作权限为例，配置如下：

• 首先确认未给该SA绑定任何包含Pod list/get权限的ClusterRoleBinding，集群级权限绑定会导致全命名空间查询返回所有Pod，不符合要求。
• 按需在授权命名空间下创建权限绑定，可直接使用K8s内置ClusterRole简化配置，无需单独创建Role：

# ns1命名空间权限绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: custom-sa-pod-access
  namespace: ns1
subjects:
- kind: ServiceAccount
  name: custom-sa
  namespace: default
roleRef:
  kind: ClusterRole
  name: edit # 内置edit ClusterRole包含Pod的全操作权限，可根据需要替换为自定义ClusterRole
  apiGroup: rbac.authorization.k8s.io
---
# ns2命名空间权限绑定
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: custom-sa-pod-access
  namespace: ns2
subjects:
- kind: ServiceAccount
  name: custom-sa
  namespace: default
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

RoleBinding的作用范围仅限定在它所在的命名空间，即便是引用ClusterRole，也不会将权限升级为集群级，完全符合安全要求。

效果验证 #

使用该SA的凭证执行kubectl get pods --all-namespaces，返回结果仅包含ns1、ns2两个命名空间下的Pod，其余命名空间的Pod会被API服务器自动过滤。

细粒度资源过滤配置 #

如果需要同一命名空间下仅返回指定资源（比如特定Pod），可以在Role规则中添加resourceNames字段限制：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: ns1
  name: specific-pod-access
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
  resourceNames: ["allowed-pod-1", "allowed-pod-2"] # 仅允许访问该命名空间下的这两个Pod

配置完成后即便是查询ns1下的所有Pod，也仅会返回指定的两个Pod，其余资源会被自动过滤。

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