3. 镜像安全水位概念：什么是镜像安全水位？安全基线与合规要求

在 Kubernetes Deployment 滚动更新场景中，镜像安全水位并非一个单一的阈值，而是一组经过风险量化后定义的可接受安全状态边界。它回答了这样一个问题：“一个镜像在投入生产滚动更新之前，其安全缺陷的严重程度和数量必须控制在什么水平以下？”

镜像安全水位由三个核心维度构成：安全基线（Security Baseline）、合规要求（Compliance Requirements）和风险容忍度（Risk Tolerance）。三者共同决定了滚动更新流水线中“阻断”与“放行”的决策点。

3.1 安全基线的层次模型

安全基线是镜像安全水位的“地板”，通常由组织安全策略或行业标准定义。我们将其划分为三个层次：

3.2 合规要求对水位的影响

合规要求将安全水位从“技术指标”提升为“法律/监管红线”。不同合规框架对镜像安全有不同的量化标准：

• PCI DSS v4.0：要求所有容器镜像必须通过漏洞扫描，且 Critical 漏洞必须在发现后 30 天内修复。
• HIPAA：强调镜像中不得包含未授权的 PHI（受保护健康信息）数据，且必须记录镜像来源。
• SOC 2：要求镜像构建和部署过程具备可审计的变更记录，且安全扫描结果必须存档。
• NIST SP 800-190：明确要求容器镜像必须使用最小基础镜像，且禁止使用 latest 标签。

合规要求通常比技术基线更严格，因为它们引入了时间维度（修复 SLA）和证据维度（审计日志）。

3.3 镜像安全水位的可视化模型

下图展示了镜像安全水位在滚动更新决策中的位置：

3.4 安全水位在滚动更新中的实际表现

在 Deployment 滚动更新过程中，安全水位通过 Admission Controller 或 CI/CD 门禁 实现。以下是一个典型的安全水位策略配置示例：

# 安全水位策略示例（YAML 格式）
apiVersion: security.policy.io/v1
kind: ImageSecurityWatermark
metadata:
  name: production-watermark
spec:
  # 致命漏洞：零容忍
  criticalVulnerabilities: 0
  # 高危漏洞：最多 2 个，且必须无已知利用
  highVulnerabilities:
    maxCount: 2
    noKnownExploit: true
  # 中危漏洞：最多 10 个，且修复 SLA 为 7 天
  mediumVulnerabilities:
    maxCount: 10
    fixSlaDays: 7
  # 合规标签：必须包含
  requiredLabels:
    - "security-scan-passed"
    - "compliance-level=L2"
  # 阻断行为
  onViolation: "block-rollout"  # 可选：block-rollout | warn-only | quarantine

3.5 安全水位与滚动更新节奏的联动

安全水位不仅决定“是否放行”，还影响滚动更新的节奏和策略：

• 水位达标镜像：使用默认的 maxSurge=25%, maxUnavailable=25% 快速滚动。
• 水位临界镜像：（如仅超出中危漏洞数量）降速滚动，设置 maxSurge=10%, maxUnavailable=10%，并触发人工审核。
• 水位超标镜像：完全阻断滚动，回滚到上一个安全版本，并触发安全事件响应流程。

这种联动机制确保了安全水位不仅是“静态检查点”，更是动态风险控制的一部分。

3.6 安全水位的持续演进

安全水位不是一成不变的。随着新漏洞的披露（如 CVE-2024-XXXXX）和业务风险的变化，水位需要定期校准：