Kubernetes认证授权

最新推荐文章于 2025-11-24 23:05:31 发布

原创最新推荐文章于 2025-11-24 23:05:31 发布 · 798 阅读

26 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #云原生 #K8s认证 #k8s #K8s授权 #RBAC

Kubernetes 专栏收录该内容

8 篇文章

订阅专栏

K8s认证授权

API-Server：本质是Web服务，使用HTTPS协议；
RBAC：基于权限的角色管理（基于角色的访问控制，现行默认规则）；

认证授权的三步：

1.创建用户

User Account：普通用户；私钥→CA证书→kubeconfig；
ServiceAccount：系统用户，让Pod和API-Server通信使用的用户；

2.角色与授权

Role：局部的角色，某个命名空间内生效；
ClusterRole：全局的角色，所有命名空间都生效；
权限：
- 只读：查询权限
  - get（查询单个资源）、
  - list（列出资源清单）、
  - watch（实时监听资源变化）；
- 只写：修改创建权限
  - create（创建）、
  - update（更新）、
  - patch（部分更新）；
- 删除权限：
  - delete（删除单个资源）、
  - deletecollection（删除资源集合，如所有Pod）
资源：要操作的K8s对象，比如Pod、Deployment、Service、Node(节点)、Namespace(命名空间)等;

3.用户与角色绑定

RoleBinding：局部绑定
- 分配Role权限给命名空间内部用户；
- 让ClusterRole的权限仅在单个命名空间生效；

ClusterRoleBinding：全局绑定，给用户/用户组分配集群级权限（运维管理原）

k8s证书

一、核心安全机制

K8s 围绕 API Server 安全设计，通过「认证（Authentication）→ 鉴权（Authorization）→ 准入控制（AdmissionControl）」三步防护。

二、认证方式（3 种）

HTTP Token 认证：基于唯一复杂字符串 Token，存储于 API Server 可访问文件，请求时需放入 HTTP Header；
HTTP Base 认证：用户名 + 密码经 BASE64 编码，通过 Authorization 请求头传递；
HTTPS 证书认证：最严格，基于 CA 根证书签名的客户端身份认证。

三、鉴权策略（5 种）

AlwaysDeny：拒绝所有请求（测试用）；
AlwaysAllow：允许所有请求（无需授权时使用）；
Webbook：调用外部 REST 服务授权；
RBAC：基于角色的访问控制（默认规则）；
ABAC：基于属性的访问控制（按配置规则匹配）。

四、准入控制（核心插件功能）

NamespaceLifecycle：管控命名空间生命周期（禁止无效命名空间操作、级联删除资源）；
LimitRanger：限制资源请求不超过 Namespace 的 LimitRange 配置；
ResourceQuota：限制资源请求不超过 ResourceQuota 配置；
ServiceAccount：为 Pod 进程及外部用户提供身份信息。

五、证书自动续签方案

kubeadm 方式：

检查过期：kubeadm certs check-expiration；
续签：sudo kubeadm certs renew all；
生效：sudo systemctl restart kubelet（重启控制平面组件）。

cert-manager 方式（推荐，自动化管理）：

安装：kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.yaml；
配置：创建 ClusterIssuer/Issuer（对接 Let's Encrypt 等 CA）；
申请：创建 Certificate 资源指定证书需求，自动颁发续签。

手动方式：

生成新证：openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes；
替换旧证：更新控制平面组件（kube-apiserver 等）的证书；

重启生效。

总结

K8s 证书是集群安全核心，优先使用 kubeadm 或 cert-manager 实现自动化续签，避免人工遗漏导致证书过期中断服务；核心安全流程为「认证→鉴权→准入控制」，层层防护 API Server 安全。

k8s认证、授权、准入控制概述

Kubernetes（K8s）作为容器编排平台，其安全核心围绕“请求访问控制”构建，所有对集群资源的操作均需经过kube-apiserver（集群唯一入口）的三层校验：认证（Authenticating）->授权（Authorization）->准入控制（Admission Control）。这一流程确保只有“身份合法、权限足够、符合规则”的请求才能执行，是集群安全的基石。

一、整体安全架构：请求的 “三道防线”

K8s采用“分层防御”思想，所有客户端（普通用户/集群内Pod）的请求必须依次通过以下三步，任一环节失败则请求被拒绝：

