第九章 Kubernetes集群安全机制：鉴权（一）
1. 鉴权的基本概念
- 鉴权是Kubernetes安全机制的第二个核心环节，承接上一节讲解的认证（Authentication） 环节：认证仅确认访问主体是集群可信组件、Pod等「自己人」，但无法确认其操作是否具备权限，因此需要鉴权对操作权限进行校验。
- 当前Kubernetes生态默认采用基于双向HTTPS认证方案，组件间、Pod与API Server之间均通过双向认证确认身份，认证通过后才进入鉴权环节。
2. Kubernetes支持的鉴权模式
Kubernetes在启动API Server时可通过--authorization-mode参数配置鉴权模式，主流模式包括4类：
2.1 基础鉴权模式（生产环境极少使用）
- AlwaysDeny（拒绝所有）：所有请求直接拒绝，无实际生产价值。
- AlwaysAllow（允许所有）：所有请求直接放行，相当于无鉴权，安全性极低，生产环境不会采用。
2.2 ABAC（Attribute-Based Access Control，基于属性的访问控制）
- 逻辑类比Linux文件系统的权限模型：通过用户、属主、其他用户等属性，配置对应资源的读、写、执行权限，配置逻辑清晰简单。
- 缺点：批量配置权限非常繁琐，且部分Kubernetes资源对象无法通过ABAC配置权限，当前已基本不再使用。
2.3 Webhook鉴权
- 逻辑：通过调用外部RESTful接口实现鉴权逻辑，将鉴权能力交给外部系统实现。
- 类比OpenStack生态中的Keystone组件：Keystone是OpenStack的统一3A（认证、授权、计费）服务，可为OpenStack各模块（Nova、Glance、网络服务等）提供统一的鉴权能力，且已开源。
- 适用场景：若需要统一管理Kubernetes、OpenStack等多平台的权限，可通过类似Keystone的外部服务实现，优点是管理统一，缺点是整体复杂度较高，当前使用场景较少。
- 补充：Rancher公司开源的Harvest项目，可在Kubernetes平台内提供RBAC即服务（RBAC as a Service, RaaS），降低多平台权限管理的复杂度。
2.4 RBAC（Role-Based Access Control，基于角色的访问控制）
- 基础信息：Kubernetes 1.5版本引入，当前版本已作为默认鉴权模式，是生产环境的主流选择。
- 核心优势：
- 权限覆盖全面：集群所有资源、非资源（如API接口访问权限）均可配置权限。
- 全API化操作：RBAC的所有配置均通过API对象实现，可通过
kubectl、API接口直接操作，方便二次开发、自动化集成，无需修改集群内部配置。 - 运行时生效：权限调整后无需重启API Server，配置立即生效，运维效率高。
3. RBAC核心资源对象与作用域
RBAC通过4个顶级资源对象实现权限管理，按作用域分为两类：
| 资源对象 | 作用域 | 说明 |
|---|---|---|
| Role（角色） | Namespace级别 | 仅对所属Namespace生效，不同Namespace的同名Role互不干扰 |
| ClusterRole（集群角色） | 集群级别 | 对整个集群所有Namespace生效，所有Namespace共享同一份配置 |
| RoleBinding（角色绑定） | Namespace级别 | 将用户/用户组/ServiceAccount绑定到Role，仅对绑定所在的Namespace生效 |
| ClusterRoleBinding（集群角色绑定） | 集群级别 | 将用户/用户组/ServiceAccount绑定到ClusterRole，对整个集群生效，无需指定Namespace |
- 类比理解：Role类比班级管理员，仅能管理所在班级；ClusterRole类比校长，可管理所有班级；RoleBinding是将用户指定为某个班级的管理员，ClusterRoleBinding是将用户指定为全校的管理员。
4. RBAC绑定组合与权限逻辑
RBAC的权限绑定遵循「权限 → 角色 → 绑定 → 主体」的逻辑，权限与角色为多对多关系（一个角色可绑定多个权限，一个权限可绑定到多个角色），支持3种绑定组合：
- Role + RoleBinding：Namespace内的标准绑定，仅当前Namespace生效，适合单命名空间的权限配置。
- ClusterRole + ClusterRoleBinding：集群级标准绑定，所有Namespace均生效，适合集群全局权限配置（如集群管理员权限）。
- ClusterRole + RoleBinding（降维绑定）：特殊绑定方式，将集群角色绑定到指定Namespace，仅该Namespace内生效，避免权限溢出。
- 示例：若需要为4个Namespace分别配置管理员，传统方式需要每个Namespace创建独立的Role+RoleBinding，共需创建12个资源对象；若使用降维绑定，仅需创建1个ClusterRole（集群管理员角色）+ 4个RoleBinding，共9个资源对象，Namespace越多资源开销越小，且管理更简便。
5. 权限主体与ServiceAccount（SA）创建
- RBAC的权限可绑定到3类主体：用户（User）、用户组（Group）、ServiceAccount（SA）。
- ServiceAccount是Kubernetes中Pod用于访问API Server的身份凭证，创建方式有两种：
- 命令行创建：
kubectl create serviceaccount <SA名称> -n <Namespace> - 资源清单创建：可通过
kubectl create serviceaccount <SA名称> -n <Namespace> --dry-run=client -o yaml导出YAML模板，修改后直接应用。
- 命令行创建：
AI 总结
本节为Kubernetes集群安全鉴权模块的核心内容，首先明确了鉴权是认证后验证操作权限的关键环节，随后介绍了Kubernetes支持的4类鉴权模式，重点讲解当前默认的RBAC鉴权机制：包括其全API化、运行时生效、权限覆盖全面的核心优势，4个顶级资源对象的作用域差异，以及3种绑定组合的逻辑，最后通过实例对比了降维绑定的资源优势，为后续RBAC的实操配置打下基础。