登录/ 注册
 找回密码
 立即注册
关闭

CSDN热搜

程序园 精品问答 技术交流 资源下载
返回列表 发新帖
首页 › 业界区 › 科技 ›一文搞懂K8s中的RBAC认证授权

一文搞懂K8s中的RBAC认证授权

堠秉 2025-6-8 11:37:09
概述

官方文档：

  • https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authorization/
  • https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/
Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。所谓的安全性其实就是保证对Kubernetes的各种客户端进行认证和鉴权操作。
在K8S中，当我们试图通过API与集群资源交互时，必定经过集群资源管理对象入口kube-apiserver。显然不是随随便便来一个请求它都欢迎的，每个请求都需要经过合规检查，包括Authentication(身份验证)、Authorization(授权)和Admission Control(准入控制)。通过一系列验证后才能完成交互。

  • Authentication（认证）：身份鉴别，只有正确的账号才能够通过认证
  • Authorization（授权）： 判断用户是否有权限对访问的资源执行特定的动作
  • Admission Control（准入控制）：用于补充授权机制以实现更加精细的访问控制功能。
1.png

认证账号分类

在K8S体系中有两种账号类型：

  • User accounts（用户账号），即针对human user的；
  • Service accounts（服务账号），即针对pod的。
这两种账号都可以访问 API server，都需要经历认证、授权、准入控制等步骤
当然，除了上面两种之外，还有一个组的概念，这就是Group，主要是用于将用户或服务账号（ServiceAccount）分组，以便可以对整个组应用统一的权限策略。
2.png

认证管理方式

Kubernetes集群安全的最关键点在于如何识别并认证客户端身份，它提供了3种客户端身份认证方式：
HTTP Base认证

这种方式通过通过用户名+密码的方式认证。把“用户名:密码”用BASE64算法进行编码后的字符串放在HTTP请求中的Header Authorization域里发送给服务端。服务端收到后进行解码，获取用户名及密码，然后进行用户身份认证的过程。
HTTP Token认证

这种认证方式是用一个很长的难以被模仿的字符串--Token来表明客户身份的一种方式。每个Token对应一个用户名，当客户端发起API调用请求时，需要在HTTP Header里放入Token，API Server接到Token后会跟服务器中保存的token进行比对，然后进行用户身份认证的过程。
HTTPS认证（推荐！！）

基于CA根证书签名的双向数字证书认证方式，这种认证方式是安全性最高的一种方式，也是生产环境中最常用的一种。但是同时也是操作起来最麻烦的一种方式。
授权管理方式

授权发生在认证成功之后，通过认证就可以知道请求用户是谁， 然后Kubernetes会根据事先定义的授权策略来决定用户是否有权限访问，这个过程就称为授权。
每个发送到ApiServer的请求都带上了用户和资源的信息：比如发送请求的用户、请求的路径、请求的动作等，授权就是根据这些信息和授权策略进行比较，如果符合策略，则认为授权通过，否则会返回错误。
API Server目前支持以下几种授权策略：

  • AlwaysDeny：表示拒绝所有请求，一般用于测试
  • AlwaysAllow：允许接收所有请求，相当于集群不需要授权流程（Kubernetes默认的策略）
  • ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
  • Webhook：通过调用外部REST服务对用户进行授权
  • Node：是一种专用模式，用于对kubelet发出的请求进行访问控制
  • RBAC：基于角色的访问控制（kubeadm安装方式下的默认选项）
RBAC介绍

RBAC(Role-Based Access Control) 基于角色的访问控制，主要是在描述一件事情：给哪些对象授予了哪些权限
其中涉及到了下面几个概念：

  • 对象：User、Groups、ServiceAccount
  • 角色：代表着一组定义在资源上的可操作动作(权限)的集合
  • 绑定：将定义好的角色跟用户绑定在一起
3.png

RBAC引入了4个顶级资源对象：

  • Role：普通角色，只能对命名空间内的资源进行授权，需要指定nameapce，可以指定一组权限
  • ClusterRole：集群角色，可以对集群范围内资源、跨namespaces的范围资源、非资源类型进行授权
  • RoleBinding：将 Role 中定义的权限绑定到特定命名空间内的用户、组或服务账户。只能引用同一命名空间中的 Role。若需在多个命名空间使用相同权限，需为每个命名空间创建单独的 RoleBinding。
  • ClusterRoleBinding：将 ClusterRole 中定义的权限绑定到集群范围内的用户、组或服务账户。