1.认证（身份校验）：确认“你是谁” —— 验证客户端身份合法性（如账号、令牌、证书）。

2.授权（权限校验）：确认“你能做什么” —— 检查已认证的客户端是否有权限操作目标资源（如创建Pod、删除ConfigMap）。

3.准入控制（规则校验）：确认“操作是否合规”—— 在资源持久化前，通过插件对请求进行额外校验或修改（如资源配额、安全策略）。

用户可以分为两类：

1、普通用户（User Account）：面向现实中的人（如运维人员），需手动管理账号（K8s不提供内置用户管理，需结合外部系统如LDAP）。

2、服务账号（ServiceAccount）：面向集群内Pod中的进程（如应用程序调用 K8s API），是 K8s 内置资源，自动关联到Pod。

二、第一道防线：认证（Authenticating）

认证的核心是“验证客户端身份”，K8s不存储用户信息，仅通过“凭证”判断身份合法性。常见认证方式和账号体系如下：

核心认证方式

K8s支持多种认证机制（可同时启用，按顺序校验），主流方式包括：

认证方式	原理	适用场景
令牌（Token）认证	客户端携带预生成的令牌（如 ServiceAccount 关联的 Secret Token），APIServer 校验令牌有效性	Pod 内进程调用 K8s API（默认方式）
SSL/TLS 证书认证	客户端与 APIServer 双向认证：客户端需提供 CA 签署的证书，APIServer 验证证书合法性	运维人员通过 kubectl 操作集群（最安全）
基础认证（Basic Auth）	客户端携带用户名 + 密码（存储在静态文件中），APIServer 比对校验	测试环境（生产环境不推荐，密码易泄露）
Webhook 认证	APIServer 将认证请求转发到外部服务（如 LDAP、OAuth2 服务），由外部服务返回认证结果	企业级集群（对接现有身份系统）

两类账号体系

K8s区分“用户账号”和“服务账号”，分别对应“人”和“Pod进程”的身份：

1. 服务账号（ServiceAccount）：给 Pod 用的账号

设计目的：为Pod内的应用程序提供访问K8s API的身份凭证（如Pod内的程序需查询其他Pod状态）。

核心特性：

与Namespace绑定：每个Namespace自动创建一个default ServiceAccount，Pod若未指定则默认使用该账号。

自动关联Secret：创建ServiceAccount时，K8s会自动生成一个包含Token和CA证书的Secret，Pod挂载该Secret即可完成认证。

操作示例：

# 1. 创建 ServiceAccount（命名空间 default）

kubectl create serviceaccount test-sa

# 2. 查看 ServiceAccount 详情（含关联的 Secret）

kubectl describe sa test-sa

# 输出会包含：Secrets: [test-sa-token-xxxx]

# 3. Pod 引用 ServiceAccount

cat <<EOF | kubectl apply -f -

apiVersion: v1

kind: Pod

metadata:

spec:

serviceAccountName: test-sa # 引用自定义 ServiceAccount

containers:

- name: nginx

image: nginx:latest

EOF

2. 用户账号（User Account）：给人用的账号

设计目的：面向集群管理员、开发人员等“人”的身份，用于通过kubectl或API操作集群。

核心特性：

跨Namespace：用户账号不绑定Namespace，可在集群范围内使用。
需外部管理：K8s不提供内置的用户创建命令，需通过证书、LDAP等外部系统管理）如通过openssl生成用户证书。

配置示例（kubectl 配置文件）：kubectl config view 可查看当前用户的认证配置，核心包含 “集群地址、用户证书 / 令牌”：

apiVersion: v1

clusters:

- cluster:

certificate-authority-data: DATA+OMITTED # 集群 CA 证书

server: https://192.168.40.199:6443 # APIServer 地址

users:

- name: kubernetes-admin # 用户名

user:

client-certificate-data: REDACTED # 用户证书

client-key-data: REDACTED # 用户私钥

contexts:

- context:

cluster: kubernetes # 关联的集群

user: kubernetes-admin # 关联的用户

current-context: kubernetes-admin@kubernetes # 当前使用的上下文

三、第二道防线：授权（Authorization）

认证通过后，K8s需判断“该客户端是否有权限执行请求操作”，这一过程由授权插件实现。K8s 1.6+后默认推荐RBAC（基于角色的访问控制），替代了早期的ABAC、Node等插件。

