RBAC 是 Kubernetes 的基于角色的访问控制：
Role-Based Access Control它用于控制：
谁（Subject）
可以对什么资源（Resource）
执行什么操作（Verb）
在哪个范围内执行（Scope）可以抽象为：
Subject + Role + Binding = 权限例如：
ServiceAccount: app-sa
可以在 production Namespace 中
读取 Pod 和 ServiceRBAC 只负责授权，不负责身份认证。
完整访问链路是：
对应关系：
| 机制 | 作用 |
|---|---|
| Authentication | 认证身份 |
| RBAC | 授权权限 |
| Admission | 进一步校验和拦截 |
| Audit | 记录访问行为 |
如果没有权限控制，任何能够访问 Kubernetes API 的身份都可能：
RBAC 的核心目标是：
只允许身份执行完成工作所必需的操作。生产环境通常遵循：
最小权限
权限分层
Namespace 隔离
服务账号独立
Kubernetes RBAC 主要由四类对象组成：
Role
ClusterRole
RoleBinding
ClusterRoleBindingRole 定义某个 Namespace 内的权限。
含义：
允许访问 production Namespace 中的 Pod
但不允许访问其他 NamespaceRole 是 Namespace 级别的权限定义。
ClusterRole 定义集群级权限，或者定义可被绑定到 Namespace 的权限模板。
示例：
nodes 是集群级资源，因此通常需要 ClusterRole。
ClusterRole 还可以定义 Namespace 级资源的通用权限：
然后通过 RoleBinding 绑定到某个 Namespace，使权限只在该 Namespace 生效。
这是生产环境非常常见的复用模式：
一个 ClusterRole
+ 多个 Namespace 中的 RoleBindingRoleBinding 将一个 Role 或 ClusterRole 绑定给用户、组或 ServiceAccount。
示例：
含义：
production Namespace 中的 app-sa
获得 pod-reader 定义的权限RoleBinding 只能在它所在的 Namespace 中生效。
含义：
ClusterRole view 被复用，
但只在 team-a Namespace 中生效。注意：
RoleBinding 引用 ClusterRole，
不会因此获得整个集群权限。权限范围由 Binding 的位置决定。
ClusterRoleBinding 将 ClusterRole 绑定到整个集群范围。
含义：
platform-admins 获得 cluster-admin 的集群级权限。ClusterRoleBinding 风险很高，尤其是绑定：
cluster-admin生产环境应严格限制创建和修改 ClusterRoleBinding 的权限。
| 对象 | 权限定义范围 | 常见用途 |
|---|---|---|
| Role | 单个 Namespace | 团队或应用 Namespace 内权限 |
| ClusterRole | 集群级或可复用权限模板 | 节点、Namespace、集群资源 |
| RoleBinding | 在一个 Namespace 中授予权限 | 给团队或应用授权 |
| ClusterRoleBinding | 在整个集群授予权限 | 平台管理员、集群组件 |
最重要的理解：
Role/ClusterRole：定义权限
RoleBinding/ClusterRoleBinding：授予权限只有 Role 没有 Binding，权限不会生效。
只有 Binding 没有被引用的有效 Role，也不会产生预期权限。
Subject 是权限的使用者，主要有三种。
用户通常来自外部身份系统：
示例：
subjects:
- kind: User
name: alice@example.comKubernetes 通常不直接管理 User 对象，User 的身份由认证系统提供。
组通常也来自外部身份系统：
subjects:
- kind: Group
name: 生产环境推荐以 Group 授权，而不是大量单独绑定 User：
SSO Group -> RoleBinding -> Role优点：
ServiceAccount 是 Kubernetes 内部的工作负载身份。
示例：
Pod 使用：
spec:
serviceAccountName: app-sa给 ServiceAccount 授权：
注意完整身份通常是：
system:serviceaccount:production:app-saServiceAccount 适合：
RBAC 规则主要由以下字段组成：
apiGroupsAPI Group 决定资源属于哪个 API 组。
Core API Group 使用空字符串：
apiGroups:
- ""常见资源：
apiGroups:
- apps常见资源：
deployments
replicasets
statefulsets
daemonsetsapiGroups:
- batch常见资源：
jobs
cronjobsapiGroups:
- networking.k8s.io常见资源：
ingresses
networkpoliciesapiGroups:
- rbac.authorization.k8s.io常见资源：
roles
rolebindings
clusterroles
clusterrolebindings查看资源所属 API Group：
kubectl api-resourcesresources资源名称通常使用复数形式：
resources:
- pods
- services
- configmaps常见资源：
以下不是普通 pods 权限的自动延伸：
pods/log
pods/exec
pods/portforward
deployments/scale
deployments/status例如查看日志：
进入容器执行命令：
pods/exec 常见需要 create，因为执行命令通常通过创建一个 exec 请求完成。
verbs常见 Verb：
| Verb | 含义 |
|---|---|
get | 获取单个对象 |
list | 列出对象 |
watch | 监听对象变化 |
create | 创建对象 |
|
常见只读权限：
verbs:
- get
- list
- watch常见写权限：
生产环境不建议默认使用：
verbs: ["*"]resourceNames可以限制只能访问指定名称的对象：
含义：
只能读取名为 app-config 的 ConfigMap注意：
resourceNames 对 list/watch 的使用有额外限制。因为 list/watch 请求通常不包含具体资源名称。需要时可以使用字段选择器：
kubectl get configmaps \
--field-selector metadata.name=app-confignonResourceURLsRBAC 也可以授权非资源 URL：
常见非资源 URL：
/version
/healthz
/readyz
/livez
/metrics生产环境不要随意开放：
nonResourceURLs:
- "/*"Kubernetes RBAC 的基本特点是：
没有显式允许，就默认拒绝。规则之间通常是权限累加：
Role A：get pods
Role B：delete pods
最终：get + delete podsRBAC 本身不提供传统意义上的：
允许所有，但拒绝某个资源如果需要复杂条件限制，例如：
允许创建 Deployment，但禁止使用 hostNetwork
允许创建 Pod，但禁止 privileged
允许修改镜像，但禁止修改资源需要配合：
Kubernetes 通常提供一些默认 ClusterRole：
view
edit
admin
cluster-adminview通常是只读权限：
查看大多数 Namespace 内资源但通常不允许读取：
Secrets因为 Secret 读取等同于获得敏感凭据。
edit通常允许修改 Namespace 内多数资源，但不代表能够修改 RBAC 或获得完整集群管理权。
仍然需要谨慎，因为创建某些资源可能间接带来较高权限。
admin通常用于 Namespace 管理员，权限范围比 edit 更高。
cluster-admin几乎拥有完整集群权限：
verbs:
- "*"
resources:
- "*"应极其谨慎使用。
查看默认角色：
Kubernetes 支持 ClusterRole 聚合。
例如：
这个 ClusterRole 的规则会聚合到默认 view 角色中。
常见标签：
rbac.authorization.k8s.io/aggregate-to-view: "true"
rbac.authorization.k8s.io/aggregate-to-edit: "true"
rbac.authorization.k8s.io/aggregate-to-admin: "true"生产环境修改默认聚合角色时要谨慎，因为可能影响整个集群中所有绑定该角色的身份。
例如：
pods
deployments
services
configmaps
可以通过：
Role + RoleBinding限制在某个 Namespace。
例如：
nodes
namespaces
persistentvolumes
通常需要：
ClusterRole + ClusterRoleBinding可以用：
ClusterRole + RoleBinding实现：
权限定义集中复用
授权范围仍然局限在某个 Namespace这是团队只读、开发权限和平台角色常见的生产模式。
Pod：
spec:
serviceAccountName: config-reader这是比下面更安全的方式：
因为后者可能读取 Namespace 中所有 Secret。
开发团队只能在：
development Namespace使用 view 权限。
不能访问：
production除非另外配置 Binding。
注意：
edit 不是绝对安全的“开发权限”。允许创建和修改工作负载，可能间接访问：
要结合具体集群策略审查。
不要让业务 Pod 使用人类用户身份，也不要让开发者共享应用 ServiceAccount。
推荐：
不推荐：
serviceAccountName: default也不推荐多个应用共享一个高权限 ServiceAccount。
推荐：
原因：
如果 Pod 不需要访问 Kubernetes API：
或者在 Pod 级别：
spec:
automountServiceAccountToken: false这可以减少：
Token 泄露后的攻击面推荐按以下维度拆分 Namespace：
team-a-dev
team-a-staging
team-a-prod
team-b-prod
platform-monitoring
platform-loggingNamespace 不只是逻辑分组，还可以作为：
不推荐给大量 User 创建独立 Binding：
更推荐：
subjects:
- kind: Group
name: team-a-developers人员加入或离开团队时，只修改外部身份组。
cluster-admin以下对象不应轻易绑定 cluster-admin：
只有真正需要集群全局管理的身份才应使用。
读权限可能导致：
信息泄露写权限可能导致：
应用替换
Secret 替换
恶意 Pod 创建
权限提升
集群接管特别危险的能力包括：
secrets 的读取权限可以读取 Secret，通常意味着可以读取：
因此不要轻易授予：
优先使用：
resourceNames:
- specific-secret并尽量避免 list。
pods/exec允许进入容器：
resources:
- pods/exec
verbs:
- create这意味着使用者可能：
生产环境建议：
允许创建 Pod 可能间接获得较高权限。
例如用户创建一个 Pod：
hostNetworkprivileged因此：
允许创建 Pod ≠ 低风险权限需要配合：
如果用户可以创建或修改 RoleBinding，可能把已有高权限 Role 授予自己。
这属于典型的权限提升风险。
特别要保护：
rolebindings
clusterrolebindings
roles
clusterrolesbind 和 escalateKubernetes 对角色绑定和权限提升有额外保护。
高风险操作包括：
bind
escalate
impersonate这些权限应只授予：
不要把这些 Verb 放进普通团队角色。
RBAC 负责：
谁可以创建和操作资源Pod Security 负责：
创建的 Pod 是否满足安全约束例如：
RBAC 允许开发者创建 Pod
Pod Security 禁止 privileged 和 hostNetwork两者应该配合：
RBAC：限制 API 操作权限
Pod Security：限制 Pod 的安全能力
Admission Policy：限制组织级规则仅有 RBAC 不足以防止高风险 Pod 配置。
Pod 使用 ServiceAccount 后，可能通过挂载 Token 访问 Kubernetes API。
检查 Pod 是否挂载 Token：
如果应用不需要 Kubernetes API，建议：
automountServiceAccountToken: false如果需要访问 API，应：
现代 Kubernetes 通常使用短期、可轮换的 ServiceAccount Token。
可以通过 TokenRequest API 获取：
kubectl create token app-sa -n production相比长期静态 Token，短期 Token 更适合：
生产环境应避免把长期 ServiceAccount Token 写死在：
kubectl auth whoami具体支持情况取决于 Kubernetes 版本。
kubectl auth can-i get pods -n production检查指定用户：
kubectl auth can-i get pods
检查 ServiceAccount：
kubectl auth can-i get
kubectl auth can-i --list -n production查看指定身份：
kubectl auth can-i --list \
--as=system:serviceaccount:production:app-sa
查看详情：
kubectl get serviceaccount -n
kubectl api-resources
kubectl api-versions应用 Pod：
spec:
serviceAccountName: config-watcher适合：
不授予：
verbs:
- list
- watch这样可以减少读取其他 Secret 的风险。
生产 Namespace 不配置对应 Binding：
team-a-developers 无法访问 team-a-prod如果只需要查看生产状态，可以单独绑定：
自定义 Role：
绑定给 CI ServiceAccount：
注意跨 Namespace ServiceAccount 的写法：
subject namespace: cicd
binding namespace: productionBinding 的作用范围是 production，被授权的身份来自 cicd Namespace。
绑定给 DaemonSet 使用的 ServiceAccount：
节点是集群级资源，因此通常需要 ClusterRole。
假设 Operator 管理：
databases.example.com需要权限：
实际权限应根据 Operator 代码访问的资源最小化，不要直接给：
resources: ["*"]
verbs: ["*"]集群级管理
节点、Namespace、StorageClass、RBAC、网络和安全策略通常需要较高权限，但应使用：
只管理指定 Namespace可以允许：
通常不应默认允许：
开发 Namespace edit
生产 Namespace view 或受限发布权限只管理指定 Namespace
只操作必要资源
独立 ServiceAccount
不使用 cluster-admin只访问必要的 ConfigMap、Secret 或自定义资源
默认不访问 Kubernetes API只读访问节点、Pod、Namespace、Endpoint 等必要资源kubectl get clusterrolebindings -o yaml重点查找：
cluster-admin
system:masters
匿名用户
普通 ServiceAccount
外部第三方账号kubectl get roles,clusterroles -A -o yaml重点审查：
通配符会使未来新增资源也可能自动获得权限，风险较高。
查找允许读取 Secret 的角色：
kubectl get roles,clusterroles -A -o yaml重点审查：
重点审查：
resources:
- pods
verbs:
- create以及：
resources:
- pods/exec
verbs:
- createverbs:
- impersonate
- bind
- escalate这些权限需要极少数身份持有。
生产环境建议启用 Kubernetes Audit。
审计日志可以记录：
重点关注：
读取 Secret
pods/exec
删除生产 Pod
RBAC 审计回答的是：
这个身份理论上能做什么？Audit 回答的是：
这个身份实际上做了什么？两者需要结合使用。
生产 RBAC 建议：
Git 管理
代码审查
自动化部署
变更审批
定期审计
目录示例：
rbac/
├── namespaces/
每次变更应说明：
谁需要权限
需要访问哪些资源
需要哪些 Verb
权限作用范围
不会。
必须有：
RoleBinding或：
ClusterRoleBinding不一定。
如果是：
RoleBinding + ClusterRole权限通常只在 RoleBinding 所在 Namespace 生效。
真正集群范围的是：
ClusterRoleBinding + ClusterRolepods 权限包括查看日志和执行命令不完全包括。
通常需要单独授权：
pods/log
pods/execget pods 就可以列出所有 Pod不行。
列出通常需要：
list pods监听变化需要：
watch podsRBAC 只能控制：
API 资源和操作不能控制：
Pod 是否 privileged
是否使用 hostNetwork
镜像来自哪里
资源是否填写这些需要 Admission Policy 或 Pod Security。
ServiceAccount 主要是工作负载身份，不应代替人类用户账号。
默认 ServiceAccount 可能通过其他 Binding 获得权限，也可能被错误复用。
应检查：
kubectl get rolebindings,clusterrolebindings -A -o yamlKubernetes 通常不管理外部 User 对象。外部身份系统中的用户离职后，还要确认：
Kubernetes RBAC 的核心模型：
Subject
+ Role 或 ClusterRole
+ RoleBinding 或 ClusterRoleBinding
= 权限四个核心对象：
权限规则由以下内容组成：
apiGroups
resources
resourceNames
verbs
nonResourceURLsSubject 主要包括：
User
Group
ServiceAccount生产环境推荐：
最核心的一句话是：
RBAC 负责回答“谁可以对什么 Kubernetes 资源执行什么操作”，
但不负责判断请求内容是否安全。完整的生产授权体系通常是：
Authentication：确认身份
RBAC：授予资源操作权限
Pod Security/Admission：限制资源内容
NetworkPolicy：限制网络访问
Audit：记录实际行为一个成熟的 Kubernetes 权限模型，不是给所有人 cluster-admin，而是把权限拆成：
每个身份只获得完成工作所必需的最小权限。 还有一些 RBAC 的高级边界和生产实践值得补充。
只能访问 RoleBinding 所在 NamespaceClusterRole 中的 Namespace 级权限，
只在 RoleBinding 所在 Namespace 生效ClusterRole 中的 Namespace 级资源和集群级资源，
按集群范围生效但要注意：
RoleBinding 不能把集群级资源变成 Namespace 级资源例如 nodes、namespaces、persistentvolumes 本身是集群级资源。即使在某个 Namespace 创建 RoleBinding，也不能通过它只授权“某 Namespace 的 nodes”。
如果一个身份同时绑定：
Role A：get pods
Role B：delete pods最终权限是：
get pods + delete podsRBAC 没有传统 ACL 中常见的：
允许所有权限，但拒绝删除 Pod因此需要谨慎处理：
排查权限时不能只看某一个 Binding。
system:masters 是高风险特殊组Kubernetes 中的：
system:masters通常被视为超级管理员组。
将用户加入该组，或者让外部认证系统把用户映射到该组，风险极高。它不应作为普通平台管理员的日常权限方案。
生产建议：
system:mastersimpersonateimpersonate 允许一个身份模拟另一个用户、组或 ServiceAccount。
例如：
模拟请求示例：
kubectl auth can-i get
模拟能力适合：
但如果普通用户拥有对高权限身份的 impersonate，可能直接绕过原有权限边界。
应严格限制：
谁可以 impersonate
可以模拟哪些身份
可以模拟哪些 Group
是否需要审计bind 和 escalatebind允许身份将角色绑定给其他 Subject。
escalate允许身份创建或修改权限高于自身的 Role 或 ClusterRole。
这两个权限都可能造成权限提升。
例如用户本身没有读取 Secret 的权限，但如果可以：
创建一个包含 secrets/get 的 Role
再把该 Role 绑定给自己就可能获得额外权限。
生产环境应特别审查：
verbs:
- bind
- escalate
- impersonate这些权限通常只授予：
即使用户不能直接修改 RoleBinding，也可能通过创建高权限 Pod 间接提升权限。
例如允许创建 Pod 的身份，如果还能指定：
serviceAccountName: privileged-sa就可能借用高权限 ServiceAccount。
其他高风险能力包括：
或者挂载：
/var/run/containerd/containerd.sock
/var/run/docker.sock因此生产环境必须组合：
RBAC
+ Pod Security Admission
+ Admission Policy
+ ServiceAccount 限制
+ 镜像策略
+ NetworkPolicy仅靠 RBAC 不能阻止所有权限提升路径。
pods/exec 和 pods/attach 要单独审计除了：
pods/exec还要关注：
pods/attach
pods/portforward
pods/log常见风险：
| 子资源 | 风险 |
|---|---|
pods/exec | 进入容器执行命令 |
pods/attach | 连接容器进程 |
pods/portforward | 绕过部分网络入口访问 Pod |
pods/log | 可能读取敏感信息 |
|
生产环境建议：
pods/logexec 采用临时授权portforward 限制到特定运维组get Secret 和 list Secret 都很敏感以下权限风险不同：
verbs:
- get表示可以读取指定对象，若配合 resourceNames，范围可以更小。
verbs:
- list
- watch可能让身份获取 Namespace 中大量 Secret 的元数据或内容，具体行为还受 API 请求形式影响。
如果应用只需要读取一个 Secret，优先：
避免给：
resourceNames 不能解决所有访问限制resourceNames 适合限制：
只能访问指定名称的对象但它有边界：
list 请求通常没有具体资源名称watch 也不一定能按名称自然限制例如 RBAC 不能表达：
允许修改 Deployment 镜像
但不允许修改 replicas这类规则需要：
RBAC 只能表达：
某身份能否对某资源执行某个 Verb不能表达：
只能创建 2 CPU 以下的 Pod
只能使用指定镜像仓库
不能使用 privileged
不能使用 hostNetwork
只能修改自己的 Deployment
只能访问带某个标签的 Pod对应能力：
| 需求 | 推荐机制 |
|---|---|
| 禁止 privileged | Pod Security Admission |
| 限制镜像仓库 | Admission Policy |
| 限制资源范围 | LimitRange |
| 限制 Namespace 总量 | ResourceQuota |
| 限制字段内容 | Kyverno/Gatekeeper/CEL |
| 限制网络 | NetworkPolicy |
SelfSubjectRulesReview 分析当前权限可以让当前身份查询自己在某个 Namespace 的有效规则：
命令行通常更方便：
kubectl auth can-i --list -n production对于指定身份：
kubectl auth can-i --list \
--as=system:serviceaccount:production:app-sa
生产排障中建议同时检查：
Kubernetes 对部分默认 RBAC 角色和绑定具有自动协调机制。
如果直接修改系统默认角色，例如：
view
edit
admin
cluster-admin控制面可能在启动或同步时恢复默认规则，或者后续升级行为发生变化。
更安全的做法是：
创建自定义 ClusterRole而不是直接修改内置角色。
如果使用聚合标签扩展默认角色，需要明确知道：
这个权限会影响所有绑定该默认角色的身份推荐使用组织或平台前缀：
company-team-a-view
platform-monitor-read
example-database-operator避免使用过于通用的名称：
admin
operator
reader
manager这样可以减少：
下面两个 ServiceAccount 是不同身份：
system:serviceaccount:team-a:app
system:serviceaccount:team-b:app即使名称都叫：
app也不是同一个身份。
RoleBinding 示例：
跨 Namespace 给 ServiceAccount 授权时必须写对：
Binding 所在 Namespace：权限生效范围
Subject 的 Namespace：身份所属位置不建议一个 CI ServiceAccount 管理所有 Namespace。
更合理的设计：
ci-team-a-dev
ci-team-a-staging
ci-team-a-prod分别绑定：
team-a-dev
team-a-staging
team-a-prod如果确实需要跨多个 Namespace，应明确：
CI/CD 账号一旦泄露，影响通常比单个业务 Pod 更大。
允许修改 Deployment 通常意味着可以修改 Pod Template，包括：
serviceAccountName
volumes
securityContext
image
command
如果用户可以修改 Deployment，并且 Namespace 中存在高权限 ServiceAccount，可能间接让业务 Pod 使用高权限身份。
因此：
允许 update deployments不一定是低风险权限。
生产发布平台应考虑：
审计不能只搜索某个 Role 文件，还要分析：
Subject
-> RoleBinding
-> Role/ClusterRole
建议定期生成：
用户 -> Namespace -> 资源 -> Verb
Group -> Namespace -> 资源 -> Verb
ServiceAccount -> 资源 -> Verb重点关注：
谁能读取 Secret
谁能创建 Pod
谁能执行 exec
对于生产排障，可以采用：
临时 RoleBinding
-> 完成操作
-> 自动或人工删除示例：
完成后删除：
kubectl delete rolebinding temporary-debug -n production更成熟的方式是使用权限提升平台，自动实现：
不要为了方便永久授予：
cluster-admin每次 RBAC 变更后，至少验证：
kubectl auth can-i ...同时验证：
RBAC 变更应具备：
Git 版本
变更审批
自动校验
灰度环境
回滚文件
审计记录常用思路包括：
kubectl auth can-i
RBAC Review
权限图分析
策略扫描器
CI 中的 YAML 校验CI 阶段可以检查：
推荐分层：
最终可以这样判断一个 RBAC 设计是否成熟：
最终结论：
RBAC 解决“谁能对什么资源做什么操作”；
它是 Kubernetes 授权的基础，但不是完整安全体系。生产环境应将 RBAC 与：
组合使用。最重要的原则仍然是：
默认拒绝、最小权限、范围明确、身份独立、可审计、可回收。有，但前面的内容已经覆盖了 RBAC 的主体。最后补充一些更底层的授权机制和生产边界。
Kubernetes API Server 的授权模式可以通过配置启用多种机制，例如：
RBAC
Node
Webhook
ABAC（历史机制，不推荐新系统使用）常见组合类似：
--authorization-mode=Node,RBAC含义：
Node：允许 kubelet 访问它需要管理的节点和 Pod 资源RBAC：根据 Role 和 Binding 判断普通身份权限Webhook：把授权请求交给外部授权系统通常生产集群至少使用：
Node,RBAC如果有复杂组织权限模型，可以额外使用 Webhook，但必须考虑：
Kubelet 使用的身份通常类似：
system:node:<node-name>Node Authorizer 用于限制 kubelet 能访问的对象，避免一个节点上的 kubelet读取不属于自己的敏感资源。
生产环境应确保：
Node Authorizer 保护的是节点代理访问边界，不是业务用户权限。
API Server 的匿名认证可能允许未认证请求以类似身份访问：
system:anonymous
system:unauthenticated生产环境应检查：
kubectl get clusterrolebindings -o yaml
kubectl get clusterroles确认没有把高权限角色绑定给：
system:anonymous
system:unauthenticated还要检查 API Server 是否启用了匿名认证，以及哪些健康检查端点允许匿名访问。
原则：
匿名访问只能用于确实需要公开的健康检查接口。Kubernetes 不验证 Group 名称是否真实存在。它通常直接信任认证层提供的 Group 信息。
因此，如果 OIDC、LDAP 或云 IAM 配置错误，可能出现：
用户被错误加入高权限组生产环境要同时审计：
RBAC 文件本身正确，不代表外部 Group 映射一定正确。
允许删除 Namespace 是非常高风险的集群级权限：
删除 Namespace 通常会级联影响：
生产环境通常只允许：
平台管理员
受控的 Namespace 管理平台并建议增加：
自定义资源通常可能包含：
widgets
widgets/status
widgets/finalizersOperator 的角色如果只写：
resources:
- widgets可能无法更新：
status
finalizers典型示例：
排查 Operator 权限时，必须检查它实际访问的所有资源和子资源。
例如：
deployments
deployments/scale
deployments/status可以分别授权：
这样某个自动扩缩组件可以只修改副本数，而不一定拥有完整 Deployment 修改权限。
这是比直接授予：
resources:
- deployments
verbs:
- update更细粒度的做法。
但要注意，修改完整 Deployment 的权限可能仍然带来更高风险，因为它可以修改 PodTemplate 和 ServiceAccount。
deletecollection 容易被忽略以下权限：
verbs:
- deletecollection允许批量删除资源。
它可能造成：
批量删除 Pod
批量删除 Job
批量删除 ConfigMap
批量删除其他对象普通开发和应用 ServiceAccount 通常不需要这个 Verb。
如果某个清理控制器确实需要，应限制：
watch 权限可能暴露持续变化watch 不只是“查看一次”，而是持续监听资源变化。
例如允许监听 Secret、ConfigMap 或 Pod，可能让应用持续获取：
Controller 通常需要：
get
list
watch但普通业务 Pod 未必需要 watch。权限设计应区分：
单次读取：get
批量读取：list
持续监听：watch即使 RBAC 限制了 Secret 访问，也建议启用 etcd 静态加密：
Encryption at Rest因为 Secret 还可能通过以下方式泄露：
kubectl describepods/exec生产 Secret 管理应组合：
RBAC
+ etcd 加密
+ 外部密钥管理
+ Vault/KMS
只审计 Kubernetes API 权限是不够的，还要检查：
例如一个用户虽然不能读取 Kubernetes Secret，但如果可以：
读取 CI/CD 变量
读取应用日志
执行 pods/exec
访问云平台 IAM仍然可能取得同样的凭据。
因此 RBAC 审计应放在完整身份和数据访问链路中考虑。
删除 RoleBinding 后，新的 API 请求通常会按最新授权判断，但以下因素可能造成“权限似乎还在”：
撤权流程应包括：
删除 Binding
禁用外部身份
撤销或等待 Token 过期
终止现有会话
检查审计日志
确认 can-i 结果对于高风险账号，不能只删除一条 RoleBinding 就认为所有访问路径都已关闭。
变更前后比较：
重点查看：
新增了哪些 Subject
新增了哪些资源
新增了哪些 Verb
是否扩大了 Namespace 范围
是否从 RoleBinding 变成 ClusterRoleBinding
是否增加 Secret、exec、create Pod生产流水线可以把这些检查自动化，遇到以下内容要求人工审批：
如果应用确实需要 API，再显式开启，并绑定最小 Role。
这个模板体现：
独立身份
默认不挂载 Token
Namespace 内授权
指定资源名称
只给 getRBAC 的完整安全模型可以归纳为：
最重要的生产原则仍然是：
到这里，RBAC 从基本对象、权限模型、Subject、Role 绑定、ServiceAccount、子资源、权限提升、审计、认证集成、Operator、CI/CD 到生产治理边界，已经基本完整。 RBAC 的核心内容已经基本覆盖完整，再继续扩展主要就是平台安全和运维治理的相邻内容，而不是新的 RBAC 核心概念。
还可以继续深入的方向包括：
Kubernetes 认证体系
RBAC 高级审计
pods/execRBAC 与 Pod 安全联动
RBAC 与多租户
RBAC 与 CI/CD
cluster-adminRBAC 与 Operator
可以把 RBAC 最终记成：
Authentication：你是谁
RBAC：你能操作什么资源
Admission：你提交的对象是否合规
Pod Security：Pod 能具备什么能力
NetworkPolicy：Pod 能和谁通信
Audit：你实际做了什么生产中真正成熟的方案不是单独部署 RBAC，而是：
因此，除非继续深入某个具体方向，例如“RBAC 与 OIDC 集成”“生产权限设计模板”“RBAC 故障排查”或“最小权限实战”，RBAC 本身已经没有新的核心知识点需要补充了。
用户或程序发起请求
|
v
Authentication：你是谁？
|
v
Authorization：你能做什么？
|
v
Admission：这次请求是否符合策略？
|
v
执行或拒绝apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: production
rules:
- apiGroups: [""]
resources:
- pods
verbs:
- get
- list
- watchapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-reader
rules:
- apiGroups: [""]
resources:
- nodes
verbs:
- get
- list
- watchapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources:
- pods
verbs:
- get
- list
- watchapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: api-readers
namespace: production
subjects:
- kind: ServiceAccount
name: app-sa
namespace: production
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pod-readerapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: team-a-readonly
namespace: team-a
subjects:
- kind: Group
name: team-a
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: viewapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: platform-admins
subjects:
- kind: Group
name: platform-admins
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-adminapiVersion: v1
kind: ServiceAccount
metadata:
name: app-sa
namespace: productionsubjects:
- kind: ServiceAccount
name: app-sa
namespace: productionrules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watchpods
services
configmaps
secrets
nodes
namespaces
persistentvolumeclaims
serviceaccountspods
pods/log
pods/exec
deployments
deployments/status
deployments/scale
services
secrets
configmaps
jobs
cronjobs
nodes
namespaces
persistentvolumeclaimsrules:
- apiGroups: [""]
resources:
- pods
- pods/log
verbs:
- getrules:
- apiGroups: [""]
resources:
- pods
- pods/exec
verbs:
- get
- create| 完整更新对象 |
patch | 局部修改对象 |
delete | 删除对象 |
deletecollection | 批量删除 |
impersonate | 冒充其他身份 |
bind | 绑定角色 |
escalate | 创建权限高于自身的角色 |
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: read-specific-config
namespace: production
rules:
- apiGroups: [""]
resources:
- configmaps
resourceNames:
- app-config
verbs:
- getapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: health-reader
rules:
- nonResourceURLs:
- "/healthz"
- "/version"
verbs:
- getkubectl get clusterrole view -o yaml
kubectl get clusterrole edit -o yaml
kubectl get clusterrole admin -o yaml
kubectl get clusterrole cluster-admin -o yamlapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: custom-view
labels:
rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups:
- example.com
resources:
- widgets
verbs:
- get
- list
- watchapiVersion: v1
kind: ServiceAccount
metadata:
name: config-reader
namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: configmap-reader
namespace: production
rules:
- apiGroups: [""]
resources:
- configmaps
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: config-reader-binding
namespace: production
subjects:
- kind: ServiceAccount
name: config-reader
namespace: production
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: configmap-readerapiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: app-secret-reader
namespace: production
rules:
- apiGroups: [""]
resources:
- secrets
resourceNames:
- app-secret
verbs:
- getresources:
- secrets
verbs:
- get
- list
- watchapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developers-view
namespace: development
subjects:
- kind: Group
name: developers
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: viewapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: team-a-edit
namespace: team-a
subjects:
- kind: Group
name: team-a
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: edit人类用户：
OIDC User/Group
业务 Pod：
独立 ServiceAccount
CI/CD：
独立 ServiceAccount
平台组件：
独立 ServiceAccountapiVersion: v1
kind: ServiceAccount
metadata:
name: order-api
namespace: productionapiVersion: v1
kind: ServiceAccount
metadata:
name: app
namespace: production
automountServiceAccountToken: falsesubjects:
- kind: User
name: alice
- kind: User
name: bob
- kind: User
name: carol创建 Pod
创建 Deployment
修改 ServiceAccount
修改 RoleBinding
修改 ClusterRoleBinding
读取 Secrets
使用 pods/exec
使用 impersonateresources:
- secrets
verbs:
- get
- list
- watchkubectl get roles -A
kubectl get rolebindings -A
kubectl get clusterroles
kubectl get clusterrolebindingskubectl describe role <role-name> -n <namespace>
kubectl describe rolebinding <binding-name> -n <namespace>
kubectl describe clusterrole <role-name>
kubectl describe clusterrolebinding <binding-name>apiVersion: v1
kind: ServiceAccount
metadata:
name: config-watcher
namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: configmap-watcher
namespace: production
rules:
- apiGroups: [""]
resources:
- configmaps
resourceNames:
- app-config
verbs:
- get
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: config-watcher
namespace: production
subjects:
- kind: ServiceAccount
name: config-watcher
namespace: production
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: configmap-watcherapiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: order-api-secret-reader
namespace: production
rules:
- apiGroups: [""]
resources:
- secrets
resourceNames:
- order-api-secret
verbs:
- getapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-team-access
namespace: team-a-dev
subjects:
- kind: Group
name: team-a-developers
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: editkind: RoleBinding
metadata:
name: dev-team-prod-view
namespace: team-a-prod
subjects:
- kind: Group
name: team-a-developers
roleRef:
kind: ClusterRole
name: viewapiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployer
namespace: production
rules:
- apiGroups:
- apps
resources:
- deployments
- deployments/scale
verbs:
- get
- list
- watch
- create
- update
- patch
- apiGroups:
- ""
resources:
- services
- configmaps
verbs:
- get
- list
- watch
- create
- update
- patch
- apiGroups:
- ""
resources:
- pods
- pods/log
verbs:
- get
- list
- watchapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: ci-deployer
namespace: production
subjects:
- kind: ServiceAccount
name: ci
namespace: cicd
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: deployerapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-monitor
rules:
- apiGroups: [""]
resources:
- nodes
- nodes/metrics
verbs:
- get
- list
- watch
- apiGroups: [""]
resources:
- pods
- namespaces
verbs:
- get
- list
- watchapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: node-monitor
subjects:
- kind: ServiceAccount
name: node-monitor
namespace: monitoring
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: node-monitorapiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: database-operator
rules:
- apiGroups:
- example.com
resources:
- databases
- databases/status
- databases/finalizers
verbs:
- get
- list
- watch
- create
- update
- patch
- delete
- apiGroups:
- apps
resources:
- deployments
- statefulsets
verbs:
- get
- list
- watch
- create
- update
- patch
- delete
- apiGroups:
- ""
resources:
- services
- configmaps
- secrets
verbs:
- get
- list
- watch
- create
- update
- patch
- deleteresources:
- secrets
verbs:
- get
- list
- watchRole：
Namespace 内的权限定义
ClusterRole：
集群级权限或可复用权限模板
RoleBinding：
在一个 Namespace 中授予 Role/ClusterRole
ClusterRoleBinding：
在整个集群授予 ClusterRole人类用户使用 OIDC/SSO Group
应用使用独立 ServiceAccount
默认关闭不需要的 Token
优先 Role + RoleBinding
谨慎使用 ClusterRoleBinding
禁止普通身份使用 cluster-admin
避免通配符权限
限制 Secret、pods/exec、Pod 创建和 RBAC 修改权限
配合 Pod Security 和 Admission Policy
启用 Audit
GitOps 管理 RBAC
定期审计和回收权限rules:
- apiGroups: [""]
resources:
- users
- groups
- serviceaccounts
verbs:
- impersonatehostNetwork: true
hostPID: true
privileged: true
hostPath: /| 注入临时调试容器 |
resources:
- secrets
resourceNames:
- app-secret
verbs:
- getresources:
- secrets
verbs:
- get
- list
- watchapiVersion: authorization.k8s.io/v1
kind: SelfSubjectRulesReview
spec:
namespace: productionkubectl auth can-i get pods -n production
kubectl auth can-i get secrets -n production
kubectl auth can-i create pods -n production
kubectl auth can-i create pods/exec -n production
kubectl auth can-i create rolebindings -n productionsubjects:
- kind: ServiceAccount
name: app
namespace: team-akubectl create rolebinding temporary-debug \
--role=debug-reader \
--user=alice@example.com \
-n production[ ] 是否出现 cluster-admin 绑定
[ ] 是否出现通配符权限
[ ] 是否允许读取所有 Secret
[ ] 是否允许 impersonate
[ ] 是否允许 bind/escalate
[ ] 是否允许 privileged Pod
[ ] ServiceAccount 是否独立
[ ] 是否设置 automountServiceAccountToken
[ ] RoleBinding Namespace 是否正确第一层：身份系统
OIDC、SSO、LDAP、云 IAM
第二层：RBAC
User、Group、ServiceAccount、Role、Binding
第三层：内容策略
Pod Security、Kyverno、Gatekeeper、CEL
第四层：网络策略
NetworkPolicy、Service Mesh、云防火墙
第五层：行为审计
Kubernetes Audit、SIEM、操作日志
第六层：定期治理
权限回收、临时授权、越权分析、离职清理[ ] 人类用户是否通过 Group 授权
[ ] 应用是否使用独立 ServiceAccount
[ ] 是否避免默认 ServiceAccount
[ ] 是否关闭不需要的 Token 自动挂载
[ ] 是否尽量使用 RoleBinding 而非 ClusterRoleBinding
[ ] 是否避免 cluster-admin
[ ] 是否避免通配符
[ ] 是否限制 Secret、exec、Pod 创建权限
[ ] 是否审查 bind、escalate、impersonate
[ ] 是否有 Pod Security 和 Admission 策略
[ ] 是否启用 Audit
[ ] 是否支持临时授权和自动回收
[ ] 是否有权限变更审批和回滚
[ ] 是否定期检查离职账号和无主绑定Authentication
Pod Security
Admission Policy
NetworkPolicy
Secret 管理
Audit
临时权限
权限审计apiGroups:
- ""
resources:
- namespaces
verbs:
- deleterules:
- apiGroups:
- example.com
resources:
- widgets
- widgets/status
- widgets/finalizers
verbs:
- get
- list
- watch
- create
- update
- patch
- deletecluster-admin
*
secrets
pods/exec
rolebindings
clusterrolebindings
impersonate
bind
escalateapiVersion: v1
kind: ServiceAccount
metadata:
name: order-api
namespace: production
automountServiceAccountToken: falseapiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: order-api-config-reader
namespace: production
rules:
- apiGroups: [""]
resources:
- configmaps
resourceNames:
- order-api-config
verbs:
- getapiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: order-api-config-reader
namespace: production
subjects:
- kind: ServiceAccount
name: order-api
namespace: production
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: order-api-config-reader[ ] 是否启用 RBAC
[ ] 是否启用 Node Authorizer
[ ] 是否启用 NodeRestriction
[ ] 是否关闭不必要的匿名访问
[ ] 人类用户是否通过 SSO/OIDC Group 授权
[ ] 应用是否使用独立 ServiceAccount
[ ] 是否关闭不需要的 Token 自动挂载
[ ] 是否优先使用 Role + RoleBinding
[ ] 是否限制 ClusterRoleBinding
[ ] 是否避免 cluster-admin
[ ] 是否避免 apiGroups/resources/verbs 通配符
[ ] 是否审查 secrets
[ ] 是否审查 pods/exec、attach、portforward
[ ] 是否审查 Pod create
[ ] 是否审查 bind、escalate、impersonate
[ ] 是否限制 deletecollection
[ ] 是否限制 Namespace 删除
[ ] 是否正确授权 CRD 子资源
[ ] 是否限制 Deployment 修改权限
[ ] 是否使用 Pod Security 和 Admission Policy
[ ] 是否配置 NetworkPolicy
[ ] 是否启用 Audit
[ ] 是否有临时授权机制
[ ] 是否定期回收离职和无主权限
[ ] 是否有 RBAC 变更审批和回滚
[ ] 是否测试 can-i 和实际业务流程认证系统确认身份
RBAC 决定资源操作权限
Admission 限制对象内容
Pod Security 限制运行时能力
NetworkPolicy 限制网络访问
Secret/KMS 保护敏感数据
Audit 记录实际行为
权限治理负责回收和复核默认拒绝
最小权限
Namespace 隔离
身份独立
避免通配符
限制高风险子资源
禁止无必要的 cluster-admin
权限变更可审计
权限可临时提升
权限可及时回收finalizersRBAC 故障排查
kubectl auth can-iSelfSubjectRulesReviewRoleBinding 和 ClusterRoleBindingforbidden、cannot list resource、cannot create resourceRBAC 自动化治理
cluster-adminSSO/OIDC
+ RBAC
+ Pod Security Admission
+ Admission Policy
+ NetworkPolicy
+ Secret/KMS
+ Audit
+ 临时授权
+ 定期权限审计