RoleBinding和ClusterRoleBinding区别
RoleBinding
将 Role 中定义的权限绑定到特定命名空间内的用户、组或服务账户。
只能引用同一命名空间中的 Role。
若需在多个命名空间使用相同权限，需为每个命名空间创建单独的 RoleBinding。
ClusterRoleBinding
将 ClusterRole 中定义的权限绑定到集群范围内的用户、组或服务账户。
绑定的 ClusterRole 可以是集群级资源（如 Nodes）或非资源型 URL（如/healthz）。
可用于授予跨命名空间的权限（如查看所有命名空间的 Pods）。
ClusterRole 与 RoleBinding 的组合
虽然 ClusterRoleBinding 只能绑定 ClusterRole，但RoleBinding 可以绑定 ClusterRole，此时权限会被限制在 RoleBinding 所在的命名空间内。
Role详解

在 Kubernetes 中，Role 是一种用于定义命名空间（Namespace）内权限的资源对象，属于 RBAC（基于角色的访问控制）系统的核心组件之一。通过 Role，你可以精确控制用户或服务账户对命名空间内资源的操作权限，遵循最小权限原则（Least Privilege Principle）。
定义Role资源清单

示例：
  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: Role
  3. metadata:
  4.   # 可选，默认为当前命名空间，对应某个空间的操作权限
  5.   namespace: default
  6.   name: develop-role
  7. rules:
  8.   # 规则1：操作核心组和 apps 组的 pods、deployments，仅允许 get 和 list
  9. - apiGroups: ["","apps"]
  10.   resources: ["pods","deployments"]
  11.   verbs: ["get", "list"]
  12.   
  13.   # 规则2：操作核心组和 apps 组的 configmaps、secrets、daemonsets，仅允许 get 和 list
  14. - apiGroups: ["","apps"]
  15.   resources: ["configmaps","secrets","daemonsets"]
  16.   verbs: ["get", "list"]
  17.   
  18.   # 规则3：操作核心组的 secrets，允许 delete 和 create
  19. - apiGroups: [""]
  20.   resources: ["secrets"]
  21.   verbs: ["delete","create"]
复制代码
资源清单详解

rules：权限规则列表，每条规则包含：


  • apiGroups：API 组（如 ""、apps、networking.k8s.io）。
  • resources：资源类型（如 pods、deployments）。
  • verbs：操作权限（如 get、create、delete）。
  • resourceNames（可选）：限定特定资源名称（如 web-pod）。
  • nonResourceURLs（可选）：非资源 URL（如 /healthz，仅 ClusterRole 支持）。
apiGroups，API 组（分组标识）

作用

  • 用于标识 Kubernetes 资源所属的 API 分组，不同的资源属于不同的 API 组，便于对资源进行分类管理。
  • Kubernetes 将核心资源（如 pods、services）归为 核心组（Core Group），非核心资源（如 deployments、daemonsets）归为 非核心组（如 apps、networking.k8s.io 等）。
取值规则：

  • 核心组（Core Group）：

    • apiGroups 取值为 [""]（空字符串），对应 Kubernetes API 中的 v1 版本资源。
    • 常见资源：pods、services、configmaps、secrets、namespaces 等。

  • 非核心组：

    • apiGroups 取值为具体的组名（如 apps、batch、networking.k8s.io），对应不同 API 版本的资源。
    • 常见资源：

      • apps 组：deployments、daemonsets、replicasets 等。
      • networking.k8s.io 组：ingresses、networkpolicies 等。
      • batch 组：jobs、cronjobs 等。


示例：

  • apiGroups: [""]：匹配核心组资源（如 pods、secrets）。
  • apiGroups: ["apps"]：匹配 apps 组资源（如 deployments、daemonsets）。
  • apiGroups: ["*"]：匹配 所有 API 组（包括核心组和非核心组），需谨慎使用。集群管理员就是这一个
resources：资源类型（具体操作对象）

作用

  • 定义 允许操作的 Kubernetes 资源类型，需使用资源的 完整名称（不支持简称）。
  • 资源类型需与 apiGroups 配合使用，例如：

    • apiGroups: [""] + resources: ["pods"]：操作核心组的 pods 资源。
    • apiGroups: ["apps"] + resources: ["deployments"]：操作 apps 组的 deployments 资源。

