第九章 k8s集群安全机制 - 准入控制（Admission Control）笔记
前置背景
在讲解完认证（Authentication）、授权（Authorization，视频中称「健全」）后引入准入控制：即使请求主体通过认证、拥有操作权限，其行为也不一定合理，准入控制承担集群内「行为合理性监督」的职责，类比现实中的巡查组，监督权限使用是否合规。
准入控制核心定义
是Kubernetes API Server的插件集合，通过配置不同插件可实现额外的准入规则，甚至API Server的部分核心功能也由准入控制插件实现。
视频给出的核心定义：合法但无理的控制行为，即拦截「有权限但不合理」的操作请求。
补充功能：除监督拦截外，还可实现集群额外功能，如自动创建资源等。
官方推荐准入控制插件及功能
视频中提到官方给出的推荐准入控制列表版本较老旧，但应用官方推荐配置的合理性较高，无需刻意记忆具体列表。
官方推荐的插件主要分为两类能力：
额外功能添加类
- 防止在不存在Namespace内创建资源对象，起到请求校验的确认作用
- 创建Namespace时，自动在Namespace下创建默认的default ServiceAccount，该功能由ServiceAccount准入插件实现
- 删除Namespace时，自动连带删除该Namespace下的所有资源对象
不合理行为拦截类（有权限但不合理）
- 防止删除系统预置核心Namespace（如default、kube-system等），避免误删/恶意删除集群基础命名空间
- 拦截超过所在Namespace ResourceQuota（资源配额）限制的资源请求：即使管理员拥有跨Namespace调用资源的权限，若请求量超过Namespace预设的资源上限，也会被拦截
- 类比案例：老版本Linux完全信任管理员权限，执行
rm -rf /会删除到系统调用库为止，极易造成系统损毁；新版Linux对该类操作做了权限拦截，因为该行为要么是恶意破坏、要么是误操作，属于「有权限但不合理」，和准入控制的拦截逻辑一致。
3A安全体系全流程梳理
K8s集群安全由3个核心环节串联，请求需全部通过才会被放行：
1. 认证（Authentication）：确认请求方身份
- 核心作用：判断请求主体（用户、ServiceAccount、集群组件等）是否是合法主体
- 两类主体的认证方案：
- 集群组件间通信：大多采用HTTPS双向认证；Control Manager、Scheduler与API Server部署在同一台机器时，可通过非安全端口、回环接口（127.0.0.1）访问，无需双向认证
- Pod：因Pod动态性强，为每个Pod分配证书成本极高，因此引入ServiceAccount（SA）资源对象实现Pod的身份认证与双向认证
2. 授权（Authorization，视频中称「鉴权」）：确认权限合法性
- 核心作用：确认通过认证的请求主体，是否拥有当前操作行为的对应权限
- 当前主流采用RBAC（基于角色的访问控制）模型
- 核心关联资源对象：Role（角色）、ClusterRole（集群角色）、RoleBinding（角色绑定）、ClusterRoleBinding（集群角色绑定）
3. 准入控制（Admission Control）：确认行为合理性
- 核心作用：确认通过认证、拥有权限的请求，其行为是否符合集群规则
- 两类核心能力：
- 实现集群额外功能（如自动创建default ServiceAccount）
- 拦截「有权限但不合理」的行为（如删除系统Namespace、超过资源配额、恶意/误操作等）
本章知识点总结
本章围绕K8s集群安全机制，系统讲解了3A安全体系的核心逻辑：先通过认证确认「你是谁」，再通过授权确认「你能做什么」，最后通过准入控制确认「你做的是否合理」，三者共同保障集群操作的安全性。
AI 总结
准入控制是K8s集群安全3A体系的最后一道防线，核心作用是拦截「已通过认证、拥有权限但不合理」的操作请求，同时支持通过插件扩展集群额外功能。它既可以通过拦截删除系统Namespace、超过资源配额等不合理行为避免集群故障，也能实现自动创建ServiceAccount等便捷能力，是保障集群安全与合规的核心机制。