一、K8S 访问控制核心流程

K8S 集群的访问控制通过 API Server 作为唯一入口，所有请求需依次经过认证→授权→准入控制三层校验：

1. 认证（Authenticating）：验证客户端身份，核心是确认 “谁在访问”，支持令牌（Token）、SSL/TLS 双向认证等方式；
2. 授权（Authorization）：验证客户端权限，核心是确认 “能做什么”，K8S 1.6 + 主推 RBAC（基于角色的访问控制）；
3. 准入控制（Admission Control）：请求持久化前的拦截校验，可修改（Mutating）或验证（Validating）请求对象，集群默认开启 ServiceAccount、NamespaceLifecycle 等关键控制器。

二、认证层核心知识点

1. 账号类型

K8S 包含两类账号，核心区别如下：

账号类型	用途	作用域	默认配置
User Account	面向真实用户（人）	跨命名空间	无默认，需手动创建 / 配置
ServiceAccount	面向 Pod 内进程访问 API	仅所属命名空间	每个命名空间默认创建default SA

2. 认证方式

• Token 认证：基于对称密钥，通过 HTTP 首部传递令牌；
• SSL/TLS 认证：双向认证，客户端 / 服务端均需 CA 签发证书，确保通信加密 + 身份互认；
• kubeconfig：存储集群、用户、上下文信息，通过kubectl config管理，核心字段包含集群地址、用户证书 / 密钥、当前上下文。

三、授权层：RBAC 核心（重点）

RBAC（基于角色的访问控制）核心逻辑：将权限赋予角色，再将角色绑定给用户 / SA / 组，包含四大核心资源。

1. 角色定义类（权限集合）

资源类型	作用域	适用场景
Role	单个命名空间	授权命名空间内资源（如仅允许读取 default 命名空间的 Pod）
ClusterRole	集群级	授权集群级资源（Node）、跨命名空间资源（所有 Secrets）、非资源路径（/healthz）

Role/ClusterRole 核心配置字段：

• apiGroups：目标资源所属 API 组（核心组填 ""，如 Pod；扩展组如 apps、batch）；
• resources：授权的资源类型（如 pods、deployments、secrets，子资源需加后缀如 pods/log）；
• resourceNames：限定仅对指定名称的资源生效（精细化权限控制）；
• verbs：允许的操作（get/list/watch/create/update/patch/delete 等）。

2. 角色绑定类（关联角色与用户）

资源类型	作用域	绑定规则
RoleBinding	单个命名空间	可绑定 Role（同命名空间）或 ClusterRole（仅对当前命名空间生效）
ClusterRoleBinding	集群级	仅绑定 ClusterRole，适用于集群级 / 跨命名空间授权

绑定核心字段：

• subjects：绑定对象（User/Group/ServiceAccount）；
• roleRef：关联的 Role/ClusterRole（需指定 kind、name、apiGroup）。

3. RBAC 关键技巧

• 复用 ClusterRole：多命名空间需相同权限时，定义 1 个 ClusterRole，通过多个 RoleBinding 绑定（避免重复创建 Role）；
• 资源引用：子资源需用/分隔（如 pods/log），resourceNames 可限定仅操作指定名称的资源；
• 内置 ClusterRole：K8S 预定义view（只读）、edit（可读写）、admin（全量管理）、cluster-admin（集群超级管理员），可直接引用。

四、RBAC 实操要点

1. ServiceAccount 授权

• 未指定 SA 的 Pod 默认使用default SA，且默认无权限；
• 为 SA 授权的常用命令：

# 为my-namespace的my-sa授予view权限
kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace
# 为kube-system的default SA授予集群管理员权限（高危）
kubectl create clusterrolebinding add-ons-add-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default

2. 创建自定义用户并授权（SSL 证书方式）

        1.生成证书（在 master 节点的 /etc/kubernetes/pki 目录）：

# 生成私钥
umask 077; openssl genrsa -out lucky.key 2048
# 生成证书请求（CN为用户名）
openssl req -new -key lucky.key -out lucky.csr -subj "/CN=lucky"
# 用CA签发证书（有效期10年）
openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650

        2.配置 kubeconfig：

# 添加用户凭证
kubectl config set-credentials lucky --client-certificate=./lucky.crt --client-key=./lucky.key --embed-certs=true
# 创建上下文
kubectl config set-context lucky@kubernetes --cluster=kubernetes --user=lucky
# 切换上下文
kubectl config use-context lucky@kubernetes

        3.授权（仅允许操作 lucky 命名空间）：

kubectl create ns lucky
kubectl create rolebinding lucky -n lucky --clusterrole=cluster-admin --user=lucky

五、RBAC 核心权限速查

权限动词	核心含义	典型场景
get	获取单个资源详情	kubectl get pod <pod-name>
list	批量列出资源	kubectl get pods
watch	实时监控资源变化	kubectl watch pod <pod-name>
create	创建资源	kubectl create -f pod.yaml
patch	增量更新资源	kubectl patch pod <pod-name>
delete	删除单个资源	kubectl delete pod <pod-name>
exec	进入容器执行命令	kubectl exec -it <pod-name>
*	通配符，所有操作（高危）	谨慎使用，仅管理员场景

六、核心总结

1. RBAC 是 K8S 授权的核心，核心是 “角色定义 + 角色绑定”，区分命名空间级（Role/RoleBinding）和集群级（ClusterRole/ClusterRoleBinding）；
2. ServiceAccount 是 Pod 访问 API 的核心身份，默认无权限，需按需授权；
3. 自定义用户需通过 SSL 证书认证，授权后仅能操作指定命名空间 / 资源，符合最小权限原则；
4. 优先复用内置 ClusterRole（view/edit/admin），减少重复配置，降低权限管理复杂度。