一文搞懂K8s中的RBAC认证授权
<h2 id="概述">概述</h2><p>官方文档：</p>
<ul>
<li>https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authorization/</li>
<li>https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/</li>
</ul>
<p>Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。</p>
<p>在K8S中，当我们试图通过API与集群资源交互时，必定经过集群资源管理对象入口kube-apiserver。显然不是随随便便来一个请求它都欢迎的，每个请求都需要经过合规检查，包括Authentication(身份验证)、Authorization(授权)和Admission Control(准入控制)。通过一系列验证后才能完成交互。</p>
<ul>
<li>Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证</li>
<li>Authorization（授权）： 判断用户是否有权限对访问的资源执行特定的动作</li>
<li>Admission Control（准入控制）：用于补充授权机制以实现更加精细的访问控制功能。</li>
</ul>
<p><img src="https://img2024.cnblogs.com/blog/3468887/202506/3468887-20250604103601622-1986456226.png" alt="image" loading="lazy"></p>
<h2 id="认证账号分类">认证账号分类</h2>
<p>在K8S体系中有两种账号类型：</p>
<ul>
<li>User accounts（用户账号），即针对human user的；</li>
<li>Service accounts（服务账号），即针对pod的。</li>
</ul>
<p>这两种账号都可以访问 API server，都需要经历认证、授权、准入控制等步骤</p>
<p>当然，除了上面两种之外，还有一个组的概念，这就是Group，主要是用于将用户或服务账号（ServiceAccount）分组，以便可以对整个组应用统一的权限策略。<br>
<img src="https://img2024.cnblogs.com/blog/3468887/202506/3468887-20250604103902948-84724301.png" alt="image" loading="lazy"></p>
<h2 id="认证管理方式">认证管理方式</h2>
<p>Kubernetes集群安全的最关键点在于如何识别并认证客户端身份，它提供了3种客户端身份认证方式：</p>
<h3 id="http-base认证">HTTP Base认证</h3>
<p>这种方式通过通过用户名+密码的方式认证。把“用户名:密码”用BASE64算法进行编码后的字符串放在HTTP请求中的Header Authorization域里发送给服务端。服务端收到后进行解码，获取用户名及密码，然后进行用户身份认证的过程。</p>
<h3 id="http-token认证">HTTP Token认证</h3>
<p>这种认证方式是用一个很长的难以被模仿的字符串--Token来表明客户身份的一种方式。每个Token对应一个用户名，当客户端发起API调用请求时，需要在HTTP Header里放入Token，API Server接到Token后会跟服务器中保存的token进行比对，然后进行用户身份认证的过程。</p>
<h3 id="https认证推荐">HTTPS认证（推荐！！）</h3>
<p>基于CA根证书签名的双向数字证书认证方式，这种认证方式是安全性最高的一种方式，也是生产环境中最常用的一种。但是同时也是操作起来最麻烦的一种方式。</p>
<h2 id="授权管理方式">授权管理方式</h2>
<p>授权发生在认证成功之后，通过认证就可以知道请求用户是谁， 然后Kubernetes会根据事先定义的授权策略来决定用户是否有权限访问，这个过程就称为授权。</p>
<p>每个发送到ApiServer的请求都带上了用户和资源的信息：比如发送请求的用户、请求的路径、请求的动作等，授权就是根据这些信息和授权策略进行比较，如果符合策略，则认为授权通过，否则会返回错误。</p>
<p>API Server目前支持以下几种授权策略：</p>
<ul>
<li>AlwaysDeny：表示拒绝所有请求，一般用于测试</li>
<li>AlwaysAllow：允许接收所有请求，相当于集群不需要授权流程（Kubernetes默认的策略）</li>
<li>ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制</li>
<li>Webhook：通过调用外部REST服务对用户进行授权</li>
<li>Node：是一种专用模式，用于对kubelet发出的请求进行访问控制</li>
<li>RBAC：基于角色的访问控制（kubeadm安装方式下的默认选项）</li>
</ul>
<h3 id="rbac介绍">RBAC介绍</h3>
<p>RBAC(Role-Based Access Control) 基于角色的访问控制，主要是在描述一件事情：给哪些对象授予了哪些权限<br>
其中涉及到了下面几个概念：</p>
<ul>
<li>对象：User、Groups、ServiceAccount</li>
<li>角色：代表着一组定义在资源上的可操作动作(权限)的集合</li>
<li>绑定：将定义好的角色跟用户绑定在一起</li>
</ul>
<p><img src="https://img2024.cnblogs.com/blog/3468887/202506/3468887-20250604104704083-1724271201.png" alt="image" loading="lazy"></p>
<p>RBAC引入了4个顶级资源对象：</p>
<ul>
<li>
<p>Role：普通角色，只能对命名空间内的资源进行授权，需要指定nameapce，可以指定一组权限</p>
</li>
<li>
<p>ClusterRole：集群角色，可以对集群范围内资源、跨namespaces的范围资源、非资源类型进行授权</p>
</li>
<li>
<p>RoleBinding：将 Role 中定义的权限绑定到特定命名空间内的用户、组或服务账户。只能引用同一命名空间中的 Role。若需在多个命名空间使用相同权限，需为每个命名空间创建单独的 RoleBinding。</p>
</li>
<li>
<p>ClusterRoleBinding：将 ClusterRole 中定义的权限绑定到集群范围内的用户、组或服务账户。</p>
</li>
</ul>
<blockquote>
<p>RoleBinding和ClusterRoleBinding区别</p>
</blockquote>
<blockquote>
<p>RoleBinding<br>
将 Role 中定义的权限绑定到特定命名空间内的用户、组或服务账户。<br>
只能引用同一命名空间中的 Role。<br>
若需在多个命名空间使用相同权限，需为每个命名空间创建单独的 RoleBinding。</p>
</blockquote>
<blockquote>
<p>ClusterRoleBinding<br>
将 ClusterRole 中定义的权限绑定到集群范围内的用户、组或服务账户。<br>
绑定的 ClusterRole 可以是集群级资源（如 Nodes）或非资源型 URL（如/healthz）。<br>
可用于授予跨命名空间的权限（如查看所有命名空间的 Pods）。</p>
</blockquote>
<blockquote>
<p>ClusterRole 与 RoleBinding 的组合<br>
虽然 ClusterRoleBinding 只能绑定 ClusterRole，但RoleBinding 可以绑定 ClusterRole，此时权限会被限制在 RoleBinding 所在的命名空间内。</p>
</blockquote>
<h2 id="role详解">Role详解</h2>
<p>在 Kubernetes 中，Role 是一种用于定义命名空间（Namespace）内权限的资源对象，属于 RBAC（基于角色的访问控制）系统的核心组件之一。通过 Role，你可以精确控制用户或服务账户对命名空间内资源的操作权限，遵循最小权限原则（Least Privilege Principle）。</p>
<h3 id="定义role资源清单">定义Role资源清单</h3>
<p>示例：</p>
<pre><code>apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
# 可选，默认为当前命名空间，对应某个空间的操作权限
namespace: default
name: develop-role
rules:
# 规则1：操作核心组和 apps 组的 pods、deployments，仅允许 get 和 list
- apiGroups: ["","apps"]
resources: ["pods","deployments"]
verbs: ["get", "list"]
# 规则2：操作核心组和 apps 组的 configmaps、secrets、daemonsets，仅允许 get 和 list
- apiGroups: ["","apps"]
resources: ["configmaps","secrets","daemonsets"]
verbs: ["get", "list"]
# 规则3：操作核心组的 secrets，允许 delete 和 create
- apiGroups: [""]
resources: ["secrets"]
verbs: ["delete","create"]
</code></pre>
<h3 id="资源清单详解">资源清单详解</h3>
<h4 id="rules权限规则列表每条规则包含">rules：权限规则列表，每条规则包含：</h4>
<ul>
<li>apiGroups：API 组（如 ""、apps、networking.k8s.io）。</li>
<li>resources：资源类型（如 pods、deployments）。</li>
<li>verbs：操作权限（如 get、create、delete）。</li>
<li>resourceNames（可选）：限定特定资源名称（如 web-pod）。</li>
<li>nonResourceURLs（可选）：非资源 URL（如 /healthz，仅 ClusterRole 支持）。</li>
</ul>
<h4 id="apigroupsapi-组分组标识">apiGroups，API 组（分组标识）</h4>
<p>作用</p>
<ul>
<li>用于标识 Kubernetes 资源所属的 API 分组，不同的资源属于不同的 API 组，便于对资源进行分类管理。</li>
<li>Kubernetes 将核心资源（如 pods、services）归为 核心组（Core Group），非核心资源（如 deployments、daemonsets）归为 非核心组（如 apps、networking.k8s.io 等）。</li>
</ul>
<p>取值规则：</p>
<ul>
<li>核心组（Core Group）：
<ul>
<li>apiGroups 取值为 <code>[""]</code>（空字符串），对应 Kubernetes API 中的 v1 版本资源。</li>
<li>常见资源：pods、services、configmaps、secrets、namespaces 等。</li>
</ul>
</li>
<li>非核心组：
<ul>
<li>apiGroups 取值为具体的组名（如 apps、batch、networking.k8s.io），对应不同 API 版本的资源。</li>
<li>常见资源：
<ul>
<li>apps 组：deployments、daemonsets、replicasets 等。</li>
<li>networking.k8s.io 组：ingresses、networkpolicies 等。</li>
<li>batch 组：jobs、cronjobs 等。</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>示例：</p>
<ul>
<li>apiGroups: [""]：匹配核心组资源（如 pods、secrets）。</li>
<li>apiGroups: ["apps"]：匹配 apps 组资源（如 deployments、daemonsets）。</li>
<li>apiGroups: ["*"]：匹配 所有 API 组（包括核心组和非核心组），需谨慎使用。集群管理员就是这一个</li>
</ul>
<h4 id="resources资源类型具体操作对象">resources：资源类型（具体操作对象）</h4>
<p>作用</p>
<ul>
<li>定义 允许操作的 Kubernetes 资源类型，需使用资源的 完整名称（不支持简称）。</li>
<li>资源类型需与 apiGroups 配合使用，例如：
<ul>
<li>apiGroups: [""] + resources: ["pods"]：操作核心组的 pods 资源。</li>
<li>apiGroups: ["apps"] + resources: ["deployments"]：操作 apps 组的 deployments 资源。</li>
</ul>
</li>
</ul>
<p>取值规则：</p>
<ul>
<li>单一资源：直接填写资源全称（如 pods、configmaps）。</li>
<li>资源集合：
<ul>
<li>使用 * 匹配 同一组下的所有资源（如 resources: ["*"]）。</li>
<li>使用 resourceName 匹配 特定名称的资源（需结合 verbs 中的 get、update 等操作）。</li>
</ul>
</li>
</ul>
<pre><code>- apiGroups: [""]
resources: ["pods"]
resourceNames: ["web-pod"]# 仅操作名为 "web-pod" 的 Pod
verbs: ["get"]
</code></pre>
<h4 id="verbs操作权限允许的动作">verbs：操作权限（允许的动作）</h4>
<p>作用</p>
<ul>
<li>定义 对指定资源允许执行的操作，用于控制用户或服务账户的行为权限。</li>
</ul>
<p>常见 verbs 分类</p>
<ul>
<li>
<p>基础操作：</p>
<ul>
<li>get：获取单个资源，如 <code>kubectl get pod <name></code></li>
<li>list：列出资源列表，如 <code>kubectl list pods</code></li>
<li>create：创建资源，如 <code>kubectl create pod</code></li>
<li>update：更新资源，如 <code>kubectl apply</code> 或 <code>kubectl edit</code></li>
<li>delete：删除资源，如 <code>kubectl delete pod <name></code></li>
</ul>
</li>
<li>
<p>高级操作：</p>
<ul>
<li>patch：部分更新资源，如 <code>kubectl patch pod <name> -p '{"spec": {...}}'）</code></li>
<li>watch：监控资源变化，如 <code>kubectl get pods --watch</code></li>
<li>exec：进入 Pod 执行命令，如 <code>kubectl exec -it <pod> /bin/sh</code></li>
<li>connect：建立连接，如 <code>kubectl port-forward</code></li>
</ul>
</li>
<li>
<p>特殊操作：</p>
</li>
<li>
<p>*：允许所有操作（需谨慎使用）。</p>
</li>
<li>
<p>list 和 watch 通常配合使用，用于实现资源监控（如 Dashboard 或控制器）。</p>
</li>
</ul>
<p>示例：</p>
<ul>
<li>verbs: ["get", "list"]：允许查看资源（获取单个或列表）。</li>
<li>verbs: ["create", "delete"]：允许创建和删除资源。</li>
<li>verbs: ["*"]：允许对资源执行所有操作（危险操作，仅用于测试或管理员角色）。</li>
</ul>
<h3 id="role实战">Role实战</h3>
<pre><code># 定义Role
# cat role-default.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: custom-role
rules:
# 规则1：操作核心组和 apps 组的 pods、deployments，仅允许 get 和 list
- apiGroups: ["","apps"]
resources: ["pods","deployments"]
verbs: ["get", "list"]
# 规则2：操作核心组和 apps 组的 configmaps、secrets、daemonsets，仅允许 get 和 list
- apiGroups: ["","apps"]
resources: ["configmaps","secrets","daemonsets"]
verbs: ["get", "list"]
# 规则3：操作核心组的 secrets，允许 delete 和 create
- apiGroups: [""]
resources: ["secrets"]
verbs: ["delete","create"]
# 创建Role
# kubectl apply -f role-default.yaml
role.rbac.authorization.k8s.io/custom-role created
</code></pre>
<p>查看Role</p>
<pre><code># 查看Role
# kubectl get role -o wide
NAME CREATED AT
custom-role 2025-06-07T06:34:52Z
# kubectl describe role custom-role
Name: custom-role
Labels: <none>
Annotations:<none>
PolicyRule:
Resources Non-Resource URLsResource NamesVerbs
--------- ------------------------------------
secrets [] []
configmaps [] []
daemonsets [] []
deployments [] []
pods [] []
configmaps.apps [] []
daemonsets.apps [] []
deployments.apps[] []
pods.apps [] []
secrets.apps [] []
</code></pre>
<h2 id="clusterrole详解">ClusterRole详解</h2>
<p>在 Kubernetes 中，ClusterRole 是一种用于定义集群级别权限的资源对象，属于 RBAC（基于角色的访问控制）系统的核心组件之一。与只能作用于单个命名空间的 Role 不同，ClusterRole 可以跨命名空间授权，或用于集群级资源（如节点、命名空间）的访问控制。</p>
<h3 id="核心概念">核心概念</h3>
<p>ClusterRole 是一个 集群级别的资源，用于定义对 集群范围资源 或 非资源 URL 的操作权限。<br>
可以用于以下场景：</p>
<ul>
<li>对集群级资源（如 Node、PersistentVolume）的访问控制。</li>
<li>对所有命名空间资源（如 Pod、Deployment）的跨命名空间访问。</li>
<li>对非资源端点（如 /healthz、/metrics）的访问控制。</li>
</ul>
<h3 id="clusterrole资源清单文件">ClusterRole资源清单文件</h3>
<p>ClusterRole资源清单文件和上述Role是一致的</p>
<pre><code>apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: <clusterrole-name># ClusterRole 的名称
rules:
- apiGroups: [""]# API 组列表
resources: ["nodes"]# 资源类型列表（集群级资源）
verbs: ["get", "list", "watch"]# 操作权限
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["*"]# 所有操作权限
resourceNames: ["backend"]# 可选，限定特定资源名称
- nonResourceURLs: ["/healthz", "/metrics"]# 非资源 URL（仅 ClusterRole 支持）
verbs: ["get"]
</code></pre>
<h3 id="clusterrole实战">ClusterRole实战</h3>
<pre><code># 定义ClusterRole
# cat ClusterRole-1.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: custom-clusterrole
rules:
# 规则1：操作核心组和 apps 组的 pods、deployments，仅允许 get 和 list
- apiGroups: ["","apps"]
resources: ["pods","deployments"]
verbs: ["get", "list"]
# 规则2：操作核心组和 apps 组的 configmaps、secrets、daemonsets，仅允许 get 和 list
- apiGroups: ["","apps"]
resources: ["configmaps","secrets","daemonsets"]
verbs: ["get", "list"]
# 规则3：操作核心组的 secrets，允许 delete 和 create
- apiGroups: [""]
resources: ["secrets"]
verbs: ["delete","create"]
# 创建Role
# kubectl apply -f ClusterRole-1.yaml
clusterrole.rbac.authorization.k8s.io/custom-clusterrole created
</code></pre>
<p>查看ClusterRole</p>
<pre><code># 查看Role
# kubectl get clusterrole custom-clusterrole
NAME CREATED AT
custom-clusterrole 2025-06-07T06:44:54Z
# kubectl describe clusterrole custom-clusterrole
Name: custom-clusterrole
Labels: <none>
Annotations:<none>
PolicyRule:
Resources Non-Resource URLsResource NamesVerbs
--------- ------------------------------------
secrets [] []
configmaps [] []
daemonsets [] []
deployments [] []
pods [] []
configmaps.apps [] []
daemonsets.apps [] []
deployments.apps[] []
pods.apps [] []
secrets.apps [] []
</code></pre>
<h3 id="集群中默认的clusterrole">集群中默认的ClusterRole</h3>
<pre><code># kubectl get clusterrole | grep -v system
NAME CREATED AT
admin 2025-05-24T05:57:58Z
calico-cni-plugin 2025-05-24T05:58:41Z
calico-crds 2025-05-24T05:59:30Z
calico-extension-apiserver-auth-access 2025-05-24T05:59:30Z
calico-kube-controllers 2025-05-24T05:58:41Z
calico-node 2025-05-24T05:58:41Z
calico-typha 2025-05-24T05:58:40Z
calico-webhook-reader 2025-05-24T05:59:30Z
cluster-admin 2025-05-24T05:57:57Z
custom-clusterrole 2025-06-07T06:44:54Z
edit 2025-05-24T05:57:58Z
kubeadm:get-nodes 2025-05-24T05:57:59Z
tigera-operator 2025-05-24T05:58:37Z
view 2025-05-24T05:57:58Z
</code></pre>
<p>其中主要关注这四个</p>
<ul>
<li>admin:主要用于授权命名空间的读写权限</li>
<li>cluster-admin:超级管理员，拥有集群的所有权限</li>
<li>edit:允许对大多数对象读写操作，不允许查看或者修改角色，角色绑定。</li>
<li>view:允许对命名空间大多数对象只读权限，不允许查看角色，角色绑定和secret</li>
</ul>
<h2 id="rolebinding详解">RoleBinding详解</h2>
<p>在 Kubernetes（K8s）中，RoleBinding 是实现权限控制（RBAC，Role-Based Access Control）的核心资源之一，用于将角色（Role）与用户、服务账户或组关联起来，从而赋予其对特定资源的操作权限。</p>
<p>RoleBinding 仅在单个命名空间内生效，用于授予对命名空间内资源的访问权限（如 Pod、Service 等）。</p>
<p>若需跨命名空间或集群级权限（如管理节点、命名空间本身），需使用 ClusterRoleBinding（关联 ClusterRole）。</p>
<h3 id="作用">作用</h3>
<p>将 Role（角色）定义的权限授予 主体（Subjects），主体可以是：</p>
<ul>
<li>用户账户（User Accounts）：K8s 中的外部用户（如管理员、开发人员），通常通过认证插件（如 X509、OIDC）管理。</li>
<li>服务账户（Service Accounts）：K8s 内部用于 Pod 中容器访问 API 的账户，自动创建于命名空间中。</li>
<li>组（Groups）：用户组（如通过认证插件定义的组），用于批量授权。</li>
</ul>
<h3 id="rolebinding资源清单文件">RoleBinding资源清单文件</h3>
<pre><code>apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developer-rolebinding# RoleBinding 名称
namespace: dev-namespace # 作用的命名空间
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role # 引用的角色类型（必须是 Role 或 ClusterRole）
name: developer # 引用的角色名称
subjects: # 被授权的主体列表
- kind: User # 主体类型（User/ServiceAccount/Group）
name: alice # 主体名称
apiGroup: "" # User 和 Group 的 apiGroup 为空
- kind: ServiceAccount
name: my-app-sa
namespace: dev-namespace# 服务账户所在的命名空间（若与 RoleBinding 同命名空间可省略）
- kind: Group
name: my-group # 组名
apiGroup: ""
</code></pre>
<h4 id="字段说明">字段说明</h4>
<ul>
<li>metadata
<ul>
<li>namespace：必填，指定 RoleBinding 生效的命名空间。</li>
<li>name：RoleBinding 的唯一名称。</li>
</ul>
</li>
<li>roleRef：引用要绑定的角色，支持两种类型：
<ul>
<li>Role：命名空间内的角色，授予对该命名空间内资源的权限。</li>
<li>ClusterRole：集群级角色，可通过 RoleBinding 绑定到命名空间，授予该命名空间内资源的权限（需角色定义中包含命名空间作用域的规则）。</li>
</ul>
</li>
<li>subjects：定义被授权的主体，每个主体包含：
<ul>
<li>kind：主体类型，取值为 User、ServiceAccount 或 Group。</li>
<li>name：主体名称（如用户名、服务账户名、组名）。</li>
<li>namespace：仅当主体为服务账户且与 RoleBinding 不在同一命名空间时需指定。</li>
</ul>
</li>
</ul>
<h3 id="rolebinding与clusterrole">RoleBinding与ClusterRole</h3>
<p>虽然 RoleBinding 通常绑定 Role，但也可以绑定 ClusterRole，前提是该 ClusterRole 的规则适用于命名空间内的资源。例如：</p>
<pre><code># 使用 ClusterRole 定义命名空间内权限
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: namespace-pod-reader
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "list", "watch"]
resourceNames: []# 不限制具体资源名称，作用于整个命名空间
# 通过 RoleBinding 将 ClusterRole 绑定到命名空间
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: clusterrole-binding
namespace: dev-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole# 引用集群级角色
name: namespace-pod-reader
subjects:
- kind: User
name: charlie
apiGroup: ""
</code></pre>
<h2 id="clusterrolebinding详解">ClusterRoleBinding详解</h2>
<p>在 Kubernetes（K8s）中，ClusterRoleBinding 是实现集群级权限控制的核心资源，用于将集群级角色（ClusterRole）与用户、服务账户或组关联，从而赋予其跨命名空间或集群级资源的访问权限。</p>
<p>ClusterRoleBinding 不局限于单个命名空间，而是对整个集群生，可用于授权对集群级资源（如 Nodes、Namespaces、PersistentVolumes）或所有命名空间资源（如所有 Pod、ConfigMaps）的访问。</p>
<h3 id="作用-1">作用</h3>
<p>将 ClusterRole 定义的权限授予 主体（Subjects），主体可以是：</p>
<ul>
<li>用户账户（User Accounts）：K8s 中的外部用户（如集群管理员）。</li>
<li>服务账户（Service Accounts）：K8s 内部用于 Pod 中容器访问 API 的账户。</li>
<li>组（Groups）：用户组（如通过认证插件定义的组）。</li>
</ul>
<h3 id="clusterrolebinding资源清单文件">ClusterRoleBinding资源清单文件</h3>
<pre><code>apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin-binding# ClusterRoleBinding 名称
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole# 必须是 ClusterRole
name: cluster-admin# 引用的 ClusterRole 名称
subjects:
- kind: User # 主体类型
name: admin-user# 用户名
apiGroup: ""
- kind: Group
name: system:serviceaccounts# 所有服务账户所在的组
apiGroup: ""
</code></pre>
<h4 id="字段说明-1">字段说明</h4>
<ul>
<li>metadata
<ul>
<li>name：ClusterRoleBinding 的唯一名称（集群级别）。</li>
</ul>
</li>
<li>roleRef
<ul>
<li>引用要绑定的集群角色，必须是 ClusterRole，不能是普通 Role。</li>
<li>ClusterRole 可以是：
<ul>
<li>集群级资源权限（如管理节点、命名空间）。</li>
<li>所有命名空间资源的权限（如查看所有命名空间中的 Pod）。</li>
<li>非资源端点权限（如 /healthz、/metrics）。</li>
</ul>
</li>
</ul>
</li>
<li>subjects
<ul>
<li>定义被授权的主体，结构与 RoleBinding 相同，但服务账户需指定命名空间（若有）。</li>
</ul>
</li>
</ul>
<h2 id="role和clusterrole的区别">Role和ClusterRole的区别</h2>
<table>
<thead>
<tr>
<th>特性</th>
<th>Role</th>
<th>ClusterRole</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>作用范围</strong></td>
<td>单个命名空间内</td>
<td>集群范围（所有命名空间或集群级资源）</td>
</tr>
<tr>
<td><strong>定义位置</strong></td>
<td>属于命名空间资源（需指定 namespace）</td>
<td>集群级资源（无需 namespace 字段）</td>
</tr>
<tr>
<td><strong>可授权的资源类型</strong></td>
<td>命名空间内资源（如 Pod、Service）</td>
<td>1. 集群级资源（如 Nodes、Namespaces）<br>2. 所有命名空间的资源（如所有 Pod）<br>3. 非资源端点（如 /healthz、/metrics）</td>
</tr>
<tr>
<td><strong>绑定方式</strong></td>
<td>通过 RoleBinding 绑定到主体</td>
<td>1. 通过 RoleBinding 绑定到单个命名空间（需角色规则适用于命名空间资源）<br>2. 通过 ClusterRoleBinding 绑定到整个集群</td>
</tr>
<tr>
<td><strong>典型场景</strong></td>
<td>授权命名空间内的操作（如开发人员管理自己命名空间的资源）</td>
<td>1. 集群管理员权限<br>2. 跨命名空间操作<br>3. 访问集群级资源</td>
</tr>
</tbody>
</table>
<h2 id="rolebinding和clusterrolebinding的区别">RoleBinding和ClusterRoleBinding的区别</h2>
<table>
<thead>
<tr>
<th>特性</th>
<th>RoleBinding</th>
<th>ClusterRoleBinding</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>作用范围</strong></td>
<td>单个命名空间内</td>
<td>集群范围（所有命名空间或集群级资源）</td>
</tr>
<tr>
<td><strong>绑定的角色类型</strong></td>
<td>1. Role（命名空间内角色）<br>2. ClusterRole（需角色规则适用于命名空间资源）</td>
<td>仅 ClusterRole（集群级角色）</td>
</tr>
<tr>
<td><strong>定义位置</strong></td>
<td>属于命名空间资源（需指定 namespace）</td>
<td>集群级资源（无需 namespace 字段）</td>
</tr>
<tr>
<td><strong>典型场景</strong></td>
<td>授权用户/服务账户操作特定命名空间内的资源（如开发人员管理 dev 命名空间的 Pod）</td>
<td>1. 集群管理员权限<br>2. 跨命名空间操作<br>3. 访问集群级资源（如 Nodes）</td>
</tr>
</tbody>
</table>
</div>
<div id="MySignature" role="contentinfo">
<p>本文来自博客园，作者：huangSir-devops，转载请注明原文链接：https://www.cnblogs.com/huangSir-devops/p/18908560，微信Vac6666666，欢迎交流</p><br><br>
来源：https://www.cnblogs.com/huangSir-devops/p/18908560
頁:
[1]