授权插件	原理	优缺点	适用场景
RBAC（推荐）	将权限定义为 “角色”，通过 “绑定” 将角色赋予用户 / ServiceAccount，灵活可控	优点：细粒度、易维护；缺点：需手动配置角色	生产环境（所有场景）
ABAC	基于属性（如用户、资源、操作）的策略文件授权，策略文件修改需重启 APIServer	优点：灵活；缺点：难维护、不支持动态更新	测试环境
Node	仅授权 Node 节点访问自身相关资源（如 Node 上的 Pod），由 K8s 自动管理	优点：无需手动配置；缺点：仅适用于 Node	节点自身权限控制
Webhook	将授权请求转发到外部服务，由外部服务判断是否授权（如对接企业权限系统）	优点：对接外部系统；缺点：依赖外部服务可用性	企业级复杂权限场景

RBAC的核心是“角色定义权限，绑定关联角色与用户”，包含4个内置资源对象：

资源对象	作用	作用范围
Role（角色）	定义单个 Namespace 内的权限集合（如 “读取 default 命名空间的 Pod”）	Namespace 级别
ClusterRole（集群角色）	定义集群范围的权限集合（如 “读取所有 Namespace 的 Secret”“访问 Node 资源”）	集群级别
RoleBinding（角色绑定）	将 Role/ClusterRole 绑定到用户 / ServiceAccount，权限仅作用于单个 Namespace	Namespace 级别
ClusterRoleBinding（集群角色绑定）	将 ClusterRole 绑定到用户 / ServiceAccount，权限作用于整个集群	集群级别

1. Role：Namespace 级别的权限定义，命名空间内的“局部权限说明书”

实操示例：在default命名空间创建一个名为pod-ops的Role，允许“查看、创建、更新Pod”，但仅允许删除名为test-pod的Pod（通过ResourceNames限定）。

# 保存为 role-pod-ops.yaml

apiVersion: rbac.authorization.k8s.io/v1 # RBAC固定API版本

kind: Role # 资源类型为Role

metadata:

namespace: default # 必须指定命名空间（作用范围）

rules: # 权限规则（可配置多个规则）

- apiGroups: [""] # 核心资源（Pod、Service等）的API组，固定填""

resources: ["pods"] # 操作的资源：Pod

verbs: ["get", "list", "watch", "create", "update", "delete"] # 允许的操作

resourceNames: ["test-pod"] # 仅允许操作名为test-pod的Pod（可选配置）

- apiGroups: [""] # 第二个规则：允许查看所有Pod的日志（不受资源名称限制）

resources: ["pods/log"] # 操作的子资源：Pod日志

verbs: ["get", "list"]

# 创建命令：执行后Role立即生效

kubectl apply -f role-pod-ops.yaml

# 验证创建结果：查看default命名空间的Role

kubectl get role -n default

# 输出结果中会显示pod-ops，说明创建成功

2. ClusterRole：集群级别的权限定义，集群级的“全局权限说明书”

实操示例：创建一个名为cluster-resource-ops的ClusterRole，允许：1. 查看所有命名空间的Pod、Deployment；2. 查看和创建命名空间；3. 查看节点信息。

# 保存为 clusterrole-resource-ops.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole # 资源类型为ClusterRole

metadata:

rules:

# 规则1：查看所有命名空间的Pod和Deployment

- apiGroups: ["", "apps"] # ""=核心组（Pod），apps=Deployment所属组

resources: ["pods", "deployments"]

verbs: ["get", "list", "watch"]

# 规则2：查看和创建命名空间（集群级资源）

- apiGroups: [""]

resources: ["namespaces"]

verbs: ["get", "list", "create"]

# 规则3：查看节点信息（集群级资源）

- apiGroups: [""]

resources: ["nodes"]

verbs: ["get", "list"]

# 创建命令：

kubectl apply -f clusterrole-resource-ops.yaml

# 验证创建结果：查看集群内所有ClusterRole

kubectl get clusterrole

# 输出结果中会显示cluster-resource-ops3. RoleBinding：绑定角色到用户（Namespace 级别）

3. RoleBinding：给“局部对象”分配权限

