1. 课程导论：为什么需要指标驱动的安全基线？Prometheus 在云原生安全中的角色

1.1 传统安全基线的困境

在传统 IT 环境中，安全基线检查通常依赖周期性扫描和人工审计。管理员定期登录节点，执行脚本检查文件权限、内核参数、密码策略等。这种方式在静态、低频率变更的环境中尚可接受，但在云原生场景下暴露出明显短板：

• 配置漂移不可控：Kubernetes 集群中 Pod、Service、NetworkPolicy 等资源持续创建和销毁，安全配置可能在数秒内偏离基线。
• 人工响应滞后：从配置变更到被发现，再到人工介入修复，往往经历数小时甚至数天，攻击窗口期过长。
• 覆盖面有限：传统检查难以覆盖容器运行时行为、API Server 审计日志、RBAC 权限滥用等动态安全维度。

1.2 指标驱动：从“扫描”到“观测”的范式转变

指标驱动的安全基线，本质是将安全状态量化为可观测的时序数据，通过 Prometheus 等监控系统持续采集、存储、分析，并触发自动化响应。其核心优势在于：

例如，当某个 Pod 的 securityContext.runAsNonRoot 被意外设置为 false，传统扫描可能在下一次定时任务中才发现；而指标驱动模式下，Prometheus 可以实时采集 kube_pod_security_context_non_root 指标，一旦值变为 0，立即触发告警并自动执行修复策略。

1.3 Prometheus 在云原生安全中的角色

Prometheus 已成为云原生可观测性的事实标准，其在安全领域的角色可以概括为“安全指标的采集器、存储引擎、告警引擎”三位一体。具体而言：

• 采集层：通过 kube-state-metrics、node_exporter、cadvisor 以及自定义 Exporter，采集集群资源的安全配置指标（如 Pod 特权模式、RBAC 绑定、NetworkPolicy 覆盖率）。
• 存储与查询层：Prometheus TSDB 高效存储高基数安全指标，PromQL 支持灵活的聚合与关联查询，例如“找出所有未设置 readOnlyRootFilesystem 的 Deployment”。
• 告警与自动化层：基于 Alertmanager 实现安全基线的实时告警，并可联动 Webhook 触发 Kubernetes 原生修复（如自动删除违规 Pod、更新 NetworkPolicy）。

1.4 为什么选择 Prometheus 作为安全基线引擎？

在云原生生态中，Prometheus 并非唯一可观测性工具，但其在安全基线场景下具备不可替代的优势：

• 原生集成 Kubernetes：通过 kube-state-metrics 和 kubelet 内置指标，无需额外 Agent 即可获取 Pod、Node、Namespace 等资源的安全属性。
• 高基数处理能力：安全指标通常带有大量标签（如 namespace、pod、container），Prometheus TSDB 针对高基数场景做了优化。
• 灵活的告警规则：PromQL 支持复杂的逻辑运算和聚合，可以定义“如果某个 Namespace 中超过 3 个 Pod 未设置 runAsNonRoot，则触发告警”这类业务语义规则。
• 生态丰富：社区已有大量现成的安全指标 Exporter 和告警规则（如 kube-bench、kube-hunter 的 Prometheus 集成），降低实施成本。

1.5 本课程的核心内容与学习路径

本课程将围绕“指标驱动的安全基线”这一核心理念，从以下四个阶段展开：

通过本课程的学习，你将能够：

• 独立设计一套基于 Prometheus 的集群安全基线指标体系；
• 编写 PromQL 查询，实时发现安全配置漂移；
• 配置 Alertmanager 实现秒级告警，并联动 Kubernetes 原生 API 自动修复；
• 构建可复用的安全基线仪表盘，支撑合规审计与日常运维。