取值规则：

  • 单一资源：直接填写资源全称（如 pods、configmaps）。
  • 资源集合：

    • 使用 * 匹配 同一组下的所有资源（如 resources: ["*"]）。
    • 使用 resourceName 匹配 特定名称的资源（需结合 verbs 中的 get、update 等操作）。

  1. - apiGroups: [""]
  2.   resources: ["pods"]
  3.   resourceNames: ["web-pod"]  # 仅操作名为 "web-pod" 的 Pod
  4.   verbs: ["get"]
复制代码
verbs：操作权限（允许的动作）

作用

  • 定义 对指定资源允许执行的操作，用于控制用户或服务账户的行为权限。
常见 verbs 分类

  • 基础操作：

    • get：获取单个资源，如 kubectl get pod
    • list：列出资源列表，如 kubectl list pods
    • create：创建资源，如 kubectl create pod
    • update：更新资源，如 kubectl apply 或 kubectl edit
    • delete：删除资源，如 kubectl delete pod

  • 高级操作：

    • patch：部分更新资源，如 kubectl patch pod  -p '{"spec": {...}}'）
    • watch：监控资源变化，如 kubectl get pods --watch
    • exec：进入 Pod 执行命令，如 kubectl exec -it  /bin/sh
    • connect：建立连接，如 kubectl port-forward

  • 特殊操作：
  • *：允许所有操作（需谨慎使用）。
  • list 和 watch 通常配合使用，用于实现资源监控（如 Dashboard 或控制器）。
示例：

  • verbs: ["get", "list"]：允许查看资源（获取单个或列表）。
  • verbs: ["create", "delete"]：允许创建和删除资源。
  • verbs: ["*"]：允许对资源执行所有操作（危险操作，仅用于测试或管理员角色）。
Role实战
  1. # 定义Role
  2. [root@master ~/role]# cat role-default.yaml
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. kind: Role
  5. metadata:
  6.   namespace: default
  7.   name: custom-role
  8. rules:
  9.   # 规则1：操作核心组和 apps 组的 pods、deployments，仅允许 get 和 list
  10. - apiGroups: ["","apps"]
  11.   resources: ["pods","deployments"]
  12.   verbs: ["get", "list"]
  14.   # 规则2：操作核心组和 apps 组的 configmaps、secrets、daemonsets，仅允许 get 和 list
  15. - apiGroups: ["","apps"]
  16.   resources: ["configmaps","secrets","daemonsets"]
  17.   verbs: ["get", "list"]
  19.   # 规则3：操作核心组的 secrets，允许 delete 和 create
  20. - apiGroups: [""]
  21.   resources: ["secrets"]
  22.   verbs: ["delete","create"]
  24. # 创建Role
  25. [root@master ~/role]# kubectl apply -f role-default.yaml
  26. role.rbac.authorization.k8s.io/custom-role created
复制代码
查看Role
  1. # 查看Role
  2. [root@master ~/role]# kubectl get role -o wide
  3. NAME          CREATED AT
  4. custom-role   2025-06-07T06:34:52Z
  5. [root@master ~/role]# kubectl describe role custom-role
  6. Name:         custom-role
  7. Labels:       <none>
  8. Annotations:  <none>
  9. PolicyRule:
  10.   Resources         Non-Resource URLs  Resource Names  Verbs
  11.   ---------         -----------------  --------------  -----
  12.   secrets           []                 []              [get list delete create]
  13.   configmaps        []                 []              [get list]
  14.   daemonsets        []                 []              [get list]
  15.   deployments       []                 []              [get list]
  16.   pods              []                 []              [get list]
  17.   configmaps.apps   []                 []              [get list]
  18.   daemonsets.apps   []                 []              [get list]
  19.   deployments.apps  []                 []              [get list]
  20.   pods.apps         []                 []              [get list]
  21.   secrets.apps      []                 []              [get list]
复制代码
ClusterRole详解

在 Kubernetes 中，ClusterRole 是一种用于定义集群级别权限的资源对象，属于 RBAC（基于角色的访问控制）系统的核心组件之一。与只能作用于单个命名空间的 Role 不同，ClusterRole 可以跨命名空间授权，或用于集群级资源（如节点、命名空间）的访问控制。
核心概念

