企业官网建设流程全解析

• 云原生
• 可观测性
• 指标监控
• 监控大盘
• 告警

kube-prometheus 通过 CI 中集成的 kubescape 安全扫描（NSA 框架）对生成的全部 Kubernetes manifests 进行持续安全审计，本文基于 docs/security.md 展开，详细解读扫描机制、本地执行方式，以及 node-exporter、prometheus-adapter、blackbox-exporter、kube-state-metrics、prometheus-operator 五个组件因功能需要而不得不做出的安全例外，帮助你理解"默认安全最佳实践"与"功能必需例外"之间的取舍逻辑，并能自行运行扫描、解读结果。

kube-prometheus 的安全审计机制

kube-prometheus 仓库中通过 jsonnet 生成的全部 Kubernetes manifests（位于 manifests/ 目录）都会在 CI 中接受一次安全审计，审计工具为 kubescape（ARMO 开源的 Kubernetes 安全扫描工具），扫描框架为NSA（美国国家安全局 Kubernetes 加固指南框架）。

这意味着每次代码变更提交后，CI 都会重新生成 manifests 并执行安全扫描，一旦风险评分超过阈值，构建即失败，从源头上阻止存在明显安全隐患的配置被合入仓库。该能力的历史引入可见于 CHANGELOG.md 中 "Scan generated manifests with kubescape in CI" 这一条目。

本地运行安全扫描：make kubescape

除了 CI 自动扫描，你可以在本地对当前仓库生成的 manifests 执行同样的安全审计。对应 Makefile 目标定义如下（见 Makefile）：

.PHONY: kubescape kubescape: $(KUBESCAPE_BIN) ## Runs a security analysis on generated manifests - failing if risk score is above threshold percentage 't' $(KUBESCAPE_BIN) scan framework nsa --compliance-threshold $(KUBESCAPE_THRESHOLD) -v --exceptions 'kubescape-exceptions.json' manifests/

执行方式：

make kubescape

该命令的构成与含义如下：

如果本机尚未安装 kubescape，Makefile 中的$(KUBESCAPE_BIN)依赖会自动触发安装脚本（见 Makefile），安装位置为~/.kubescape/bin/kubescape。

例外清单：哪些组件突破了默认安全基线

仓库目标是"默认安全"，但受限于项目本质（监控组件天然需要更深的系统与集群访问权限），以下组件必须做出例外。这些例外以显式方式声明在 kubescape-exceptions.json 中，被扫描命令通过--exceptions参数加载，从而避免误报导致 CI 失败。

node-exporter：Host 级访问例外

node-exporter 作为节点指标采集器，是例外最多的组件（对应 manifests/nodeExporter-daemonset.yaml）：

• Host Port：设置为主机端口。文档指出 Kubernetes 本身在启用 Host Network 时就会默认设置 Host Port（对应 Kubernetes 源码pkg/apis/core/v1/defaults.go中 HostNetwork 为 true 时自动设置 HostPort 的默认逻辑），既然无法避免，kube-prometheus 便将其配置为偏好的端口9100；
• Host PID =true：node-exporter 需要直接访问宿主机 PID 命名空间以采集进程统计信息；
• Host Network =true：node-exporter 需要直接访问宿主机网络命名空间以采集网络统计信息；
• automountServiceAccountToken = true（Pod 层）：因为 kube-rbac-proxy sidecar 需要连接 Kubernetes API server 完成鉴权。

对应生成的 DaemonSet 清单中可见如下字段（manifests/nodeExporter-daemonset.yaml、manifests/nodeExporter-daemonset.yaml）：

spec: template: spec: automountServiceAccountToken: true hostNetwork: true hostPID: true # kube-rbac-proxy sidecar 暴露 hostPort: 9100

prometheus-adapter：API server 访问例外

prometheus-adapter 作为 metrics API 适配器（对应 manifests/prometheusAdapter-deployment.yaml），在Pod 层设置automountServiceAccountToken = true，原因同样是应用本身需要连接 Kubernetes API server（它以 APIService 形式注册并提供 custom metrics 接口，见 prometheusAdapter-apiService.yaml）。

blackbox-exporter：API server 访问例外

blackbox-exporter（对应 manifests/blackboxExporter-deployment.yaml）在Pod 层设置automountServiceAccountToken = true，因为其 kube-rbac-proxy sidecar 需要连接 Kubernetes API server 完成请求鉴权。

kube-state-metrics：API server 访问例外

kube-state-metrics（对应 manifests/kubeStateMetrics-deployment.yaml）在Pod 层设置automountServiceAccountToken = true，因为它的两个 kube-rbac-proxy sidecar（kube-rbac-proxy-main与kube-rbac-proxy-self）需要连接 Kubernetes API server。

