## 一、授权拿到的不是对象，是"属性"

认证交出 `user.Info` 之后，授权拿到的是另一组东西：

```go
// staging/src/k8s.io/apiserver/pkg/authorization/authorizer/interfaces.go (v1.34.0)
type Attributes interface {
    GetUser() user.Info
    GetVerb() string          // get / list / watch / create / update / patch / delete / deletecollection / proxy
    GetNamespace() string
    GetResource() string      // pods / deployments ...
    GetSubresource() string   // logs / status / exec ...
    GetName() string          // 只对 get / update / delete 有值
    GetAPIGroup() string
    IsResourceRequest() bool  // false 表示 /healthz、/metrics 这类非资源请求
    GetPath() string
}
```

注意这里**没有对象本身**。授权发生在对象被读出来之前，所以它不可能知道"这个 Pod 是不是带 `team=infra` 标签"。

这就划出一条硬边界：**依赖对象内容的策略，只能放在准入层**。很多人想把"只允许改带某标签的资源"写进 RBAC，写不出来——不是配置问题，是模型问题。

## 二、四种 authorizer，一条链，默认拒绝

和认证一样，授权也是链式的，但语义不同：

![authz-1-chain.png](https://developer.qcloudimg.com/http-save/yehe-11479707/acfba159a0a16d7288aba10da42ecc60.png)

*图 1：第一个 Allow / Deny 终止链条；全部 NoOpinion 就是 403。*

```go
// staging/src/k8s.io/apiserver/pkg/authorization/union/union.go (v1.34.0)
for _, currAuthzHandler := range authzHandler {
    decision, reason, err := currAuthzHandler.Authorize(ctx, a)
    switch decision {
    case authorizer.DecisionAllow, authorizer.DecisionDeny:
        return decision, reason, err      // 第一个明确表态的说了算
    case authorizer.DecisionNoOpinion:
        // continue
    }
}
```

三种决策：`Allow`、`Deny`、`NoOpinion`。**第一个非 NoOpinion 的结果直接终止链条**；全部 NoOpinion，就是 403。

可选的四种实现：

| 模式 | 判断依据 | 什么时候用 |
| --- | --- | --- |
| **RBAC** | Role + Binding 里的规则集 | 绝大多数场景 |
| **Node** | 请求里的节点名与对象之间的边 | 给 kubelet 用，RBAC 表达不了 |
| **Webhook** | 调外部服务（SubjectAccessReview） | OPA / Kyverno、云 IAM 映射 |
| **ABAC** | JSON 策略文件 | 历史遗留，基本淘汰 |

kubeadm 的默认是 `--authorization-mode=Node,RBAC`。

**为什么是"默认拒绝"而不是"默认允许"？**
因为安全模型里，未知必须失败。新装一个 CRD、新加一个 API group，如果没有显式授权，任何人都不该能访问。默认允许意味着每加一个扩展都要记得"去关权限"，迟早漏。

代价是排障成本：403 不会告诉你"差哪条规则"，只会说 `cannot list resource "pods"`。

> 一个例外：`system:masters` 组在 apiserver 里有硬编码旁路，直接 Allow，不进入任何 authorizer。所以**永远不要把这个组绑给 OIDC 的某个 group**——那等于给整个 IdP 开后门。

## 三、RBAC 的两个关键选择

### 1. Role 和 Binding 是分离的两类对象

![authz-2-rbac.png](https://developer.qcloudimg.com/http-save/yehe-11479707/bbe3180371c9535ab39e9008938a28cc.png)

*图 2：同一份规则可以绑给任意多个主体，改规则只改一处。*

```yaml
# 规则集：能做什么
kind: Role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

# 绑定：谁拥有它
kind: RoleBinding
subjects:
- kind: Group
  name: dev-team
roleRef: {kind: Role, name: pod-reader}
```

**为什么不合二为一？**
因为复用。同一个 `pod-reader` 可以绑给三个团队、五个 ServiceAccount；改规则只改一处，所有绑定自动生效。合在一起，每加一个团队就要复制一份规则，规则漂移是必然的。

这也是 GitOps 友好的形状：规则是"库"，绑定是"引用"。

### 2. 纯加法，没有 Deny

Kubernetes RBAC **没有 deny 规则**。这条经常被吐槽，但它是刻意的：

- 多作者（多个 RoleBinding）叠加时，deny 需要定义优先级和求值顺序，否则结果不可预测；
- 没有 deny，权限集合就是所有绑定规则的并集，**可推导、可缓存、可审计**；
- `kubectl auth can-i --list` 能直接列出"你实际能干什么"，不用做减法。

代价是：表达不了"除了某个 namespace 之外都能"。只能反向写成白名单。

### 3. 规则匹配的几个坑

- `resourceNames` 只对 `get / update / patch / delete` 生效，**对 `list / watch` 无效**——因为 list 返回的是集合，没法按名字预先判定；
- `verbs` 里的 `*` 包含 `deletecollection` 和 `proxy`，很多人以为只匹配增删改查；
- `ClusterRole` + `RoleBinding` 是合法组合：规则是集群级的，但只在这个 namespace 生效；
- `apiGroups: [""]` 是 core 组，写成 `["*"]` 会连 CRD 一起放行。

### 4. 聚合 ClusterRole（1.9）

```yaml
aggregationRule:
  clusterRoleSelectors:
  - matchLabels: {rbac.example.com/aggregate-to-monitoring: "true"}
```

controller 会自动把带这个标签的 ClusterRole 规则合并进来。这是给"Operator 往内置角色里加规则"准备的——比如 metrics-server 想给 `system:aggregated-metrics-reader` 加一条，不用改内置角色。

## 四、Node authorizer：RBAC 表达不了的场景

![authz-3-node.png](https://developer.qcloudimg.com/http-save/yehe-11479707/9460643aa0e51cf6716430be4581a273.png)

*图 3：判断依据不是名字，而是"这个 Secret 有没有连到我这台节点上的 Pod"。*

kubelet 需要：读**本节点上**的 Pod、Secret、ConfigMap，写自己节点的 Node status、Pod status、Event。

用 RBAC 写就是：

```yaml
resources: ["secrets"]
resourceNames: ["...每个 Pod 用到的每个 secret..."]   # 动态、且会变
```

不可行。因为"哪些 Secret 属于我"是**运行时关系**，不是静态名字。

所以有了 Node authorizer：它维护一张图（node → pod → secret/configmap/pv），从请求里取节点名（kubelet 的身份是 `system:node:<name>`），再看目标对象是否与这台节点上的 Pod 相连。有边才放行。

它需要读对象、维护 informer 和图缓存——这是"授权依赖对象语义"的少数例外。

配套的是 **NodeRestriction 准入插件**（1.7）：限制 kubelet 只能修改自己的 Node 对象、只能创建绑定到自己节点的 Pod。

**这两个必须成对出现**：只开 Node authorizer 不开 NodeRestriction，等于给 kubelet 开了越权的口子。

## 五、Webhook：把策略外包

云厂商的 IAM、企业的 OPA 策略，都不在 RBAC 的表达范围内。于是有了授权 webhook：

```
API Server --SubjectAccessReview--> 你的策略服务 --> {allowed: true/false, reason}
```

三个设计细节：

1. **默认 fail-closed**：webhook 超时或报错，按拒绝处理。这和认证 webhook 是同一个安全取向。
2. **有缓存**：`--authorization-webhook-cache-authorized-ttl` / `-unauthorized-ttl`，默认都是 5 分钟。缓存放大了"策略变更生效延迟"，排障时容易误判。
3. **它是链的一环，不是替代**：`Node,RBAC,Webhook` 可以并存，webhook 只对前面说 NoOpinion 的请求表态。

## 六、一次 403 的完整判定路径

```
请求 → 认证成功（user.Info）
     → 解析 RequestInfo（verb / resource / namespace / name）
     → 依次问 authorizer
     → 全部 NoOpinion
     → 403 Forbidden
```

403 的响应里通常带一句人类可读的 reason：

```
pods is forbidden: User "alice" cannot list resource "pods"
in API group "" in the namespace "prod"
```

**为什么 403 比 401 信息多？**
因为 401 时还没确认你是谁，多说一句都是给攻击者的枚举信号；403 时身份已经确定，告诉"你差什么权限"不会泄露额外信息，反而能省掉一轮排障。

## 七、版本时间线

| 时间 | 版本 | 变化 |
| --- | --- | --- |
| 2015 | 1.0 | ABAC、AlwaysAllow / AlwaysDeny（仅测试用） |
| 2016 | 1.5 | RBAC alpha |
| 2017 | 1.6 | RBAC beta；授权 webhook |
| 2017 | 1.7 | Node authorizer + NodeRestriction 准入 |
| 2018 | 1.8 | RBAC GA；Node authorizer GA |
| 2018 | 1.9 | ClusterRole 聚合（aggregationRule） |
| 2023 | 1.26 | ValidatingAdmissionPolicy alpha（把"看对象内容"的策略从 webhook 收回内置） |
| 2024 | 1.30 | VAP GA |

## 八、排障清单

| 现象 | 先查什么 |
| --- | --- |
| 403，但 `can-i` 说可以 | 是否用了 `--as` 之外的身份；ServiceAccount 的 namespace 是否写错 |
| RoleBinding 建了却不生效 | `roleRef` 指向的 Role 在**另一个 namespace**；跨 namespace 只能用 ClusterRole |
| 只能 list 不能 get | 规则里漏了 `get`；`list` 和 `get` 是两个 verb |
| `resourceNames` 对 list 无效 | 设计如此；list 无法按名字预判 |
| kubelet 403 | Node authorizer 是否启用；证书 CN 与节点名是否一致；NodeRestriction 是否拦了 |
| OIDC 用户组不生效 | `--oidc-groups-claim` 配了但 IdP 没返回该 claim |

常用命令：

```bash
kubectl auth can-i list pods --as=alice -n prod
kubectl auth can-i --list --as=system:serviceaccount:prod:api
kubectl auth reconcile -f role.yaml    # 幂等地修 Role / Binding
```

## 九、设计师会追问的四个问题

**1. 为什么不做 deny 规则？**
因为多来源授权叠加时，deny 需要定义求值顺序，否则同一组绑定换个顺序就是不同结果。纯并集模型牺牲了表达力，换来了可推导性。

**2. 为什么 Role 和 Binding 分离？**
规则与主体是两个变化频率不同的东西。分离后，规则可以复用、可以审计"谁能做什么"而不用展开每个主体。

**3. 为什么默认拒绝？**
新资源、新 CRD 默认不可见，是唯一安全的默认值。默认允许会把"忘记关权限"变成常态。

**4. 为什么 RBAC 看不到对象内容？**
因为授权发生在对象读取之前。要看内容就得先把对象读出来，那是准入阶段的事——这也是 ValidatingAdmissionPolicy 存在的理由：把"看字段"的策略从 webhook 收回内置，不用为了一个字段判断去跑一次网络调用。

---

**一句话收尾**：认证把凭证变成四个字段，鉴权拿这四个字段去匹配规则，匹配不上就拒绝。它之所以是链、之所以纯加法、之所以默认拒绝，都是为了让"谁能做什么"这件事**可以离线推导、可以静态审计**。

---

## 参考资料

1. Kubernetes 官方文档：[Authorization Overview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)、[Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
2. Kubernetes 源码（v1.34.0）：`staging/src/k8s.io/apiserver/pkg/authorization/`、`plugin/pkg/auth/authorizer/`
3. Kubernetes 文档：[Node Authorization](https://kubernetes.io/docs/reference/access-authn-authz/node/)、[Using Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)

> 本文为原创内容，基于 Kubernetes v1.34.0 源码整理；版本号以对应 release note 为准。

注意这里没有对象本身。授权发生在对象被读出来之前，所以它不可能知道"这个 Pod 是不是带 team=infra 标签"。

kubernetes 进阶知识-API Server 鉴权：默认拒绝，纯加法

上一篇讲认证，结论是它只产出四个字段的 user.Info。鉴权的全部工作，就是拿这四个字段去匹配规则——匹配不上就拒绝。

看起来简单，但 Kubernetes 在这里做了两个反直觉的选择：授权器是一条链，以及 RBAC 没有 deny。这两个选择决定了整套权限模型能不能被推导、被缓存、被审计。源码引用基于 Kubernetes v1.34.0。

运维开发工程师

编程语言

Kubernetes RBAC授权机制深度解析：授权发生在对象读取前，依赖对象内容的策略须放在准入层。四种authorizer构成默认拒绝链，RBAC无deny规则，采用纯加法模型。Role与Binding分离提升规则复用性，Node authorizer处理动态关系，Webhook支持外部策略集成。通过版本时间线、排障清单及设计哲学，全面理解K8s授权模型。

代码解释

Kubernetes

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Kubernetes RBAC授权机制深度解析：授权发生在对象读取前，依赖对象内容的策略须放在准入层。四种authorizer构成默认拒绝链，RBAC无deny规则，采用纯加法模型。Role与Binding分离提升规则复用性，Node authorizer处理动态关系，Webhook支持外部策略集成。通过版本时间线、排...

kubernetes 进阶知识-API Server 鉴权：默认拒绝，纯加法-腾讯云开发者社区-腾讯云

kubernetes 进阶知识-API Server 鉴权：默认拒绝，纯加法

kubernetes 进阶知识-API Server 鉴权：默认拒绝，纯加法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