ClusterRole 是一个 集群级别的资源，用于定义对 集群范围资源 或 非资源 URL 的操作权限。
可以用于以下场景：

  • 对集群级资源（如 Node、PersistentVolume）的访问控制。
  • 对所有命名空间资源（如 Pod、Deployment）的跨命名空间访问。
  • 对非资源端点（如 /healthz、/metrics）的访问控制。
ClusterRole资源清单文件

ClusterRole资源清单文件和上述Role是一致的
  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: ClusterRole
  3. metadata:
  4.   name: <clusterrole-name>  # ClusterRole 的名称
  5. rules:
  6. - apiGroups: [""]  # API 组列表
  7.   resources: ["nodes"]  # 资源类型列表（集群级资源）
  8.   verbs: ["get", "list", "watch"]  # 操作权限
  9. - apiGroups: ["apps"]
  10.   resources: ["deployments"]
  11.   verbs: ["*"]  # 所有操作权限
  12.   resourceNames: ["backend"]  # 可选，限定特定资源名称
  13. - nonResourceURLs: ["/healthz", "/metrics"]  # 非资源 URL（仅 ClusterRole 支持）
  14.   verbs: ["get"]
复制代码
ClusterRole实战
  1. # 定义ClusterRole
  2. [root@master ~/role]# cat ClusterRole-1.yaml
  3. apiVersion: rbac.authorization.k8s.io/v1
  4. kind: ClusterRole
  5. metadata:
  6.   name: custom-clusterrole
  7. rules:
  8.   # 规则1：操作核心组和 apps 组的 pods、deployments，仅允许 get 和 list
  9. - apiGroups: ["","apps"]
  10.   resources: ["pods","deployments"]
  11.   verbs: ["get", "list"]
  13.   # 规则2：操作核心组和 apps 组的 configmaps、secrets、daemonsets，仅允许 get 和 list
  14. - apiGroups: ["","apps"]
  15.   resources: ["configmaps","secrets","daemonsets"]
  16.   verbs: ["get", "list"]
  18.   # 规则3：操作核心组的 secrets，允许 delete 和 create
  19. - apiGroups: [""]
  20.   resources: ["secrets"]
  21.   verbs: ["delete","create"]
  24. # 创建Role
  25. [root@master ~/role]# kubectl apply -f ClusterRole-1.yaml
  26. clusterrole.rbac.authorization.k8s.io/custom-clusterrole created
复制代码
查看ClusterRole
  1. # 查看Role
  2. [root@master ~/role]# kubectl get clusterrole custom-clusterrole
  3. NAME                 CREATED AT
  4. custom-clusterrole   2025-06-07T06:44:54Z
  6. [root@master ~/role]# kubectl describe clusterrole custom-clusterrole
  7. Name:         custom-clusterrole
  8. Labels:       <none>
  9. Annotations:  <none>
  10. PolicyRule:
  11.   Resources         Non-Resource URLs  Resource Names  Verbs
  12.   ---------         -----------------  --------------  -----
  13.   secrets           []                 []              [get list delete create]
  14.   configmaps        []                 []              [get list]
  15.   daemonsets        []                 []              [get list]
  16.   deployments       []                 []              [get list]
  17.   pods              []                 []              [get list]
  18.   configmaps.apps   []                 []              [get list]
  19.   daemonsets.apps   []                 []              [get list]
  20.   deployments.apps  []                 []              [get list]
  21.   pods.apps         []                 []              [get list]
  22.   secrets.apps      []                 []              [get list]
复制代码
集群中默认的ClusterRole
  1. [root@master ~/role]# kubectl get clusterrole | grep -v system
  2. NAME                                                                   CREATED AT
  3. admin                                                                  2025-05-24T05:57:58Z
  4. calico-cni-plugin                                                      2025-05-24T05:58:41Z
  5. calico-crds                                                            2025-05-24T05:59:30Z
  6. calico-extension-apiserver-auth-access                                 2025-05-24T05:59:30Z
  7. calico-kube-controllers                                                2025-05-24T05:58:41Z
  8. calico-node                                                            2025-05-24T05:58:41Z
  9. calico-typha                                                           2025-05-24T05:58:40Z
  10. calico-webhook-reader                                                  2025-05-24T05:59:30Z
  11. cluster-admin                                                          2025-05-24T05:57:57Z
  12. custom-clusterrole                                                     2025-06-07T06:44:54Z
  13. edit                                                                   2025-05-24T05:57:58Z
  14. kubeadm:get-nodes                                                      2025-05-24T05:57:59Z
  15. tigera-operator                                                        2025-05-24T05:58:37Z
  16. view                                                                   2025-05-24T05:57:58Z
