1. Knative 云原生安全基线概述
1.1 什么是云原生安全基线
云原生安全基线是一组最低安全配置要求与最佳实践的集合，旨在为云原生环境（容器、微服务、Serverless）提供可重复、可审计的安全起点。它不是一次性的安全加固，而是贯穿应用构建、部署、运行全生命周期的安全策略框架。
核心特征：
- 可量化：每个控制项都有明确的检查标准（如“必须启用只读根文件系统”）
- 可自动化：通过准入控制器、策略引擎（如 OPA/Gatekeeper）自动执行
- 可审计：所有安全决策与违规行为均记录到审计日志中
- 可演进：基线随威胁模型与业务需求持续更新
在 Knative 场景下，安全基线需要覆盖以下关键领域：
| 安全领域 | 基线要求 | Knative 特有考量 |
|---|---|---|
| 镜像安全 | 使用签名镜像、禁止 latest 标签 | 冷启动时镜像拉取速度与安全扫描的平衡 |
| 运行时安全 | 容器以非 root 运行、只读根文件系统 | Serverless 函数无状态特性天然适配只读文件系统 |
| 网络策略 | 最小化网络暴露、禁止外部直接访问 Pod | Knative 通过 Istio/Kourier 网关统一入口 |
| 资源隔离 | 设置 CPU/内存 limits 与 requests | 冷启动削峰需要动态调整资源配额 |
| 审计日志 | 记录所有 API 变更与安全事件 | Knative 自动扩缩容事件需纳入审计范围 |
1.2 Knative 安全挑战
Knative 作为 Kubernetes 之上的 Serverless 平台，在带来弹性伸缩与按需计费优势的同时，也引入了独特的安全攻击面：
- 冷启动攻击窗口：从 0 副本扩展到 1 副本的过程中，Pod 创建、镜像拉取、网络配置等操作存在短暂的安全盲区，攻击者可利用此窗口注入恶意配置
- 多租户隔离风险：不同函数共享同一集群，Pod 间缺乏强隔离，恶意函数可能通过 Sidecar 或共享卷窃取数据
- 自动扩缩容滥用：攻击者可通过大量请求触发频繁扩缩容，导致资源耗尽（Scale-to-zero DoS）
- 配置漂移：Knative 的自动配置（如 Revision 自动创建）可能绕过原有安全策略
- 审计日志缺失：默认配置下 Knative 控制面事件未被完整记录，安全调查缺乏依据
关键风险：Knative 的自动扩缩容机制（KPA / HPA）在冷启动阶段会临时提升资源权限，若未配合准入策略，攻击者可能利用此间隙创建特权容器。
1.3 冷启动削峰与准入策略的关系
冷启动削峰与准入策略是 Knative 安全基线中两个紧密耦合的机制，它们共同解决“如何在保证安全的前提下实现 Serverless 的弹性伸缩”这一核心问题。
核心关系：准入策略是冷启动削峰的“安全门禁”，冷启动削峰是准入策略的“性能放大器”。没有准入策略的削峰是危险的，没有削峰的准入策略是低效的。
1.3.1 冷启动削峰的安全需求
冷启动削峰通过预创建 Pod、缓存镜像层、预热网络策略等手段，将冷启动延迟从秒级降低到毫秒级。但削峰操作本身会引入安全风险：
- 预创建 Pod 可能绕过准入检查：如果削峰组件直接调用 Kubernetes API 创建 Pod，可能跳过 Webhook 准入控制器
- 镜像缓存可能携带漏洞：缓存的旧版本镜像可能包含已知 CVE，削峰机制需要与镜像扫描联动
- 网络策略预热可能过度开放：为加速冷启动而提前配置的网络规则可能违反最小权限原则
1.3.2 准入策略对削峰的约束
准入策略（Admission Policy）在 Knative 中通过 ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 实现，对削峰操作施加以下约束：
| 削峰阶段 | 准入策略检查项 | 安全目标 |
|---|---|---|
| 预创建 Pod | 验证 Pod 安全上下文（SecurityContext） | 禁止特权容器、禁止 root 用户 |
| 镜像缓存 | 检查镜像签名与漏洞扫描结果 | 仅缓存通过安全审计的镜像 |
| 网络预热 | 验证 NetworkPolicy 是否遵循最小权限 | 防止过度开放网络端口 |
| 资源分配 | 检查资源 limits 是否在租户配额内 | 防止资源滥用导致 DoS |
| Revision 创建 | 验证 Configuration 变更是否合规 | 防止配置漂移 |
1.3.3 协同工作流程
冷启动削峰与准入策略的协同流程可以概括为以下步骤：
- 请求到达：用户请求触发 Knative Service 从 0 副本扩缩
- 削峰引擎启动：削峰组件（如 Activator + Autoscaler）准备预创建 Pod
- 准入检查：削峰组件通过准入 Webhook 提交 Pod 创建请求，触发安全策略验证
- 策略决策：
- 通过：继续执行削峰操作，创建 Pod 并配置网络
- 拒绝：记录审计日志，回退到标准冷启动流程（可能增加延迟）
- 审计记录：所有准入决策与削峰操作均写入审计日志
- 请求路由：Pod 就绪后，请求被路由到新创建的实例
1.4 三者关系总结
云原生安全基线、冷启动削峰、准入策略三者构成 Knative 安全体系的“铁三角”：
| 要素 | 角色 | 与安全基线的关联 |
|---|---|---|
| 云原生安全基线 | 安全策略的定义层 | 提供可量化的安全标准与检查项 |
| 冷启动削峰 | 性能优化的执行层 | 在安全基线约束下加速 Pod 创建 |
| 准入策略 | 安全控制的决策层 | 确保削峰操作不违反安全基线 |
实践要点：
- 安全基线应作为 Knative 集群的“宪法”，所有削峰与准入策略必须遵循
- 削峰组件必须通过准入 Webhook 提交请求，不能绕过安全控制
- 审计日志需要同时记录削峰操作与准入决策，形成完整证据链
- 定期审计削峰日志，发现异常模式（如频繁准入拒绝）及时调整策略