目录
一、核心安全机制详解
1.1 身份认证（Authentication）；授权（Authorization）；准入控制（Admission Controllers）
1.1.1，身份认证（Authentication）
核心概念
1.2，授权（Authorization）
1.2.1主流授权模式
. RBAC（Role-Based Access Control）
. 其他授权模式（不推荐生产使用）
1.3，准入控制（Admission Controllers）
1.3.1. 内置准入控制器（Built-in Admission Controllers）
二，支持的认证方式
2.1，Kubernetes 核心组件与 API Server 的通信认证机制
2.2. 控制平面组件的特殊通信细节
2.3. kubeconfig 配置文件的作用
三、角色（Role/clusterRole）
3.1、核心定位与区别
Role（命名空间角色）
ClusterRole（集群角色）
3.2 ，角色绑定
3.2.1、核心定位与区别
RoleBinding（命名空间级绑定）
ClusterRoleBinding（集群级绑定）
3.2.2、角色绑定的核心结构
关键字段详解
（1）subjects：被授权的主体
（2）roleRef：要绑定的角色
3.3，主体（subject）
3.4，Resource
3.4.1、Resource 的核心分类
1. 命名空间级资源（Namespaced Resource）
2. 集群级资源（Cluster-scoped Resource）
一、核心安全机制详解
1.1 身份认证（Authentication）；授权（Authorization）；准入控制（Admission Controllers）
1.1.1，身份认证（Authentication）
Kubernetes 身份认证（Authentication）是API Server 处理请求的第一道安全关卡，其核心目标是验证发起请求的用户 / 组件的真实身份，只有通过认证的请求才会进入后续的授权（Authorization）流程。K8s 不存储用户信息，而是通过凭证校验的方式完成身份识别，支持多种认证方式，可同时启用多种（只要有一种校验通过即可）。
核心概念
- 认证主体K8s 中的认证主体分为两类，对应不同的访问场景：
- 用户账户（User Account）：面向集群外部用户（如管理员、开发人员），是全局对象，不通过 K8s API 管理（需外部系统维护，如证书、LDAP）。
- 服务账户（Service Account）：面向集群内 Pod 中的应用程序，是命名空间级别的资源，由 K8s 自动或手动创建，用于 Pod 访问 API Server。
- 认证流程请求到达 API Server 后，认证模块会依次检查请求携带的凭证（如证书、令牌），匹配已配置的认证方式：
plaintext
客户端发起请求 → API Server 接收请求 → 认证模块校验凭证 → 认证通过 → 进入授权流程 ↓ 认证失败 → 拒绝请求（返回 401 Unauthorized）
1.2，授权（Authorization）
在 Kubernetes 中，授权（Authorization）是 API Server 处理请求的第二道安全关卡：它在身份认证（Authentication）通过后，决定 “已认证的用户 / 组件能对集群资源执行哪些操作”，核心是实现权限的精细化管控，遵循「最小权限原则」。
1.2.1主流授权模式
Kubernetes 支持多种授权模式，。其中RBAC（基于角色的访问控制）是 K8s 1.8+ 推荐的默认模式，也是生产环境的唯一选择。
. RBAC（Role-Based Access Control）
| 资源类型 | 作用 | 作用范围 |
|---|---|---|
Role | 定义命名空间内的权限规则（如 “允许在default命名空间查看 Pod”） | 单个命名空间 |
ClusterRole | 定义集群级的权限规则（如 “允许查看所有节点信息”） | 整个集群 |
RoleBinding | 将Role绑定到用户 / SA / 组，使主体获得该角色的权限 | 单个命名空间 |
ClusterRoleBinding | 将ClusterRole绑定到用户 / SA / 组，使主体获得集群级权限 | 整个集群 |
. 其他授权模式（不推荐生产使用）
- Node 模式：专为
kubelet设计，仅允许 kubelet 访问节点相关资源（如上报节点状态、管理 Pod）。 - ABAC（Attribute-Based Access Control）：通过配置文件定义基于用户、资源属性的权限规则，灵活性高但维护复杂，已被 RBAC 替代。
- Webhook 模式：将授权请求转发到外部服务（如企业权限系统），适合复杂的权限场景，但依赖外部服务可用性。
1.3，准入控制（Admission Controllers）
准入控制是 Kubernetes API Server 处理请求的第三道安全关卡，作用于「授权通过后、资源持久化到 etcd 前」，可以对资源请求进行验证、修改甚至拒绝，是集群安全策略、合规规则的核心落地环节。
1.3.1. 内置准入控制器（Built-in Admission Controllers）
K8s 内置了数十种准入控制器，默认启用部分核心控制器，无需额外开发即可满足大部分场景需求。
二，支持的认证方式
2.1，Kubernetes 核心组件与 API Server 的通信认证机制
- 统一协议：所有控制平面组件（Controller Manager、Scheduler）和节点组件（kubelet、kube-proxy），以及客户端工具（kubectl）与 API Server 通信时，均采用HTTPS + X.509 证书认证，确保通信加密与身份可信。
- 默认端口：API Server 的安全通信端口为
6443（HTTPS），这是生产环境中唯一应暴露的 API 端口。
2.2.控制平面组件的特殊通信细节
- 内部端口 8080： Scheduler、Controller Manager 使用内部端口
8080，这是 API Server 的非安全端口（HTTP 协议，无认证）。- 该端口仅用于组件本地或集群内部的临时通信，生产环境必须禁用（通过 API Server 启动参数
--insecure-port=0关闭），避免未授权访问风险。
- 该端口仅用于组件本地或集群内部的临时通信，生产环境必须禁用（通过 API Server 启动参数
- 组件身份凭证：Controller Manager、Scheduler 等组件通过集群根 CA 签发的客户端证书完成认证，其配置通常内嵌在组件的启动参数中，或通过 kubeconfig 文件管理。
2.3.kubeconfig 配置文件的作用
kubeconfig是 Kubernetes 中用于管理客户端凭证与集群访问配置的核心文件，主要作用包括：- 定义集群信息：指定 API Server 的地址、CA 证书（用于验证 API Server 身份）。
- 管理用户凭证：存储客户端证书、Service Account 令牌等认证信息。
- 关联上下文：将 “集群” 与 “用户” 绑定，快速切换不同集群的访问身份。
三、角色（Role/clusterRole）
3.1、核心定位与区别
两者的本质都是 “权限规则集合”，核心差异集中在作用范围上：
Role（命名空间角色）
Role 仅对单个命名空间内的资源生效，只能用来管控该命名空间内的资源操作权限。它的适用场景是命名空间级资源的权限分配，比如对default命名空间内的 Pod、Deployment 进行查看或编辑操作，都可以通过定义 Role 来实现权限约束。Role 本身属于命名空间级资源，定义时必须指定所属的namespace。
ClusterRole（集群角色）
ClusterRole 对整个集群的资源生效，既可以管控集群级资源（如 Node、Namespace）的操作权限，也可以通过RoleBinding绑定到单个命名空间，实现对特定命名空间内资源的权限管控。它的适用场景包括两类：一是集群级资源的权限分配，比如查看所有节点信息、管理命名空间；二是跨命名空间的资源权限分配，比如访问集群内所有命名空间的 Secrets 资源。ClusterRole 属于集群级资源，定义时不需要指定namespace。
3.2 ，角色绑定
3.2.1、核心定位与区别
角色绑定的核心是「关联角色与主体」，两者的差异同样体现在作用范围上，与Role/ClusterRole一一对应：
RoleBinding（命名空间级绑定）
RoleBinding 仅在单个命名空间内生效，只能绑定两类角色：
- 同一命名空间内的
Role； - 集群级的
ClusterRole（绑定后，ClusterRole的权限仅在该命名空间内有效）。它的适用场景是命名空间内的权限分配，比如给default命名空间的服务账户分配查看 Pod 的权限。
ClusterRoleBinding（集群级绑定）
ClusterRoleBinding 在整个集群范围内生效，只能绑定ClusterRole，无法绑定Role。它的适用场景是集群级权限分配，比如给集群管理员分配管理所有节点的权限，或给跨命名空间的组件分配访问多命名空间资源的权限。
3.2.2、角色绑定的核心结构
无论是RoleBinding还是ClusterRoleBinding，都包含两个核心字段：
subjects：定义被授予权限的主体，支持三类对象；roleRef：定义要绑定的角色，必须指定角色的类型和名称。
关键字段详解
（1）subjects：被授权的主体
支持三种主体类型，覆盖集群内外部所有访问者：
User：外部用户，通常由证书、OIDC 等认证方式定义，名称为用户标识（如alice）；Group：用户组，用于批量授权，常见的内置组如system:masters（超级管理员组）；ServiceAccount：集群内 Pod 组件使用的服务账户，是最常用的主体类型。
（2）roleRef：要绑定的角色
必须明确指定角色的kind（类型）和name（名称），且roleRef不允许修改（若需更换角色，需删除重建绑定）。
3.3，主体（subject）
在 Kubernetes RBAC 授权体系里，Subject（主体）是被授予权限的对象，是角色绑定（RoleBinding/ClusterRoleBinding）的核心组成部分。简单来说，角色（Role/ClusterRole）定义了 “能做什么”，而主体定义了 “谁能做这些事”。
主体的配置全部在角色绑定的subjects字段中，一个绑定可以同时包含多个主体，实现批量授权。
3.4，Resource
在 Kubernetes RBAC 授权体系的rules规则中，resource（资源）是核心字段之一，用于明确权限作用的目标 Kubernetes 资源类型，和apiGroups（资源所属 API 组）、verbs（允许的操作）共同构成一条完整的权限规则。
简单来说：apiGroups确定资源的 “分类”，resource确定具体的 “资源名称”，verbs确定对该资源能执行的 “操作动作”。
3.4.1、Resource 的核心分类
Kubernetes 中的资源按作用范围可分为两类，对应Role和ClusterRole的使用场景：
1. 命名空间级资源（Namespaced Resource）
这类资源属于某个具体的命名空间，只能在Role（命名空间级角色）中定义，或通过RoleBinding绑定ClusterRole后限定在单个命名空间内生效。常见的命名空间级资源包括：
- 核心 API 组：
pods、services、configmaps、secrets、persistentvolumeclaims - apps API 组：
deployments、statefulsets、daemonsets、replicasets - batch API 组：
jobs、cronjobs
2. 集群级资源（Cluster-scoped Resource）
这类资源不属于任何命名空间，作用于整个集群，只能在ClusterRole中定义，无法在Role中使用。常见的集群级资源包括：
- 核心 API 组：
nodes、namespaces、persistentvolumes - storage.k8s.io API 组：
storageclasses、csidrivers - rbac.authorization.k8s.io API 组：
roles、clusterroles、rolebindings