实操示例1：绑定Role到ServiceAccount（最常用场景）把前面创建的pod-ops Role（default命名空间），绑定到default命名空间的my-app-sa服务账户，让Pod内应用拥有对应的Pod操作权限。

# 保存为 rolebinding-pod-ops.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

namespace: default # 必须和Role在同一个命名空间

subjects: # 权限接收者（主体）

- kind: ServiceAccount # 主体类型：服务账户

namespace: default # 服务账户所在命名空间

roleRef: # 引用要分配的Role（固定格式，不能改）

apiGroup: rbac.authorization.k8s.io

kind: Role # 引用的是Role类型

# 创建命令：

kubectl apply -f rolebinding-pod-ops.yaml

实操示例2：绑定ClusterRole到User（限定命名空间）让外部用户dev-user仅在dev命名空间，拥有cluster-resource-ops ClusterRole的权限（相当于“全局权限局部使用”）。

# 保存为 rolebinding-cluster-role.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

namespace: dev # 限定在dev命名空间生效（需提前创建dev命名空间：kubectl create ns dev）

subjects:

- kind: User # 主体类型：外部用户

apiGroup: rbac.authorization.k8s.io

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: ClusterRole # 引用ClusterRole

# 创建命令：

kubectl apply -f rolebinding-cluster-role.yaml

4. ClusterRoleBinding：给“全局对象”分配权限

核心作用：把ClusterRole的权限分给主体，作用于整个集群（所有命名空间+集群级资源），适合“批量授权全局权限”。

实操示例：给用户组ops-team（运维团队）分配K8s默认的cluster-admin权限（拥有集群内所有操作权限，谨慎使用！），让运维人员能管理整个集群。

# 保存为 clusterrolebinding-ops-admin.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

subjects:

- kind: Group # 主体类型：用户组

apiGroup: rbac.authorization.k8s.io

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: ClusterRole

# 创建命令：

kubectl apply -f clusterrolebinding-ops-admin-binding.yaml

3.3 RBAC 常用操作命令

操作需求	命令示例
创建 Role	kubectl create role pod-reader --verb=get,list,watch --resource=pods -n default
创建 ClusterRole	kubectl create clusterrole secret-reader --verb=get,list,watch --resource=secrets
创建 RoleBinding（绑定用户）	kubectl create rolebinding alice-pod-reader --role=pod-reader --user=alice -n default
创建 RoleBinding（绑定 ServiceAccount）	kubectl create rolebinding test-sa-secret-reader --clusterrole=secret-reader --serviceaccount=default:test-sa -n default
创建 ClusterRoleBinding	kubectl create clusterrolebinding manager-secret-reader --clusterrole=secret-reader --group=manager
查看 Role/RoleBinding	kubectl get role -n default、kubectl get rolebinding -n default -o wide
查看 ClusterRole/ClusterRoleBinding	kubectl get clusterrole、kubectl get clusterrolebinding

四、第三道防线：准入控制（Admission Control）

授权通过后，请求进入“准入控制”阶段 —— 由准入控制器（Admission Controller）对请求进行最后校验或修改，确保资源符合集群规则（如资源配额、安全策略）。只有所有准入控制器通过，请求才会被持久化到etcd。

1、准入控制器的核心特性

运行位置：嵌入在kube-apiserver中，需通过APIServer启动参数 --enable-admission-plugins启用（K8s 1.19+推荐用此参数替代旧的 --admission-control）。

两类操作：

1.Mutating(修改)：修改请求中的资源对象（如自动为Pod注入Sidecar容器、添加标签）

2.Validating（验证）：校验资源对象是否符合规则（如资源是否超过配额、是否违反安全策略）。

执行顺序：先执行所有Mutating控制器，再执行所有Valicating控制器

2、必选 / 常用准入控制器

K8s提供数十种准入控制器，生产环境需启用以下核心插件（根据版本调整）：

