1. CNI准入策略概述
1.1 什么是CNI准入策略
CNI（Container Network Interface）准入策略是Kubernetes集群中一组用于控制Pod网络资源创建与修改的准入控制机制。它在Pod被持久化到etcd之前，拦截并验证网络相关的配置请求，确保只有符合预定义网络规则的Pod才能被调度和运行。
从技术实现角度看，CNI准入策略通常以ValidatingAdmissionPolicy、MutatingAdmissionWebhook或ValidatingAdmissionWebhook的形式部署在API Server的准入链中。这些策略检查Pod规约中的网络字段，包括但不限于：
- Pod网络命名空间：检查Pod是否被分配到允许的网络命名空间
- CNI插件选择：验证Pod使用的CNI插件是否在白名单内
- 网络策略绑定：确保Pod关联了必要的NetworkPolicy资源
- IP地址分配：检查Pod是否请求了允许范围内的IP地址
- 端口映射规则：验证容器端口映射是否符合安全基线
关键概念：CNI准入策略不是CNI插件本身，而是运行在API Server准入链中的策略引擎。它工作在CNI插件执行之前，属于“事前控制”而非“事后审计”。
1.2 为什么需要CNI准入策略
在Kubernetes多租户环境和生产级集群中，缺乏CNI准入策略会带来以下严重风险：
| 风险类别 | 具体问题 | 潜在后果 |
|---|---|---|
| 网络隔离失效 | Pod可以绕过NetworkPolicy约束 | 租户间数据泄露、横向移动攻击 |
| 资源滥用 | Pod请求大量IP地址或带宽 | IP池耗尽、网络性能下降 |
| 配置错误 | CNI参数配置错误导致Pod启动失败 | 服务中断、故障扩散 |
| 安全合规缺失 | 未绑定安全策略的Pod运行敏感负载 | 违反PCI-DSS、SOC2等合规要求 |
| 恶意Pod注入 | 攻击者创建特权网络Pod | 集群网络被劫持、数据窃取 |
CNI准入策略的核心价值体现在三个维度：
- 安全加固：强制实施最小网络权限原则，阻止未授权的网络访问
- 运维管控：统一网络配置基线，减少人为配置错误
- 合规审计：提供可追溯的网络策略变更记录，满足合规要求
实践建议：在集群初始化阶段就部署CNI准入策略，比事后补救成本低10倍以上。建议将策略定义纳入GitOps工作流，通过代码审查确保策略变更的合规性。
1.3 CNI准入策略在Kubernetes安全模型中的位置
Kubernetes安全模型采用纵深防御架构，CNI准入策略位于准入控制层，是网络安全的第一道防线。以下SVG图展示了CNI准入策略在整个安全模型中的位置：
从安全模型分层可以看出，CNI准入策略处于关键拦截位置：
- 认证与授权之后：确保请求来源合法、操作权限合规
- etcd持久化之前：阻止不合规的网络配置写入存储层
- CNI插件执行之前：避免无效或恶意的网络配置到达运行时环境
与Kubernetes其他安全机制相比，CNI准入策略具有独特的定位：
| 安全机制 | 作用层 | 控制粒度 | 与CNI准入策略的关系 |
|---|---|---|---|
| RBAC | API访问控制 | 用户/服务账户级别 | 前置条件，决定谁可以发起请求 |
| NetworkPolicy | 运行时网络隔离 | Pod间流量控制 | CNI准入策略确保NetworkPolicy被正确绑定 |
| PodSecurityPolicy (已弃用) | Pod安全上下文 | Pod级别安全约束 | 与CNI准入策略互补，覆盖不同维度 |
| OPA/Gatekeeper | 通用准入策略 | 任意资源约束 | 可承载CNI准入策略，但需自定义规则 |
| CNI准入策略 | 网络准入控制 | Pod网络配置级别 | 专注网络维度，提供专用语义和性能优化 |
常见误区：不要将CNI准入策略与NetworkPolicy混淆。NetworkPolicy控制Pod之间的运行时流量，而CNI准入策略控制Pod的创建时网络配置。两者是互补关系，而非替代关系。一个完整的网络安全方案需要同时部署两者。
以下SVG图进一步展示CNI准入策略在Pod创建流程中的具体拦截点：
从流程图中可以清晰看到，CNI准入策略在Pod创建流程中扮演“守门员”角色。一旦策略拒绝，Pod创建请求立即返回错误，不会进入后续的调度和CNI插件执行阶段。这种提前阻断机制有效降低了集群网络层面的攻击面，减少了无效资源消耗。