4. 镜像安全基线:CIS Docker Benchmark、K8s Pod安全标准(PSP/PSS)、镜像最小化原则

在多集群K8s环境中,镜像安全基线是供应链安全的第一道防线。本章围绕三个核心维度展开:CIS Docker Benchmark(主机与守护进程级基线)、K8s Pod安全标准(PSP/PSS,集群级准入控制)、镜像最小化原则(构建与运行时精简)。三者形成从构建到运行时的完整安全水位闭环。

巡检要点: 镜像安全基线不是一次性配置,而是需要持续巡检的“水位线”。在多集群场景下,不同集群可能采用不同版本的K8s(如1.21之前使用PSP,之后迁移至PSS),基线策略必须统一管理。
镜像安全基线三层防御架构 层1:CIS Docker Benchmark(主机与守护进程) 守护进程配置 · 文件权限 · 网络隔离 · 日志审计 · 资源限制 巡检项:/etc/docker/daemon.json · docker info · 非root运行 · TLS认证 层2:K8s Pod安全标准(PSP / PSS) PodSecurityPolicy(1.21前) · Pod Security Standards(1.23+) Privileged · Baseline · Restricted 三级策略 · 准入控制器拦截 层3:镜像最小化原则(构建与运行时) Distroless · Alpine · 多阶段构建 · 移除调试工具与包管理器 CVE扫描 · 非root用户 · 只读文件系统 · 签名验证 三层叠加:主机安全 → 准入控制 → 镜像精简,形成纵深防御

4.1 CIS Docker Benchmark:主机级安全基线

CIS(Center for Internet Security)Docker Benchmark 是业界公认的容器主机安全配置标准,覆盖 Docker 守护进程、主机文件权限、网络配置、日志审计等 100+ 检查项。在多集群场景下,每个集群节点都必须通过该基线巡检。

检查类别 关键检查项 合规要求 巡检命令
守护进程配置 --icc=false, --live-restore, --userland-proxy=false 禁止容器间默认通信,启用存活恢复 docker info | grep -E "ICC|Live Restore"
文件权限 /etc/docker/daemon.json, docker.sock, 证书文件 属主 root:root,权限 644 或 600 stat -c "%a %U:%G" /etc/docker/daemon.json
网络隔离 iptables 规则, 默认 bridge 网络, 主机网络模式 禁止使用 --net=host,限制暴露端口 docker network ls; iptables -L -n
日志审计 docker 日志驱动, 审计规则, 容器日志轮转 启用 json-file 或 journald,设置 max-size docker info | grep "Logging Driver"
资源限制 --memory, --cpu-shares, --pids-limit 所有容器必须设置资源上限 docker inspect --format='{{.HostConfig.Memory}}'
多集群巡检脚本片段(CIS Docker Benchmark):
#!/bin/bash
# 多集群节点CIS Docker Benchmark巡检
CLUSTERS=("cluster-a" "cluster-b" "cluster-c")
for cluster in "${CLUSTERS[@]}"; do
  echo "=== 巡检集群: $cluster ==="
  kubectl get nodes --context="$cluster" -o name | while read node; do
    echo "节点: $node"
    # 检查守护进程配置
    kubectl node-shell "$node" -- docker info | grep -E "ICC|Live Restore|Logging Driver"
    # 检查文件权限
    kubectl node-shell "$node" -- stat -c "%a %U:%G" /etc/docker/daemon.json
    # 检查网络模式
    kubectl node-shell "$node" -- docker ps --filter "network=host" -q | wc -l
  done
done

4.2 K8s Pod安全标准:PSP 与 PSS 的演进与落地

K8s 的 Pod 安全策略经历了从 PodSecurityPolicy (PSP) 到 Pod Security Standards (PSS) 的重大演进。PSP 在 1.21 版本被弃用,1.25 版本彻底移除,取而代之的是内置的 PSS 准入控制器。多集群环境中,不同版本集群可能同时存在,需要统一管理策略。