准入控制器名称	类型	作用
NamespaceLifecycle	Validating	禁止在不存在的 Namespace 中创建资源；删除 Namespace 时自动删除其所有资源。
LimitRanger	Mutating+Validating	强制 Pod / 容器遵守 Namespace 中的 LimitRange 规则（如 CPU / 内存默认值和上限）。
ServiceAccount	Mutating+Validating	自动为 Pod 关联 ServiceAccount；验证 Pod 引用的 ServiceAccount 存在。
ResourceQuota	Validating	强制 Namespace 遵守 ResourceQuota 规则（如总 CPU / 内存配额、资源对象数量上限）。
MutatingAdmissionWebhook	Mutating	允许通过外部 Webhook 服务修改资源（如 Istio 自动注入 Sidecar）。
ValidatingAdmissionWebhook	Validating	允许通过外部 Webhook 服务验证资源（如自定义安全策略校验）。
PodSecurityPolicy	Mutating+Validating	（K8s 1.25 + 已废弃，推荐用 Pod Security Standards）强制 Pod 遵守安全策略（如禁止特权容器）。
DefaultStorageClass	Mutating	为未指定 storageClassName 的 PVC 自动分配默认存储类。

3、启用准入控制器的配置示例

在kube-apiserver的启动参数中配置（如通过kubeadm部署的集群，可修改 /etc/kubernetes/manifests/kube-apiserver.yaml）:

spec:

containers:

- command:

- kube-apiserver

# 启用核心准入控制器（1.24+ 版本示例）

- --enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,DefaultStorageClass

# 禁用不需要的控制器（如废弃的 PodSecurityPolicy）

- --disable-admission-plugins=PodSecurityPolicy

# 其他参数...

五、核心总结：三层校验的逻辑闭环

K8s 安全管理的本质是 “最小权限原则”，通过三层校验确保集群资源不被未授权访问或滥用：

认证：解决 “身份合法” 问题 —— 排除匿名请求，确认客户端是 “可信的人或 Pod”。

授权：解决 “权限足够” 问题 —— 通过 RBAC 精细控制 “谁能操作哪些资源”，避免越权。

准入控制：解决 “操作合规” 问题 —— 通过插件强制集群规则，避免资源配置违反安全或资源策略。

生产环境中，需重点关注：

为 ServiceAccount 授予 “最小必要权限”（避免使用 cluster-admin）。

启用核心准入控制器（尤其是 ResourceQuota、ValidatingAdmissionWebhook）。