复制代码
其中主要关注这四个

  • admin:主要用于授权命名空间的读写权限
  • cluster-admin:超级管理员，拥有集群的所有权限
  • edit:允许对大多数对象读写操作，不允许查看或者修改角色，角色绑定。
  • view:允许对命名空间大多数对象只读权限，不允许查看角色，角色绑定和secret
RoleBinding详解

在 Kubernetes（K8s）中，RoleBinding 是实现权限控制（RBAC，Role-Based Access Control）的核心资源之一，用于将角色（Role）与用户、服务账户或组关联起来，从而赋予其对特定资源的操作权限。
RoleBinding 仅在单个命名空间内生效，用于授予对命名空间内资源的访问权限（如 Pod、Service 等）。
若需跨命名空间或集群级权限（如管理节点、命名空间本身），需使用 ClusterRoleBinding（关联 ClusterRole）。
作用

将 Role（角色）定义的权限授予 主体（Subjects），主体可以是：

  • 用户账户（User Accounts）：K8s 中的外部用户（如管理员、开发人员），通常通过认证插件（如 X509、OIDC）管理。
  • 服务账户（Service Accounts）：K8s 内部用于 Pod 中容器访问 API 的账户，自动创建于命名空间中。
  • 组（Groups）：用户组（如通过认证插件定义的组），用于批量授权。
RoleBinding资源清单文件
  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: RoleBinding
  3. metadata:
  4.   name: developer-rolebinding  # RoleBinding 名称
  5.   namespace: dev-namespace   # 作用的命名空间
  6. roleRef:
  7.   apiGroup: rbac.authorization.k8s.io
  8.   kind: Role         # 引用的角色类型（必须是 Role 或 ClusterRole）
  9.   name: developer    # 引用的角色名称
  10. subjects:          # 被授权的主体列表
  11. - kind: User        # 主体类型（User/ServiceAccount/Group）
  12.   name: alice       # 主体名称
  13.   apiGroup: ""      # User 和 Group 的 apiGroup 为空
  14. - kind: ServiceAccount
  15.   name: my-app-sa
  16.   namespace: dev-namespace  # 服务账户所在的命名空间（若与 RoleBinding 同命名空间可省略）
  17. - kind: Group
  18.   name: my-group            # 组名
  19.   apiGroup: ""
复制代码
字段说明


  • metadata

    • namespace：必填，指定 RoleBinding 生效的命名空间。
    • name：RoleBinding 的唯一名称。

  • roleRef：引用要绑定的角色，支持两种类型：

    • Role：命名空间内的角色，授予对该命名空间内资源的权限。
    • ClusterRole：集群级角色，可通过 RoleBinding 绑定到命名空间，授予该命名空间内资源的权限（需角色定义中包含命名空间作用域的规则）。

  • subjects：定义被授权的主体，每个主体包含：

    • kind：主体类型，取值为 User、ServiceAccount 或 Group。
    • name：主体名称（如用户名、服务账户名、组名）。
    • namespace：仅当主体为服务账户且与 RoleBinding 不在同一命名空间时需指定。

RoleBinding与ClusterRole

虽然 RoleBinding 通常绑定 Role，但也可以绑定 ClusterRole，前提是该 ClusterRole 的规则适用于命名空间内的资源。例如：
  1. # 使用 ClusterRole 定义命名空间内权限
  2. apiVersion: rbac.authorization.k8s.io/v1
  3. kind: ClusterRole
  4. metadata:
  5.   name: namespace-pod-reader
  6. rules:
  7. - apiGroups: [""]
  8.   resources: ["pods", "services"]
  9.   verbs: ["get", "list", "watch"]
  10.   resourceNames: []  # 不限制具体资源名称，作用于整个命名空间
  12. # 通过 RoleBinding 将 ClusterRole 绑定到命名空间
  13. apiVersion: rbac.authorization.k8s.io/v1
  14. kind: RoleBinding
  15. metadata:
  16.   name: clusterrole-binding
  17.   namespace: dev-namespace
  18. roleRef:
  19.   apiGroup: rbac.authorization.k8s.io
  20.   kind: ClusterRole  # 引用集群级角色
  21.   name: namespace-pod-reader
  22. subjects:
  23. - kind: User
  24.   name: charlie
  25.   apiGroup: ""
