12.1. 策略、密钥与供应链安全

Kubernetes 的安全不是「装一个安全组件」，而是一条从镜像构建到准入的链路：镜像是否可信、密钥是否泄漏、Pod 是否越权、运行时是否被攻破。这一章把策略即代码、密钥管理、供应链与运行时安全放在同一条链路上。

层级:

L3 · 平台

难度:

进阶

预计:

55 分钟

前置:

RBAC、Pod Security、镜像基础

12.1.1. 策略即代码

工具

模型

特点

Pod Security Admission

内置、命名空间标签

最简单，覆盖基线/受限

Kyverno

YAML 策略、无 Rego

易读，支持 mutate/validate/generate

OPA Gatekeeper

Rego + ConstraintTemplate

表达力强，学习曲线陡

Kubescape

扫描与合规

适合基线评估与 CI

先启用 PSA 的 baseline/restricted，再用 Kyverno/Gatekeeper 补组织策略。策略要进 Git、要测试、要有豁免流程；否则会被“临时放行”绕过。

kyverno-disallow-latest.yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "镜像必须使用明确 tag，禁止 latest"
        pattern:
          spec:
            containers:
              - image: "!*:latest"

kubectl apply -f kyverno-disallow-latest.yaml
kubectl run bad --image=nginx:latest

validationFailureAction: Audit 用于观察，Enforce 才会拒绝。上线前先用 Audit 跑一周，确认没有误伤。

12.1.2. 密钥管理

方案

密钥存放

适合

Kubernetes Secret

etcd

简单场景，需开启静态加密

Sealed Secrets

Git 中的加密 Secret

GitOps，无外部依赖

External Secrets Operator

外部 Vault/云 Secrets

多集群、集中管理

Vault + CSI/Agent

Vault

强审计、动态凭证

SOPS

Git 中的加密文件

轻量、与 Helm/Kustomize 集成
external-secret.yaml
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: https://vault.example.com
      path: kv
      auth:
        tokenSecretRef:
          name: vault-token
          key: token
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: demoapp-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: demoapp-secret
  data:
    - secretKey: password
      remoteRef:
        key: demoapp
        property: password

密钥不要进 Git；必须进 Git 时用 Sealed Secrets/SOPS。所有 Secret 都要有轮换策略，避免“一次泄漏、永久有效”。

12.1.3. 供应链：扫描、签名、准入

trivy image ghcr.io/example/demoapp:v1.0
cosign sign --key cosign.key ghcr.io/example/demoapp:v1.0
cosign verify --key cosign.pub ghcr.io/example/demoapp:v1.0

推荐链路：

  1. CI 构建镜像 → Trivy/Grype 扫描；

  2. 生成 SBOM（Syft）→ Cosign 签名；

  3. 推送镜像仓库（Harbor）→ 记录 digest；

  4. 准入控制器校验签名与漏洞阈值；

  5. 部署时使用 digest，而不是可变 tag。

SLSA 等级不是目的；先做到「可追溯、可验证、不可抵赖」。

12.1.4. 运行时安全

  • Falco：基于 eBPF/内核事件检测异常进程、文件、网络行为。

  • Tetragon：Cilium 生态的 eBPF 安全观测与阻断。

  • AppArmor/SELinux：节点级强制访问控制。

  • NetworkPolicy：限制横向移动。

  • 只读根文件系统、非 root、drop capabilities：降低逃逸后的影响。

Falco 的告警需要落到 Slack/PagerDuty，并定期调参；否则会变成“告警疲劳”。

12.1.5. 验证清单

  • 命名空间启用 PSA，违规 Pod 被拒绝。

  • Kyverno/Gatekeeper 至少一条 Enforce 策略生效。

  • Secret 不进 Git，外部密钥能自动同步/轮换。

  • 镜像扫描、签名、准入校验链路可演示。

  • Falco/Tetragon 能捕获一次异常 exec 或文件写入。

  • 所有工作负载非 root、只读根文件系统、drop ALL。

12.1.6. 排错表

现象

原因

处理

Pod 被策略拒绝

策略 Enforce / 镜像 tag 不合规

看事件中的 policy 名称，修镜像或加豁免

ESO 不同步

Vault 地址/Token/权限错误

看 ExternalSecret 状态与 ESO 日志

签名校验失败

镜像 digest 变了 / 公钥不对

用 digest 部署，核对 cosign.pub

Falco 没告警

驱动/规则未加载

检查 DaemonSet 与 falcoctl

Secret 仍可读

RBAC 过宽 / etcd 未加密

最小权限、开启 encryption at rest

12.1.7. 进阶挑战

  1. 用 Kyverno 要求所有 Pod 设置 requests/limits，并先 Audit 一周。

  2. 用 Sealed Secrets 把一个 Secret 安全地放进 Git。

  3. 用 Cosign 签名并在准入阶段校验，拒绝未签名镜像。

  4. 用 Falco 捕获一次容器内 curl 外联，并接入告警。

12.1.8. 小结

  • 安全是分层防御：身份、准入、密钥、供应链、运行时缺一不可。

  • 策略要进 Git、先 Audit 后 Enforce、有豁免流程。

  • 密钥尽量不落 etcd；必须落时开启静态加密与轮换。

  • 供应链安全的最小闭环是「扫描 + 签名 + 准入校验」。

12.1.9. 延伸阅读