通过 kubectl auth can-i 验证权限（如 `kubectl auth can-i create pods

Kubernetes 自建账号及认证

核心目标

手动创建访问 API Server 的用户（区别于自动管理的 ServiceAccount），完成认证并配置权限，支持两种主流方式：客户端证书认证（推荐）和静态令牌认证。

一、客户端证书认证（安全首选）

步骤 1：生成用户私钥与证书请求（CSR）

# 创建私钥
openssl umask 077; openssl genrsa -out 用户名.key 2048

# 生成CSR（CN=用户名，O=用户组）
openssl req -new -key 用户名.key -out 用户名.csr -subj "/CN=用户名/O=用户组"

步骤 2：用集群 CA 签名证书

openssl x509 -req -in 用户名.csr \
  -CA /etc/kubernetes/pki/ca.crt \  # 集群CA证书
  -CAkey /etc/kubernetes/pki/ca.key \  # 集群CA私钥
  -CAcreateserial \
  -out 用户名.crt \
  -days 365  # 有效期

步骤 3：配置 kubeconfig

# 1. 设置集群信息
kubectl config set-cluster kubernetes \
  --server=https://<API-Server-IP>:6443 \
  --certificate-authority=/etc/kubernetes/pki/ca.crt \
  --embed-certs=true \
  --kubeconfig=自定义配置文件路径

# 2. 设置用户信息
kubectl config set-credentials 用户名 \
  --client-certificate=用户名.crt \
  --client-key=用户名.key \
  --embed-certs=true \
  --kubeconfig=自定义配置文件路径

# 3. 绑定集群与用户（创建上下文）
kubectl config set-context 用户名@kubernetes \
  --cluster=kubernetes \
  --user=用户名 \
  --kubeconfig=自定义配置文件路径

# 4. 切换上下文
kubectl config use-context 用户名@kubernetes --kubeconfig=自定义配置文件路径

二、静态令牌认证（适合临时用户）

步骤 1：生成令牌文件

# 生成随机令牌
TOKEN=$(head -c 16 /dev/urandom | base64)

# 创建CSV格式令牌文件（token,用户名,用户ID,"组1,组2"）
echo "${TOKEN},用户名,10001,\"用户组\"" > /etc/kubernetes/tokens.csv

步骤 2：配置 API Server 加载令牌

修改 /etc/kubernetes/manifests/kube-apiserver.yaml，添加启动参数并挂载令牌文件：

spec:
  containers:
  - command:
    - kube-apiserver
    - --token-auth-file=/etc/kubernetes/tokens.csv  # 新增
    volumeMounts:
    - name: tokens
      mountPath: /etc/kubernetes/tokens.csv
      readOnly: true
  volumes:
  - name: tokens
    hostPath:
      path: /etc/kubernetes/tokens.csv
      type: File

（kubelet 会自动重启 API Server 生效）

步骤 3：配置 kubeconfig（令牌方式）

# 设置用户（使用令牌）
kubectl config set-credentials 用户名 --token=${TOKEN} --kubeconfig=自定义配置文件路径
# 后续步骤同证书认证（设置集群、上下文）

三、认证后授权（RBAC 配置）

认证仅验证身份，需配置权限：

# 1. 创建角色（定义权限，如查看default命名空间的Pod）
kubectl create role 角色名 \
  --namespace=default \
  --verb=get,list,watch \
  --resource=pods

# 2. 绑定角色到用户
kubectl create rolebinding 绑定名 \
  --namespace=default \
  --role=角色名 \
  --user=用户名

方式对比

方式	优点	缺点	适用场景
客户端证书认证	安全、有效期可控	步骤稍复杂	长期用户、生产环境
静态令牌认证	配置简单	修改需重启 API Server	临时用户、测试环境

Kubernetes RBAC 授权机制

一、核心概念

RBAC（基于角色的访问控制）是 Kubernetes 主流授权机制，核心逻辑是：定义权限→分配权限，遵循 “最小权限原则”，仅授予必要权限。

二、四大核心组件

组件类型	作用范围	功能
Role	单个命名空间	定义命名空间内的权限集合（如 “查看 default 命名空间的 Pod”）
ClusterRole	整个集群	定义集群级权限集合（如 “查看所有命名空间的 Pod”“管理节点”）
RoleBinding	单个命名空间	将 Role 或 ClusterRole 的权限分配给主体（用户 / 服务账户等），仅在当前命名空间生效
ClusterRoleBinding	整个集群	将 ClusterRole 的权限分配给主体，全集群生效

三、权限三要素

定义 Role/ClusterRole 时需明确：

资源（Resources）：操作的对象（如 pods、deployments、nodes）；
操作（Verbs）：对资源的动作（get/list/watch 只读；create/update/delete 读写）；
资源名称（ResourceNames，可选）：限定仅作用于特定名称的资源（如仅允许操作名为 “test-pod” 的 Pod）。

四、关键操作示例

1. 创建 Role（命名空间内权限）

# role-pod-ops.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-ops
  namespace: default  # 限定命名空间
rules:
- apiGroups: [""]  # 核心资源API组（Pod、Service等）
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "create", "delete"]
  resourceNames: ["test-pod"]  # 仅允许操作test-pod

创建命令：kubectl apply -f role-pod-ops.yaml

2. 创建 ClusterRole（集群级权限）

# clusterrole-global-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: global-reader
rules:
- apiGroups: ["", "apps"]  # 核心组+Deployment所属组
  resources: ["pods", "deployments", "nodes"]  # 包含集群级资源nodes
  verbs: ["get", "list", "watch"]

创建命令：kubectl apply -f clusterrole-global-reader.yaml

3. 绑定权限（RoleBinding）

# rolebinding-dev-user.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-user-binding
  namespace: default  # 与Role同命名空间
subjects:
- kind: User  # 主体类型：User/Group/ServiceAccount
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:  # 引用Role或ClusterRole
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-ops

创建命令：kubectl apply -f rolebinding-dev-user.yaml

4. 集群级绑定（ClusterRoleBinding）

# clusterrolebinding-ops-team.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ops-team-binding
subjects:
- kind: Group
  name: ops-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin  # 内置集群管理员角色

创建命令：kubectl apply -f clusterrolebinding-ops-team.yaml

五、权限验证命令

用 kubectl auth can-i 检查权限是否生效：

# 检查当前用户能否在default命名空间创建Pod
kubectl auth can-i create pods -n default

# 检查指定ServiceAccount的权限
kubectl auth can-i delete pods -n default --as=system:serviceaccount:default:my-sa

# 检查集群级权限（如查看节点）
kubectl auth can-i list nodes