复制代码
ClusterRoleBinding详解

在 Kubernetes（K8s）中，ClusterRoleBinding 是实现集群级权限控制的核心资源，用于将集群级角色（ClusterRole）与用户、服务账户或组关联，从而赋予其跨命名空间或集群级资源的访问权限。
ClusterRoleBinding 不局限于单个命名空间，而是对整个集群生，可用于授权对集群级资源（如 Nodes、Namespaces、PersistentVolumes）或所有命名空间资源（如所有 Pod、ConfigMaps）的访问。
作用

将 ClusterRole 定义的权限授予 主体（Subjects），主体可以是：

  • 用户账户（User Accounts）：K8s 中的外部用户（如集群管理员）。
  • 服务账户（Service Accounts）：K8s 内部用于 Pod 中容器访问 API 的账户。
  • 组（Groups）：用户组（如通过认证插件定义的组）。
ClusterRoleBinding资源清单文件
  1. apiVersion: rbac.authorization.k8s.io/v1
  2. kind: ClusterRoleBinding
  3. metadata:
  4.   name: cluster-admin-binding  # ClusterRoleBinding 名称
  5. roleRef:
  6.   apiGroup: rbac.authorization.k8s.io
  7.   kind: ClusterRole  # 必须是 ClusterRole
  8.   name: cluster-admin  # 引用的 ClusterRole 名称
  9. subjects:
  10. - kind: User        # 主体类型
  11.   name: admin-user  # 用户名
  12.   apiGroup: ""
  13. - kind: Group
  14.   name: system:serviceaccounts  # 所有服务账户所在的组
  15.   apiGroup: ""
复制代码
字段说明


  • metadata

    • name：ClusterRoleBinding 的唯一名称（集群级别）。

  • roleRef

    • 引用要绑定的集群角色，必须是 ClusterRole，不能是普通 Role。
    • ClusterRole 可以是：

      • 集群级资源权限（如管理节点、命名空间）。
      • 所有命名空间资源的权限（如查看所有命名空间中的 Pod）。
      • 非资源端点权限（如 /healthz、/metrics）。


  • subjects

    • 定义被授权的主体，结构与 RoleBinding 相同，但服务账户需指定命名空间（若有）。

Role和ClusterRole的区别

特性RoleClusterRole作用范围单个命名空间内集群范围（所有命名空间或集群级资源）定义位置属于命名空间资源（需指定 namespace）集群级资源（无需 namespace 字段）可授权的资源类型命名空间内资源（如 Pod、Service）1. 集群级资源（如 Nodes、Namespaces）
2. 所有命名空间的资源（如所有 Pod）
3. 非资源端点（如 /healthz、/metrics）绑定方式通过 RoleBinding 绑定到主体1. 通过 RoleBinding 绑定到单个命名空间（需角色规则适用于命名空间资源）
2. 通过 ClusterRoleBinding 绑定到整个集群典型场景授权命名空间内的操作（如开发人员管理自己命名空间的资源）1. 集群管理员权限
2. 跨命名空间操作
3. 访问集群级资源RoleBinding和ClusterRoleBinding的区别

特性RoleBindingClusterRoleBinding作用范围单个命名空间内集群范围（所有命名空间或集群级资源）绑定的角色类型1. Role（命名空间内角色）
2. ClusterRole（需角色规则适用于命名空间资源）仅 ClusterRole（集群级角色）定义位置属于命名空间资源（需指定 namespace）集群级资源（无需 namespace 字段）典型场景授权用户/服务账户操作特定命名空间内的资源（如开发人员管理 dev 命名空间的 Pod）1. 集群管理员权限
2. 跨命名空间操作
3. 访问集群级资源（如 Nodes）
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

使用道具 举报
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册
发帖
堠秉
2025-6-8 11:37:09

0

粉丝关注

16

主题发布

板块介绍填写区域，请于后台编辑
微信扫一扫