Kubernetes 安全机制

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 内置了数十种准入控制器，默认启用部分核心控制器，无需额外开发即可满足大部分场景需求。

二，支持的认证方式

HTTP Token 认证：在 HTTP Header 携带一个难以仿冒的长 Token ； API Server 维护 Token 与
用户名的映射。
HTTP Basic 认证：用户名 : 密码使用 Base64 编码后放入 Header 的 Authorization 字段。
HTTPS 证书认证（最严格） ：基于 CA 根证书签名的双向 TLS 认证。

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 关闭），避免未授权访问风险。
组件身份凭证：Controller Manager、Scheduler 等组件通过集群根 CA 签发的客户端证书完成认证，其配置通常内嵌在组件的启动参数中，或通过 kubeconfig 文件管理。

2.3. kubeconfig 配置文件的作用

kubeconfig 是 Kubernetes 中用于管理客户端凭证与集群访问配置 的核心文件，主要作用包括：
1. 定义集群信息：指定 API Server 的地址、CA 证书（用于验证 API Server 身份）。
2. 管理用户凭证：存储客户端证书、Service Account 令牌等认证信息。
3. 关联上下文：将 "集群" 与 "用户" 绑定，快速切换不同集群的访问身份。

三、角色（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