prometheus-operator：API server 访问例外

prometheus-operator（对应 manifests/prometheusOperator-deployment.yaml）在Pod 层设置automountServiceAccountToken = true，因为其 kube-rbac-proxy sidecar 需要连接 Kubernetes API server。

两层 automountServiceAccountToken 设计：ServiceAccount 与 Pod 的差异

值得注意的细节是：上述组件虽然都在Pod 层显式开启了automountServiceAccountToken，但它们的ServiceAccount 对象却普遍声明为automountServiceAccountToken: false。例如：

• prometheusOperator-serviceAccount.yaml、prometheusAdapter-serviceAccount.yaml、blackboxExporter-serviceAccount.yaml、kubeStateMetrics-serviceAccount.yaml、nodeExporter-serviceAccount.yaml 均为false；
• 而 prometheus-serviceAccount.yaml 为true（Prometheus 自身需要访问 Kubernetes API 发现 targets）。

这种"ServiceAccount 层关闭、Pod 层开启"的组合，是 kube-prometheus 对 Kubernetes 两层覆盖机制的精细利用：ServiceAccount 上的automountServiceAccountToken是默认值，而 Pod 上的同名字段优先级更高、可以覆盖前者。从 jsonnet 源码可进一步印证这一设计——jsonnet/kube-prometheus/components/blackbox-exporter.libsonnet 与 jsonnet/kube-prometheus/components/prometheus-adapter.libsonnet 中 ServiceAccount 声明automountServiceAccountToken: false，而 jsonnet/kube-prometheus/components/node-exporter.libsonnet、jsonnet/kube-prometheus/components/prometheus-operator.libsonnet 中 Pod 层则显式置为true。

对照之下，grafana 由于既不需要访问 Kubernetes API server，也没有 kube-rbac-proxy sidecar，在 grafana-deployment.yaml 与 grafana.libsonnet 中同时关闭了 token 自动挂载，属于"默认安全"的典型代表。

例外规则的声明方式：kubescape-exceptions.json

所有被接受的例外都集中声明在 kubescape-exceptions.json 中，共包含两类postureExceptionPolicy（姿态异常策略，动作均为alertOnly，即仅告警不阻断）：

1. exclude-automountServiceAccountToken-checks：豁免 6 个资源的 "Automatic mapping of service account" 控制项，资源包括 DaemonSetnode-exporter与 Deploymentblackbox-exporter、kube-state-metrics、prometheus-adapter、prometheus-operator，以及 ServiceAccountprometheus-k8s；
2. exclude-node-exporter-host-access-checks：仅针对 DaemonSetnode-exporter，豁免 "Container hostPort"、"Host PID/IPC privileges"、"HostNetwork access" 三个控制项。

如果你在 fork 或自定义部署中调整了这些组件的清单，可参照该文件的格式增删例外条目，再重新运行make kubescape验证。

如何验证与扩展安全基线

1. 验证当前状态：在仓库根目录执行make kubescape，观察输出中每个控制项的状态与最终合规性评分（阈值 1%，见 Makefile）；
2. 理解例外必要性：对照本文第二节，确认每个例外都与"Host 级指标采集"或"kube-rbac-proxy / 应用连接 API server"直接相关，属于功能性必需而非配置疏漏；
3. 保持安全增量：在生成清单中加入自定义组件时，应优先遵循仓库的既有安全实践——allowPrivilegeEscalation: false、capabilities全部 drop、readOnlyRootFilesystem: true、runAsNonRoot: true、seccompProfile: RuntimeDefault等字段在 manifests/ 各清单中随处可见，可作为新的安全默认基线；
4. 跟踪合规性：kube-prometheus 还提供了 security.md 之外的辅助材料，如 kubescape-exceptions.json 的维护规则与 CONTRIBUTING.md 中的贡献约定，新增例外时必须同时更新该文件以保证 CI 通过。

小结

kube-prometheus 的安全模型可以概括为"默认加固、显式例外、集中豁免、CI 兜底"：绝大多数组件遵循 NSA 框架的加固建议；少数监控组件因功能必须获得 Host 命名空间或 API server 访问权，则通过 Pod 层automountServiceAccountToken、hostPID、hostNetwork等字段显式突破，并在 kubescape-exceptions.json 中集中登记；最终由 CI 中的 kubescape 扫描（本地可用make kubescape复现）持续把关，确保安全状态可审计、可追踪。

• 云原生
• 可观测性
• 指标监控
• 监控大盘
• 告警