框架不是答案，是一份问题清单

在 LabHub 中继续学习

一句话总结

CIS、NSA/CISA、MITRE ATT&CK 并不是相互竞争的标准，而是职责不同的工具。CIS 是配置检查清单，NSA/CISA 是设计指南，ATT&CK 是攻击者行为词典。把三者连接成实际证据的，则是审计日志。

概念图: 职责不同的工具 · 完整性 · 共同语言 · 它是问题清单，不是标准答案。

为什么需要它

要回答“我们的集群安全吗”，必须先有标准。没有标准，每个人的检查方式都不同，既无法比较去年与今年，也无法向外部说明。

框架的价值在于完整性和共同语言。它减少遗漏，让不同组织使用相同表述。但框架不会告诉你“照做就一定安全”。它是问题清单，不是标准答案。

工作原理

CIS Kubernetes Benchmark——配置检查清单

每一项都会提出“这项配置是否为这个值”这样的具体问题，并按控制平面文件权限、apiserver 选项、etcd 配置、controller-manager/scheduler、kubelet、策略等领域分类。

每项都有 Automated / Manual 分类，区分可自动检查的项目与必须由人判断的项目。
还有 Level 1 / Level 2。L1 适用于大多数环境；L2 是为了安全而牺牲部分功能的强化项目。
kube-bench 等工具可自动执行这些检查。

使用 CIS 时要注意：许多项目不适用于托管集群（EKS/GKE/AKS），因为用户无法访问控制平面文件。因此，托管服务另有专用 Benchmark。无论考试还是现场，比起“通过了多少项”这一数字，更重要的是理解每项为何存在。

NSA/CISA Kubernetes Hardening Guidance——设计指南

它不是检查清单，而是以叙述方式说明“应如何设计”，可归纳为五个方面。

Pod 安全——以非 root 运行、不可变文件系统、镜像扫描、准入策略
网络隔离与强化——命名空间隔离、NetworkPolicy、限制控制平面访问、静态与传输加密
认证与授权——禁用匿名访问、强用户认证、RBAC 最小权限
日志审计——启用审计日志、把日志发送到集群外、配置告警
升级与配置管理——定期打补丁、删除不必要组件、定期检查漏洞

如果说 CIS 问的是“这个值对吗”，NSA/CISA 问的就是“这个结构对吗”。两者互为补充。

MITRE ATT&CK for Containers——攻击者行为词典

它不是从防御者视角出发，而是把攻击者实际采取的行为按战术（Tactic）和技术（Technique）编成目录。容器矩阵中的战术流程大致如下。

초기 접근 → 실행 → 지속성 → 권한 상승 → 방어 회피 → 자격증명 접근
        → 탐색 → 측면 이동 → 영향

其中的典型技术与前面模块学到的内容完全重合：通过暴露 API 获得初始访问，通过部署容器执行操作，通过特权容器逃逸，通过容器 API 访问凭据，以及枚举集群资源。

ATT&CK 的用途在于设计检测。以技术为单位询问“我们能否检测这种技术”，日志收集与告警规则就会具体化。如果 CIS 偏向预防，ATT&CK 就偏向检测。

审计日志——把三个框架连接成证据

审计日志在合规中承担三项工作。

证明——用记录展示“我们正在运行这项控制”
调查——事故发生后重建事件经过
检测——寻找正在进行的攻击信号

Kubernetes 审计策略使用四个级别控制记录量。

级别	记录内容
`None`	不记录
`Metadata`	请求者、操作、资源、时间；不含正文
`Request`	元数据 + 请求正文
`RequestResponse`	元数据 + 请求正文 + 响应正文

如果对 Secret 等资源设置 RequestResponse，审计日志本身会成为秘密泄露路径。因此，实践中的策略通常只以 Metadata 记录 Secret/ConfigMap，而对 RBAC 对象变更等敏感操作使用 RequestResponse。

与记录什么同样重要的是：是否记录拒绝（deny）。 权限探测只会表现为反复失败。短时间内，同一主体访问多个不同目标并被拒绝数十次，就是枚举行为的指纹。不记录拒绝，这个信号就不存在。 反方向也有用：部署后拒绝日志突然消失，可能表示检查机制本身消失了。

最后，日志必须发送到集群外部。受入侵集群内的日志可能被删除，Pod 也可能已经消失。

实际现场中的情况

作者博客提出的 RBAC 审计流程，是把 CIS 项目转化为实际查询的好例子。

使用 kubectl auth can-i --list --as=system:serviceaccount:production:app-deployer -n production，一次查看特定主体的全部有效权限
使用 kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin")'，完整调查绑定 cluster-admin 的主体
还要规定周期：通过季度 RBAC 权限审查识别权限过高的主体，通过每月策略违规报告确认违规资源现状

这里的重点是周期已经确定。合规不是一次性检查，而是运维惯例。

作者对通配符权限的论证也值得原样理解：使用 resources: ["*"] 或 verbs: ["*"]，不仅会无限制访问当前资源，还会无限制访问未来新增的资源。这准确反驳了“现在安全，所以没关系”的说法。

策略引擎的运维原则也应从合规角度理解：以 Policy as Code 管理；变更前必须用 dryrun 评估影响；预先准备发生故障时的紧急恢复流程。 作者最后一句话是：“RBAC 和策略引擎虽然是技术工具，但要有效运营，必须与组织的访问控制治理相结合。”

下一项实验要做什么

最后一项实验将亲自执行整个集群的 RBAC 审计：找出拥有 * 权限的 ClusterRole 并列出；检测拥有 escalate、bind、impersonate 的角色；通过 kubectl auth can-i --list --as= 确认服务账户的有效权限；创建新的最小权限 Role，并通过测量证明只允许期望的操作，其余操作均不允许；最后编写包含这些证据的审计报告。