【K8s】集群安全机制（二）：授权（Authorization）详解与实战

上一篇我们聊了 Kubernetes 的认证（Authentication） ，解决的是"你是谁"。
这一篇继续往下走，解决更关键的问题------你能干什么？

📌 目录

一、为什么需要授权
二、Kubernetes 授权机制概览
三、RBAC 核心原理拆解
- 3.1 四大核心对象
- 3.2 关键概念（资源 & 主体）
四、RBAC 实战配置详解
- 4.1 Role / ClusterRole
- 4.2 RoleBinding / ClusterRoleBinding
五、真实场景落地：限制用户只操作某个命名空间
六、权限设计经验与踩坑总结
七、常用内置角色说明
八、总结

一、为什么需要授权

认证完成之后，API Server 已经确认请求方是可信的，但问题还没解决：

👉 这个用户是否有权限执行这个操作？

比如：

devuser 能不能删除 Pod？
运维是否可以查看 Secret？
某个 ServiceAccount 能不能访问所有 namespace？

这些都属于**授权（Authorization）**的范畴。

二、Kubernetes 授权机制概览

Kubernetes 支持多种授权策略，通过参数控制：

复制代码

--authorization-mode=

常见策略如下：

模式	说明
AlwaysDeny	拒绝所有请求（测试用）
AlwaysAllow	允许所有请求（不安全，仅测试环境）
ABAC	基于属性控制，规则简单但难维护
Webhook	调用外部服务做授权
RBAC（推荐）	基于角色控制，K8s 默认方案

实际生产环境基本都是 RBAC

三、RBAC 核心原理拆解

RBAC（Role-Based Access Control）核心思想很简单：

通过"角色"管理权限，再把角色赋给用户

这样就避免了权限分散、难维护的问题。

3.1 四大核心对象

RBAC 主要围绕 4 个对象展开：

对象	作用范围	作用
Role	单个 namespace	定义命名空间内权限
ClusterRole	集群级别	定义全局权限
RoleBinding	单个 namespace	绑定权限
ClusterRoleBinding	集群级别	全局绑定权限

一句话总结：

Role / ClusterRole = 权限规则
Binding = 把权限给谁

3.2 关键概念

1）资源（Resources）

K8s 中一切皆资源：

pods
deployments
services
secrets

也可以有子资源，比如：

复制代码

pods/log

2）主体（Subjects）

权限可以授予：

类型	说明
User	用户（证书 CN）
Group	用户组（证书 O）
ServiceAccount	Pod 身份

实际生产中：

人类用户 → User / Group
服务访问 → ServiceAccount

四、RBAC 实战配置详解

4.1 Role（命名空间级权限）

复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

说明：

只在 dev 命名空间生效
只能读取 Pod

4.2 ClusterRole（集群级权限）

复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: global-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

可以用于：

所有 namespace
集群资源（Node）
非资源接口（/healthz）

4.3 RoleBinding（绑定权限）

复制代码

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-reader-binding
  namespace: dev
subjects:
- kind: User
  name: alice
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

效果：

alice 只能访问 dev namespace 的 pods

4.4 RoleBinding 绑定 ClusterRole（重点）

复制代码

kind: RoleBinding
metadata:
  name: dev-admin-binding
  namespace: dev
subjects:
- kind: User
  name: bob
roleRef:
  kind: ClusterRole
  name: admin

这是一个非常实用的用法：

用 ClusterRole 定义模板，在各 namespace 复用

4.5 ClusterRoleBinding（全局授权）

复制代码

kind: ClusterRoleBinding
metadata:
  name: manager-secret-access
subjects:
- kind: Group
  name: manager
roleRef:
  kind: ClusterRole
  name: secret-reader

效果：

manager 组可以访问所有 namespace 的 Secret

五、实战：限制用户只操作 dev 命名空间

这是一个典型场景，也是最常见的权限设计。

目标

创建一个用户：devuser

只能操作 dev namespace

步骤 1：生成用户证书

（略去细节，这里只讲核心）

复制代码

cfssl gencert -ca=ca.crt -ca-key=ca.key \
  -profile=kubernetes devuser-csr.json | cfssljson -bare devuser

步骤 2：生成 kubeconfig

复制代码

kubectl config set-credentials devuser \
  --client-certificate=devuser.pem \
  --client-key=devuser-key.pem \
  --kubeconfig=devuser.kubeconfig

步骤 3：创建 namespace

复制代码

kubectl create ns dev

步骤 4：绑定权限（关键）

复制代码

kubectl create rolebinding devuser-admin-binding \
  --clusterrole=admin \
  --user=devuser \
  --namespace=dev

步骤 5：验证权限

复制代码

kubectl get pods -n dev --kubeconfig=devuser.kubeconfig

✅ 可以访问

复制代码

kubectl get pods -n default

被拒绝（符合预期）

六、权限设计经验 & 踩坑

这里是实际用下来比较重要的几

1）权限只会"叠加"，不会减少

RBAC 没有"deny"

如果你给了两个角色：

一个允许
一个不允许

最终结果：允许

2）避免滥用 cluster-admin

很多新手上来就：

复制代码

--clusterrole=cluster-admin

风险极高：

能删整个集群
能读所有 Secret

建议：

最小权限原则（Least Privilege）

3）ServiceAccount 权限最容易被忽略

很多攻击场景都是：

Pod 被入侵 → 拿到 SA Token → 横向移动

建议：

禁用默认 SA
为每个服务单独分配 SA

4）RoleBinding 可以引用 ClusterRole（高频技巧）

这是权限复用的关键

5）调试权限建议用这个命令

复制代码

kubectl auth can-i get pods --as=devuser -n dev

非常好用，用来验证权限

七、常用内置角色

Kubernetes 已经帮我们准备好了很多角色：

复制代码

kubectl get clusterrole

常见如下：

角色	说明
view	只读
edit	可修改资源（不含权限相关）
admin	namespace 管理权限
cluster-admin	超级管理员

八、总结

这一篇我们重点搞清楚了：

✔ 授权解决什么问题

✔ RBAC 的核心设计思想

✔ 四大对象的关系

✔ 如何在实际场景中落地

✔ 常见坑和经验

可以用一句话总结：

RBAC = 定义权限（Role） + 绑定权限（Binding）

如果你正在做集群权限治理，这一块是必须吃透的。

很多"事故"，其实都源于权限配置不当。