针对Kubernetes Raw API资源类型，应使用何种RBAC角色资源类型？

核心逻辑 #

Kubernetes的Raw API路径对应明确的API资源与子资源关系，无需使用宽泛的通配符权限，可通过精准匹配资源/子资源组合配置RBAC，兼顾权限需求与安全性。

以你提到的/api/v1/nodes/{node-name}/proxy/stats/summary调用为例，该路径对应核心API组（apiGroups: [""]）下nodes资源的proxy子资源，只需针对此具体组合配置权限即可。

精准ClusterRole配置（替代全通配符方案） #

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: node-proxy-stats-reader
rules:
  - apiGroups: [""]
    resources: ["nodes/proxy"]
    verbs: ["get"]

• apiGroups: [""]：对应Kubernetes核心API组（/api/v1路径属于核心组）
• resources: ["nodes/proxy"]：明确指定nodes资源的proxy子资源，匹配所有节点的proxy路径
• verbs: ["get"]：仅授予GET权限，适配你的kubectl get --raw和Go客户端的GET请求

Go客户端调用的RBAC适配 #

你提供的Go客户端Raw API调用：

content, err := clientset.RESTClient().Get().AbsPath(fmt.Sprintf("/api/v1/nodes/%s/proxy/stats/summary", currentNode)).DoRaw(context.Background())

对应的RBAC权限与上述ClusterRole完全一致，因为本质是调用同一API端点。只需将该ClusterRole绑定到对应的ServiceAccount（或用户/组）即可生效。

示例：绑定ClusterRole到ServiceAccount #

如果要给指定ServiceAccount授权，创建ClusterRoleBinding：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bind-node-proxy-stats-reader
subjects:
  - kind: ServiceAccount
    name: your-service-account
    namespace: your-namespace
roleRef:
  kind: ClusterRole
  name: node-proxy-stats-reader
  apiGroup: rbac.authorization.k8s.io

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