📚 课程目录第4章运行基线定义

4. 运行基线定义：什么是运行基线、基线包含的维度（安全、性能、合规）

在云原生环境中，服务目录平台承载着大量微服务的注册、发现、配置与治理功能。为了确保平台在持续交付与动态扩缩容场景下保持稳定、安全且符合监管要求，必须引入运行基线（Runtime Baseline）的概念。运行基线是一组经过验证的、可量化的最低标准集合，用于衡量服务目录平台在安全、性能与合规三个核心维度上的运行状态。任何偏离基线的行为都应被 Kyverno 策略引擎捕获并触发告警或自动修复。

4.1 什么是运行基线

运行基线是服务目录平台在正常生产运行时所应满足的最小可接受状态。它并非静态的配置文件，而是一组由 Kyverno 策略持续评估的动态阈值与规则集合。基线定义了“什么是正常”，从而让平台能够快速识别“什么是异常”。

  核心特征：
  可测量性：每个基线项都有明确的指标或状态值（如 CPU 使用率 ≤ 70%、TLS 版本 ≥ 1.2）。
可执行性：基线通过 Kyverno 策略以 validate、mutate 或 generate 规则落地，在 Admission 阶段或后台持续审计。
可演进性：基线随业务需求、安全威胁与合规要求的变化而定期更新，并通过 GitOps 流程管理版本。

实践提示：运行基线不是“理想状态”，而是“最低可接受状态”。例如，安全基线要求所有服务使用 TLS 1.2 以上，但实际生产可能已全部升级到 TLS 1.3，此时基线应作为兜底防线，而非性能上限。

4.2 基线包含的维度

运行基线从三个相互独立又彼此关联的维度进行定义。下表总结了每个维度的关注焦点、典型指标以及 Kyverno 策略的落地方式。

维度	关注焦点	典型基线指标	Kyverno 策略示例
安全	防止未授权访问、数据泄露与供应链攻击	TLS 版本、镜像签名、容器非 root 运行、网络策略	`validate-tls-version`、`verify-image-signature`
性能	保障服务响应速度与资源利用率在可接受范围	P99 延迟、CPU/内存使用率、连接池大小	`validate-resource-limits`、`check-latency-slo`
合规	满足行业法规、公司政策与审计要求	数据加密、审计日志、标签规范、Pod 安全标准	`require-encryption`、`audit-log-enabled`

4.3 安全维度详解

安全基线是运行基线的第一道防线。在服务目录平台中，安全基线主要覆盖以下四个子领域：

传输安全：所有服务间通信必须使用 TLS 1.2 或更高版本，禁止明文 HTTP 流量进入服务网格。
镜像安全：仅允许运行经过签名验证的容器镜像，禁止使用 latest 标签或来自不可信仓库的镜像。
运行时安全：容器必须以非 root 用户运行，禁止挂载宿主机敏感路径，禁止特权容器。
网络安全：默认拒绝所有入站/出站流量，仅通过 NetworkPolicy 显式放行必要通信。

常见误区：安全基线不是“一次性配置”。当新的 CVE 漏洞披露或 TLS 协议版本被弃用时，基线必须同步更新。建议将基线策略存储在 Git 仓库中，通过 Kyverno 的 generate 规则自动同步到所有集群。

4.4 性能维度详解

性能基线确保服务目录平台在预期负载下仍能提供稳定的响应能力。性能基线通常包含以下关键指标：

延迟（Latency）：服务注册/发现请求的 P99 延迟不得超过 200ms，P50 延迟不得超过 50ms。
资源使用率：每个服务实例的 CPU 使用率不超过 70%，内存使用率不超过 80%，避免资源争抢。
连接池健康：数据库连接池、HTTP 连接池的活跃连接数不得超过最大连接数的 85%。
错误率：服务调用错误率（5xx 响应）不得超过 0.1%。

  Kyverno 与性能基线的结合：虽然 Kyverno 本身不直接采集指标，但可以通过 validate 规则检查 Pod 的 Resource 声明是否满足基线要求（如 requests.cpu >= 100m），并通过 mutate 规则自动注入 sidecar 代理以启用指标采集。

4.5 合规维度详解

合规基线确保服务目录平台满足内部审计与外部监管要求。常见的合规基线包括：

合规领域	基线要求	典型策略
数据保护	所有敏感数据（如密钥、证书）必须使用 Kubernetes Secret 并启用加密存储	`require-secret-encryption`
审计追踪	所有 API 变更操作必须记录审计日志，日志保留期 ≥ 90 天	`audit-log-enabled`
标签与注解	每个服务必须包含 `app.kubernetes.io/name`、`app.kubernetes.io/version` 等强制标签	`validate-required-labels`
Pod 安全标准	所有 Pod 必须满足 Pod Security Standards 的 `restricted` 级别	`validate-pod-security`

4.6 基线之间的关联与冲突处理

三个维度的基线并非完全独立，在实际运行中可能存在冲突。例如：

安全 vs 性能：严格的 TLS 双向认证（mTLS）会增加握手延迟，可能影响 P99 延迟基线。此时需要协商一个可接受的折中值，例如将 mTLS 的延迟预算纳入性能基线。
合规 vs 安全：合规要求所有 Secret 必须加密存储，而安全基线要求 Secret 的访问日志必须保留 90 天。两者可以协同，但需确保加密密钥的轮换策略不破坏审计链。
性能 vs 合规：合规要求启用全量审计日志，可能产生大量 I/O 操作，影响服务注册性能。建议采用异步审计日志写入，并设置独立的性能基线阈值。

最佳实践：在定义基线时，建议为每个维度设置优先级。例如，安全基线优先级最高，任何违反安全基线的行为直接阻断；性能基线优先级次之，允许在安全基线满足的前提下进行弹性调整；合规基线作为长期审计目标，可设置告警但不阻断。

4.7 基线版本管理与演进

运行基线应像代码一样进行版本管理。推荐使用 GitOps 工作流：

将基线定义存储在 Git 仓库中，每个基线版本对应一个 Git Tag。
通过 Kyverno 的 generate 策略自动将基线策略同步到目标集群。
当基线版本升级时，先在一个非生产集群进行灰度验证，确认无冲突后再推送到生产集群。
每次基线变更都生成审计记录，便于追溯与合规审查。

基线版本示例：

# baseline-v1.2.0.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: security-baseline-v1.2.0
spec:
  rules:
    - name: require-tls-1.2
      match:
        resources:
          kinds:
            - Service
      validate:
        message: "TLS version must be >= 1.2"
        pattern:
          spec:
            ports:
              - (tlsVersion): ">=1.2"