第九章.k8s集群安全机制-鉴权-2

来源链接：https://www.bilibili.com/video/BV1PbeueyE8V?spm_id_from=333.788.videopod.episodes&vd_source=d8c71ff24a3359a807967fc4b5daa0e4&p=67

第九章 k8s集群安全机制-鉴权2 核心知识点笔记

1. Kubernetes 用户与组的创建原理

Kubernetes 不存在 create user/create group 类命令，无法直接创建用户或组，其用户与组的身份来源为客户端证书，逻辑类似“保安认牌不认人”：API Server 只认可集群信任的 CA 签发的证书，通过证书内容识别身份，无需在 etcd 中存储用户/组信息。

• 证书身份映射规则：证书签发时可将 CN 字段设置为用户名，O 字段设置为用户组，API Server 会直接读取这两个字段作为身份标识。
• 证书可用范围控制：可通过 hosts 字段配置客户端 IP 白名单，未配置则允许所有 IP 使用该证书，绑定 IP 可进一步提升安全性。
• 证书生成方式：
  1. 使用 openssl 工具手动生成，配置项较多操作繁琐；
  2. 使用 coreos 开源的 cfssl 工具，通过 JSON 模板配置签发规则，可快速生成被集群 CA 信任的证书。
• ServiceAccount（SA）的创建：SA 是 Kubernetes 内置的 Namespace 级别服务账号，可直接通过 kubectl create serviceaccount <sa名称> -n <命名空间> 命令创建，系统会自动生成存储证书令牌的 Secret，供 Pod 内进程身份认证使用。

2. RBAC 核心概念

RBAC（Role-Based Access Control）是基于角色的访问控制，核心逻辑为权限仅累加：主体创建后初始权限为0，不存在默认权限，仅能通过绑定角色赋予权限，不支持通过绑定减少权限。

2.1 Role（角色）

Role 是 Namespace 级别的权限集合，仅能对所属 Namespace 内的资源进行授权。

• 资源清单核心字段：
  • kind: Role
  • apiVersion: rbac.authorization.k8s.io/v1
  • metadata.namespace: 必须指定所属 Namespace，不填默认是 default
  • metadata.name: 角色名称
  • rules: 权限规则列表，每条规则包含三个核心字段：
    • apiGroups: 资源所属的 API 组，核心组（v1 版本）可留空，代表默认核心组
    • resources: 资源名称，需写复数形式（如 pods 而非 pod），支持子资源配置（如 pods/log）
    • verbs: 允许执行的动作，如 get、list、watch、create、delete 等

2.2 ClusterRole（集群角色）

ClusterRole 是集群级别的权限集合，作用域为整个集群，除支持 Role 的所有权限外，还支持三类特殊权限：

1. 集群级资源的控制（如 node、persistentVolume 等不属于任何 Namespace 的资源）；
2. 非资源类型接口的访问（如 /healthz 健康检查接口、/metrics 监控接口等）；
3. 所有 Namespace 下的资源控制。

• 资源清单与 Role 基本一致，仅需将 kind 改为 ClusterRole，无需指定 metadata.namespace 字段。

2.3 角色绑定（RoleBinding & ClusterRoleBinding）

角色绑定用于将角色的权限授予指定的主体（用户、组、SA），分为两类：

2.3.1 RoleBinding（角色绑定）

• 作用域：Namespace 级别，仅能对所属 Namespace 内的主体授权。
• 可绑定的角色来源：Role 或 ClusterRole，若绑定 ClusterRole，其权限会被限制在当前 Namespace 内，不会外溢到其他 Namespace，符合最小权限原则。
• 资源清单核心字段：
  • kind: RoleBinding
  • metadata.namespace: 必须指定所属 Namespace
  • subjects: 被授权的对象列表，每项包含 kind（User/Group/ServiceAccount）、name（主体名称）、apiGroup（固定为 rbac.authorization.k8s.io）
  • roleRef: 绑定的角色引用，包含 apiGroup、kind（Role/ClusterRole）、name（角色名称）

2.3.2 ClusterRoleBinding（集群角色绑定）

• 作用域：集群级别，可将 ClusterRole 的权限授予集群范围内的主体，权限作用于整个集群所有 Namespace。
• 资源清单与 RoleBinding 基本一致，仅需将 kind 改为 ClusterRoleBinding，无需指定 metadata.namespace 字段。

3. 关键补充字段说明

3.1 子资源（Subresource）

Kubernetes 资源存在子资源概念，用于对资源的特定子项进行授权，格式为 资源名/子资源名，例如 Pod 的子资源包括 log（日志）、exec（进入容器执行命令）、event（事件）等。

• 权限逻辑：子资源对应唯一的 API 访问路径，例如访问 Pod 日志的请求路径为 /api/v1/namespaces/{ns}/pods/{pod名}/log，仅当主体被授予对应子资源的访问权限时，才能发起该路径的请求。
• 示例：若仅允许用户查看 Pod 日志，可配置 resources: ["pods/log"]，无法操作 Pod 其他资源。

3.2 Subject（权限附着点）

Subject 是权限的授予对象，支持三类主体：

1. User（用户）：字符串格式，支持普通名称（如 zhangsan）、邮箱格式（如 wangyang@163.com）、数字 ID 格式，注意 system: 前缀为 Kubernetes 系统保留，普通用户禁止使用。
2. Group（组）：字符串格式，无特定格式要求，同样禁止使用 system: 前缀。
3. ServiceAccount（SA）：Kubernetes 内置的服务账号，用于 Pod 内进程的身份认证。

4. 实操案例：创建仅能操作 dev Namespace 的用户

实际场景中常需要实现资源隔离，避免不同项目组的权限交叉，实现步骤如下：
1. 生成客户端证书：配置证书的 CN 为目标用户名、O 为用户组，使用集群信任的 CA 签发证书，作为用户身份凭证。
2. 转换 kubeconfig 文件：将签发的证书转换为 kubeconfig 格式文件，用户可通过该文件使用 kubectl 连接集群并完成认证。
3. 创建目标 Namespace：手动创建 dev Namespace，作为用户可操作的唯一范围。
4. 配置权限绑定：在 dev Namespace 下创建需要的 Role，再通过 RoleBinding 将角色权限绑定到目标用户，限制用户仅能在 dev Namespace 内执行授权操作。

AI 总结

本视频核心讲解了 Kubernetes RBAC 鉴权机制的核心逻辑与实操方法：首先明确了 Kubernetes 用户/组、SA 的身份创建规则，其中用户/组通过集群 CA 签发的客户端证书实现身份标识，无需直接创建；其次详细拆解了 Role、ClusterRole、RoleBinding、ClusterRoleBinding 四大核心资源的定义规则、作用域与适用场景，补充了子资源、Subject 等关键字段的含义；最终通过 Namespace 权限隔离的实操案例，演示了如何实现最小权限的集群访问控制，避免权限越界导致的集群风险。