01 · 研究背景与意义
1.1 从虚拟化到云原生：安全边界的一次结构性重构
容器不是"轻量虚拟机"，而是与宿主机共享内核的进程隔离技术——这一技术本质决定了容器安全的全部研究议程。2013年Docker开源发布，以镜像与容器重塑应用交付；2014年Google开源Kubernetes（源自其内部Borg/Omega系统十余年生产经验）；2015年12月云原生计算基金会（CNCF）成立，容器编排之争在数年内迅速收敛于Kubernetes。与虚拟机"每实例独立内核"的强隔离模型不同，容器依赖Linux命名空间（namespace）、控制组（cgroups）、 capabilities、seccomp与LSM（AppArmor/SELinux）等内核机制实现进程级隔离：隔离强度显著弱于虚拟机，攻击面却从"操作系统补丁管理"扩展到"编排控制面、声明式配置、镜像供应链、东西向服务流量"四个全新维度。NIST SP 800-190《Application Container Security Guide》（2017年5月）首次在国家层面系统定义了容器技术栈各层（镜像、注册表、编排器、容器、宿主机OS）的安全关切，是容器安全研究的基础文献。
1.2 安全模型的三重失效
- 边界失效：Pod网络默认全通（any-to-any），服务间通信不再经过传统防火墙与DMZ分区；IP不再稳定（Pod重建即换IP），以IP为核心的黑白名单策略无法表达。
- 身份失效：工作负载的"身份"从主机+IP迁移到ServiceAccount与Pod标签，但大量组织仍沿用人工管理的静态凭证，凭证泄露与过度授权成为横向移动的主要通道。
- 可见性失效：容器生命周期以秒计、密度百倍于虚拟机，进程级的短时行为使基于主机的代理式检测与人工日志审计全面失灵，必须依赖内核级（eBPF）或编排事件级的自动化遥测。
1.3 三个结构性挑战
| 挑战 | 内涵 | 本课题应对（对应页） |
|---|---|---|
| 默认开放与配置漂移 | 集群默认配置以"可跑通"为第一目标：匿名访问历史遗留、RBAC过宽、网络默认放行、敏感组件直接暴露；配置项数以万计且随版本快速演进 | 第2、3、8页：攻击面解析、基线核查与合规 |
| 共享内核的逃逸风险 | 容器与宿主机共享内核，运行时漏洞（runc/CRI-O）、危险挂载与特权配置均可导致逃逸；内核漏洞的容器场景利用面远大于虚拟机场景 | 第4页：Pod安全标准与运行时防护 |
| 供应链成为主攻击面 | 镜像、Helm Chart、插件（CSI/CNI/Operator）与CI/CD流水线构成复杂供应关系，投毒与漏洞沿"构建→分发→运行"链路规模化扩散 | 第6页：供应链与镜像安全 |
认知纠偏："容器比虚拟机更轻、启动更快，所以把原来的应用直接跑进去就天然更安全"——这是容器 adoption 早期最危险的认识误区。NIST SP 800-190与NSA/CISA《Kubernetes Hardening Guidance》均明确指出：容器降低了"运行不可信代码"的门槛，恰恰放大了攻击频次；容器环境的默认配置从来不为生产安全而设；容器不是安全边界，编排平台本身才是需要被重点防护的核心资产。安全收益只能来自显式的架构设计与基线工程，而非迁移行为本身。
02 · 研究目标与关键问题
- 攻击面完备性目标：建立覆盖控制面、节点、网络、运行时与供应链五层的Kubernetes攻击面清单，做到"每个默认端口、每个默认权限、每个历史高危面"均有档案（第2页）。
- 最小权限工程化目标：将RBAC、ServiceAccount、准入控制、Pod安全上下文的最小权限原则转化为可执行的策略模板与核查规则，而非停留在原则表述（第3—4页）。
- 运行时可视性目标：建立容器逃逸、凭证窃取、横向移动等关键攻击行为的内核级检测能力，并量化检测覆盖度与MTTD（第4、7页）。
- 治理闭环目标：将上述能力固化为基线（CIS/NSA-CISA）、度量指标与成熟度模型，形成可持续运营而非一次性加固（第8页）。
2.1 三个关键研究问题（KQ）
| 编号 | 关键问题 | 内涵说明 | 对应章节 |
|---|---|---|---|
| KQ-1 | 默认配置的暴露程度 | 主流发行版（kubeadm及各大托管K8s）出厂配置中，哪些组件、端口与权限构成可被互联网或集群内横向利用的攻击面？不同发行版的默认加固差异有多大？ | 第2、8页 |
| KQ-2 | 运行时逃逸的可检测性 | 主流逃逸路径（runc/CRI-O漏洞、危险挂载、特权容器、内核漏洞利用）在内核级遥测下分别呈现何种可观测特征？检测规则如何避免淹没在容器高频正常行为噪声中？ | 第4、7页 |
| KQ-3 | 多租户隔离的强度边界 | 命名空间+配额+网络策略的"软隔离"在多租户场景下究竟能抵御何种强度的攻击者？何种场景必须升级至独立集群、虚拟集群或微虚机（Kata/gVisor）隔离？ | 第7页 |
03 · 生态参与方与演进时间线
3.1 生态参与方与职责
| 角色 | 职责/产出 | 代表 |
|---|---|---|
| 治理与社区 | 项目治理、安全响应流程（SRC）、漏洞披露与修复协调、发布节奏管理 | CNCF（托管Kubernetes等项目）；Kubernetes SIG（特别兴趣小组：SIG Auth、SIG Security、SIG Node、SIG Network等）；kubernetes-security-announcement邮件列表 |
| 安全指引制定方 | 容器安全基线、加固指南、标准框架 | NIST（SP 800-190）；NSA与CISA联合《Kubernetes Hardening Guidance》（v1.0于2021年8月、v1.1于2022年8月发布）；CIS（Kubernetes Benchmark）；OWASP（Kubernetes Top 10，2022年发布） |
| 运行时与工具生态 | 容器运行时、沙箱、扫描、检测、策略引擎开源工具 | containerd、CRI-O、runc；gVisor、Kata Containers；Trivy、Grype；Falco、Tetragon；OPA Gatekeeper、Kyverno；Cilium |
| 商业平台与服务 | 托管Kubernetes发行版、CNAPP/CWPP安全产品、企业支持 | 各大云厂商托管K8s服务；SUSE Rancher、Red Hat OpenShift、VMware Tanzu等发行版；Aqua、Sysdig、Wiz、Prisma Cloud等安全厂商 |
| 学术与评测 | 逃逸机理、检测算法、大规模测量研究 | USENIX Security、IEEE S&P、ACM CCS等会议上的容器安全论文；容器逃逸与供应链实证研究社区 |
3.2 领域演进关键时间线
| 时间 | 事件（均可公开查证） |
|---|---|
| 2013—2015 | 2013年Docker开源，容器进入主流；2014年6月Google开源Kubernetes；2015年下半年CNCF成立（与Kubernetes产业化同步），云原生生态进入产业化加速期，容器安全议题随之进入产业与监管视野 |
| 2017 | 5月NIST发布SP 800-190《Application Container Security Guide》，从镜像、注册表、编排器、容器、宿主机五个层面系统定义容器安全关切；同年Kubernetes社区确立以安全为重点的演进方向，RBAC自v1.8进入稳定版（GA） |
| 2018—2019 | 容器运行时高危漏洞集中爆发：CVE-2018-1002105（kube-apiserver提权，CVSS 9.8）、CVE-2019-5736（runc容器逃逸，CVSS 8.6）、CVE-2019-1002101与CVE-2019-11246（kubectl cp路径穿越类问题）。社区确立了"默认安全"演进基调 |
| 2021—2022 | NSA与CISA联合发布《Kubernetes Hardening Guidance》（2021年8月v1.0，2022年8月v1.1）；OWASP发布Kubernetes Top 10（2022年）；Kubernetes v1.25（2022年8月）正式移除PodSecurityPolicy，以内置Pod Security Standards三档模式（Privileged/Baseline/Restricted）取而代之 |
| 2022—2023 | 运行时与供应链并重：CVE-2022-0811（CRI-O cr8escape，CVSS 8.8）、CVE-2022-0492（cgroups release_agent容器逃逸）、CVE-2024-21626（runc工作目录逃逸，CVSS 8.6）；Gateway API v1.0发布（2023年10月），入口流量治理进入标准化；Istio ambient mesh引入无Sidecar数据面模式 |
| 2024至今 | CVE-2024-21626（runc工作目录逃逸，CVSS 8.6）等运行时漏洞修复再度验证补丁SLA纪律；软件供应链签名验证（sigstore/cosign）与策略即代码（Kyverno/Gatekeeper）走向默认开启；eBPF成为CNI与服务网格数据面主流选项（Cilium生态）；机密计算（TEE）与"使用中数据"保护开始进入容器运行时研究议程；AI工作负载推动GPU共享与多租户隔离成为新焦点 |
04 · 术语速查与常见误区
4.1 核心术语
| 术语 | 释义 |
|---|---|
| 控制平面（Control Plane） | 集群的"大脑"：API Server、etcd、Scheduler、Controller Manager、Cloud Controller Manager五个组件，任一失守通常意味着整集群失守 |
| Pod | Kubernetes最小调度单元，可含一个或多个共享网络命名空间与存储卷的容器 |
| etcd | 集群一致性与配置数据的分布式键值存储，保存包括Secrets在内的全部集群状态；其快照泄露等同于集群全部机密泄露 |
| ServiceAccount（SA） | 为Pod内进程赋予的集群内身份；SA令牌即API访问凭证，是工作负载身份治理的核心对象 |
| 准入控制器（Admission Controller） | API Server处理链中在持久化前执行的校验/变更插件，是"默认安全"落地的关键闸口，分变更型（Mutating）与校验型（Validating）两类 |
| Pod Security Standards（PSS） | 内置的三档Pod安全配置标准：Privileged（无限制）、Baseline（最小限制防已知提权）、Restricted（强化限制遵循最佳实践） |
| RuntimeClass | Kubernetes原生资源，用于为Pod选择不同的容器运行时/沙箱（如gVisor、Kata Containers），实现硬件级隔离粒度控制 |
| NetworkPolicy | 声明式三层/四层网络访问控制资源；注意Kubernetes默认"全部放行"，NetworkPolicy的生效完全依赖CNI插件支持 |
| eBPF | Linux内核可编程子系统，可在不改内核源码的情况下实现网络转发与系统调用级观测，是Cilium、Falco、Tetragon等云原生安全工具的底座 |
| Supply Chain Levels for Software Artifacts（SLSA） | 由Google发起、OpenSSF维护的软件供应链完整性分级框架（L1—L4），定义从构建到分发的可信度要求 |
4.2 常见误区辨析
| 误区 | 辨析 |
|---|---|
| "容器本身就是安全边界" | 容器是进程级隔离，与宿主机共享内核。runc（CVE-2019-5736、CVE-2024-21626）、CRI-O（CVE-2022-0811）等运行时漏洞与危险配置（特权容器、宿主机路径挂载）均可导致逃逸。需以"容器可被逃逸"为假设设计纵深防御（第4页）。 |
| "命名空间（Namespace）提供了多租户隔离" | Namespace是逻辑分组与配额单位，不是安全边界：默认网络全通、部分资源集群级共享（节点、PV、部分RBAC为ClusterRole）。对抗多租户威胁需叠加PSA、NetworkPolicy、ResourceQuota乃至独立集群（第7页）。 |
| "托管K8s由云厂商负责安全" | 共享责任模型下，云厂商负责控制面组件的补丁与高可用，而节点操作系统、网络策略、RBAC、镜像安全、运行时检测、应用配置全部属于客户责任面——恰恰是历史事件的全部发生位置。 |
| "镜像扫描一次就可以长期信任" | 镜像内依赖的新漏洞每日披露，扫描结果快速过期；且静态扫描无法覆盖运行时配置错误与供应链投毒。需将扫描嵌入CI准入、仓库准入门与持续监测三个环节（第6页）。 |
| "NetworkPolicy配置了网络就安全了" | NetworkPolicy语义由CNI实现，部分CNI（如Flannel）完全不支持；且其为L3/L4控制，无法防御应用层攻击（SQL注入、SSRF、凭证钓鱼）。需配合七层策略与东西向mTLS（第5页）。 |
05 · 研究范围与合规边界
- 对象范围：Kubernetes容器编排平台自身的安全（v1.25及之后版本为主线），覆盖自建集群与各大云厂商托管集群；涉及容器运行时（containerd/CRI-O/runc）、镜像供应链、CNI网络、服务网格与集群运维全生命周期。
- 深度边界：做到"攻击面识别→防护基线→检测响应→治理度量"层面；对漏洞的PoC利用与EXP开发不在本子课题范围，漏洞条目仅引用公开编号与官方修复版本。
- 协同边界：云责任分界与错误配置治理属子课题01，软件供应链SBOM/SLSA总纲属子课题03，Serverless函数安全属子课题04，多云一致防护属子课题05，云上合规评估属子课题06——本子课题为其提供容器平台侧的深度展开与落地基线。
- 时效声明：所引标准、CVE编号、版本变更均以官方发布（NIST、NSA/CISA、CIS、OWASP、Kubernetes官方文档、NVD）为准；组件行为描述以对应版本官方文档为准，不虚构精确数值。
合规与伦理声明：①本子课题为防御研究，遵守《网络安全法》《数据安全法》《个人信息保护法》及网络安全等级保护相关规范；②文中集群加固、检测与演练方法仅适用于自有或获书面授权的环境；③对公开漏洞的描述限于防御所需的机理与防护要点，不提供可直接复用的攻击代码；④涉及日志、运行时遥测数据的采集遵循最小化与留存期限控制原则，跨租户数据采集须有明确法律与合同依据。
06 · 与课题体系的协同关系
| 协同子课题 | 数据/方法交换内容 |
|---|---|
| 01 云安全架构与共享责任模型 | 本子课题明确"托管K8s控制面归云厂商、节点与配置归客户"的责任分界细化；其CSPM配置审计规则与本课题基线核查项可互相映射；Capital One类元数据凭证风险在容器场景的对应面（Pod访问云元数据服务）由本课题第4页给出防护 |
| 03 云原生软件供应链与镜像安全 | 本课题第6页聚焦镜像/Chart层面的供应链落地（扫描、签名、准入）；SBOM格式规范、SLSA分级与CI/CD凭证治理的总纲方法自子课题03继承 |
| 04 Serverless与函数计算安全 | 容器是多数FaaS平台的底层执行单元（如Knative构建于K8s之上），本课题的PSS、运行时检测与最小权限方法可直接迁移至函数场景的容器沙箱 |
| 05 多云与混合云统一防护 | 不同云托管K8s（EKS/AKS/GKE及国内各云）的默认配置差异核查方法、跨集群策略等价性表达，为子课题05的多云策略一致性提供模板 |
| 06 云安全合规与评估 | 本课题第8页的CIS Benchmark映射表、等保2.0云扩展要求落地项与审计证据清单，直接作为子课题06合规测评的技术输入 |
07 · 预期成果与交付物
- 《Kubernetes集群攻击面清单与默认配置核查手册》（组件端口、历史高危面、发行版差异对照，第2页）
- 《Kubernetes身份与权限最小权限基线（RBAC/SA/准入控制模板集）》（含Gatekeeper/Kyverno策略样例，第3页）
- 《Pod安全标准与容器运行时防护基线》（PSS三档落地指引、沙箱运行时选型矩阵、逃逸检测规则库，第4页）
- 《云原生网络隔离与服务网格安全配置指南》（NetworkPolicy模式库、mTLS与L7策略基线，第5页）
- 《容器供应链安全流水线规范》（镜像扫描、签名验证、SBOM、CI/CD凭证治理，第6页）
- 《Kubernetes多租户隔离与事件响应手册》（隔离强度分级、检测场景库、响应流程，第7页）
- 《Kubernetes安全基线核查与成熟度评估体系》（CIS/NSA-CISA映射、度量指标、实施路线图，第8页）
本节参考来源（第1页）
以下均为真实可查的权威来源（NIST、NSA/CISA、CIS、OWASP、Kubernetes官方文档、CNCF、NVD），用于支撑本页事实性表述。
NIST SP 800-190《Application Container Security Guide》（2017年5月）：csrc.nist.gov/pubs/sp/800/190/final。
NSA & CISA《Kubernetes Hardening Guidance》v1.1（2022年8月，v1.0为2021年8月）：nsa.gov（发布页）；PDF原文经CISA官网发布。
Kubernetes官方安全文档（集群安全、Pod安全标准、RBAC、NetworkPolicy等）：kubernetes.io/docs/concepts/security。
CIS Kubernetes Benchmark（现行v1.8及后续版本）：cisecurity.org/cis-benchmarks；CIS Benchmarks对应的开源核查工具kube-bench：github.com/aquasecurity/kube-bench。
OWASP《Kubernetes Top 10》（2022年）：owasp.org/www-project-kubernetes-top-ten。
CNCF（云原生计算基金会）项目全景与年度报告：cncf.io；Kubernetes v1.25变更日志（PodSecurityPolicy移除）：github.com/kubernetes/kubernetes CHANGELOG-1.25。
NVD（美国国家漏洞库）CVE官方条目：CVE-2018-1002105、CVE-2019-5736、CVE-2022-0811、CVE-2024-21626等：nvd.nist.gov。