特性 PodSecurityPolicy (PSP) Pod Security Standards (PSS)
引入版本 1.10 (beta) 1.23 (alpha) → 1.25 (stable)
策略模型 CRD + Admission Webhook 内置准入控制器 + 标签选择
策略级别 自定义策略(复杂、易出错) Privileged / Baseline / Restricted 三级
命名空间绑定 通过 RBAC 绑定 ServiceAccount 通过命名空间标签 pod-security.kubernetes.io/enforce
审计模式 仅 enforce(强制) enforce / audit / warn 三种模式
迁移难度 高(需自定义策略) 低(三级策略开箱即用)
多集群迁移警告: 如果集群中同时存在 1.21 之前的 PSP 和 1.23+ 的 PSS,务必确保 PSP 先迁移至 PSS,避免策略冲突导致 Pod 创建失败。建议使用 kubectl convert 工具将 PSP 规则转换为 PSS 标签。
PSP → PSS 迁移流程(多集群统一策略) 阶段1:审计现有PSP kubectl get psp -A 提取privileged/baseline/restricted 阶段2:映射PSS标签 命名空间打标签 pod-security.kubernetes.io/enforce=baseline 阶段3:audit模式验证 先设为audit/warn 观察违规Pod,调整策略 阶段4:enforce强制 切换为enforce模式 阻止不合规Pod创建 阶段5:清理PSP 确认所有命名空间已迁移 kubectl delete psp --all 多集群建议:统一使用PSS标签模板,通过GitOps管理命名空间标签 避免每个集群手动配置,减少策略漂移

4.3 镜像最小化原则:从构建到运行时的精简策略

镜像最小化是降低攻击面的核心手段。每个不必要的包、工具或文件都可能成为漏洞载体。最小化原则贯穿镜像构建、存储和运行三个阶段。

4.3.1 构建阶段:多阶段构建与基础镜像选择

  • 基础镜像选择: 优先使用 scratch、alpine、distroless 等最小化镜像。避免使用 ubuntu:latest 或 centos:latest 等通用发行版。
  • 多阶段构建: 第一阶段使用完整工具链编译,第二阶段仅复制编译产物和运行时依赖。
  • 移除包管理器: 最终镜像中不应包含 apt、yum、apk 等包管理器,防止运行时安装恶意软件。
  • 非root用户: 在 Dockerfile 中创建专用用户,避免以 root 运行。
最小化 Dockerfile 示例(Go应用):
# 第一阶段:编译
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /app/server

# 第二阶段:运行(使用scratch)
FROM scratch
COPY --from=builder /app/server /server
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
USER 1001:1001
EXPOSE 8080
ENTRYPOINT ["/server"]

4.3.2 运行时阶段:只读文件系统与安全上下文

安全配置项 K8s Pod Spec 配置 说明
只读根文件系统 securityContext.readOnlyRootFilesystem: true 禁止容器内写文件系统,防止恶意写入
非root用户 securityContext.runAsUser: 1001 避免容器以 root 权限运行
禁止特权提升 securityContext.allowPrivilegeEscalation: false 防止通过 setuid 等方式提权
Capabilities 裁剪 securityContext.capabilities.drop: ["ALL"] 移除所有 Linux Capability,按需添加
Seccomp 配置 securityContext.seccompProfile.type: RuntimeDefault 限制系统调用,减少攻击面

4.3.3 镜像大小对比与CVE影响

基础镜像 镜像大小 已知CVE数量(2024年) 适用场景
scratch 0 MB 0 静态编译二进制(Go/Rust)
alpine:3.19 ~5 MB ~10 通用轻量应用
distroless:static ~2 MB ~2 需要 glibc 的静态应用
ubuntu:22.04 ~77 MB ~200+ 不推荐用于生产容器
多集群镜像巡检建议: 使用 trivy image --severity HIGH,CRITICAL 对所有集群的镜像进行定期扫描。将镜像大小和CVE数量作为安全水位指标,纳入CI/CD门禁。对于超过 500MB 或存在 CRITICAL CVE 的镜像,禁止部署到生产集群。

4.4 安全水位巡检清单(多集群版)

以下清单可作为多集群镜像安全基线巡检的标准化检查项,每个集群独立执行,结果汇总至统一仪表盘。

检查项 检查对象 合规标准 巡检频率
CIS Docker Benchmark 通过率 每个集群节点 ≥ 90% 检查项通过 每日
PSS 策略覆盖率 所有命名空间 100% 命名空间已打 enforce 标签 每次部署
镜像基础镜像合规 所有运行中的 Pod 禁止使用 ubuntu/centos 等通用镜像 每周
镜像CVE扫描 镜像仓库 + 运行中镜像 0 个 CRITICAL CVE,HIGH CVE ≤ 5 每次推送 + 每日
非root用户运行 所有 Pod 100% Pod 设置 runAsUser ≠ 0 每次部署
只读文件系统 所有 Pod ≥ 90% Pod 启用 readOnlyRootFilesystem 每周
容量瓶颈关联提示: 镜像最小化不仅提升安全性,还能显著降低镜像拉取时间和存储占用。在多集群场景下,过大的镜像会导致节点磁盘压力、镜像拉取超时、Pod启动延迟,进而引发集群容量瓶颈。安全巡检与容量巡检应联动分析。