疯狂的SRE

深色模式

敏感配置泄露防护 ​

摘要：本文面向安全与平台团队，系统化讲解 K8s 敏感配置（Secret/凭据/密钥）的泄露面与纵深防御：RBAC 最小权限、API 审计、etcd 静态加密、镜像与清单扫描（Trivy）、准入控制（Kyverno）、外部密钥源与 GitOps 实践。覆盖版本：Kubernetes v1.28+。

适用版本与前提 ​

  • Kubernetes：v1.28+（RBAC、审计策略、EncryptionConfiguration 均 GA/稳定）
  • 工具：kubectl、etcdctl、Trivy、Kyverno/kube-bench
  • 前提：具备集群管理员权限，已启用 RBAC 与审计

背景与问题 ​

官方文档点明两类核心泄露面：

  1. etcd / API 层：Secret 默认明文存 etcd，任何有 API 或 etcd 访问权者可读取。
  2. 权限放大层：能创建 Pod 的人即可读取同命名空间任意 Secret——包括通过 Deployment 间接创建。

此外，密钥还会经镜像层、Git 仓库、日志、错误响应外泄。防护必须是纵深（defense-in-depth），单层必漏。

一、RBAC 最小权限 ​

官方“Good practices for Kubernetes Secrets”强调：限制对 Secret 的 watch/list 仅授予最高特权系统组件；人类应限制 get/watch/list，仅集群管理员可读 etcd。

权限放大陷阱

授予某主体对某命名空间的 Secret list 权限，等于允许其抓取所有 Secret 内容。且能创建 Pod 的主体即可读取该命名空间任意 Secret——即便策略禁止其直接读 Secret，也可用 Pod 把 Secret 暴露出来。务必限制能创建 Pod/Deployment 的主体范围。

实践要点：

  • 用独立命名空间隔离不同应用的 Secret，缩小爆炸半径。
  • 用 kubectl auth can-i --as <sa> list secrets -n <ns> 定期核查多余权限。
  • 对特权组件（如 CI/CD SA）单独评估，避免 cluster-admin 泛滥。

二、API 审计 ​

开启 apiserver 审计策略，对 Secret 的 get/list/watch 重点记录，并对异常（单用户并发读取多 Secret）告警。基础策略片段：

yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    verbs: ["get", "list", "watch"]
  - level: Metadata
    resources:
      - group: ""        # 其余资源仅记元数据
        resources: ["pods", "deployments"]

审计运营

配合官方建议：用短期 Secret、对“单用户并发读取多 Secret”等事件设审计告警，及早发现横向移动。

三、etcd 静态加密（KMS） ​

Secret 明文存 etcd 是默认风险。必须启用静态加密，且生产用 KMS v2 把根密钥置于集群外（详见本站《Secret 管理与 KMS 加密》）。校验：etcdctl get 取值应以 k8s:enc:kms:v2: 开头。etcd 退役存储应擦除/粉碎。

加密不防权限

静态加密只防 etcd 落盘泄露，不防 API 权限过大与 Pod 创建权滥用——必须叠加 RBAC 与审计。

四、镜像与 IaC 扫描（Trivy） ​

Trivy（Aqua，Apache 2.0）覆盖镜像 CVE、密钥（secrets）、SBOM 与 IaC 误配置，可接入 CI、准入控制器、IDE。其 k8s 子命令还能扫运行集群的清单与配置漂移。

CI 门禁示例（GitHub Actions）：

yaml
- name: Run Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'my-app:${{ github.sha }}'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'      # 发现高危即阻断构建
    ignore-unfixed: true

多层互补

Trivy、kube-bench、Trivy Operator 互不替代：CI 镜像扫描拦不住 kubectl edit 直改的清单；kube-bench 查不了运行负载的新 CVE。需同时运行（详见本站镜像扫描/合规篇 TODO(verify)）。

建议节奏：CI 每次 PR/构建扫描；集群与 kube-bench 按日/周排程；对 CRITICAL/HIGH 超 14 天未修复设趋势指标。

五、准入控制拦截 ​

CI 可被有 kubectl apply 权限者绕过。需在集群侧用 Kyverno / OPA Gatekeeper 校验：阻断含明文 Secret 的清单、强制镜像来自可信仓库、要求 Pod 不挂载 hostPath 等。

yaml
# Kyverno 示例：禁止清单中出现明文 Secret（仅示意，实际需配合外部密钥引用）
# 详见 Kyverno 官方策略库

双保险

Trivy 在 CI 做准入前扫描 + Kyverno 在集群做准入时校验，是“腰带加背带”而非冗余——因为 CI 总能被直连 apiserver 绕过。

六、GitOps 与外部密钥源 ​

把密钥提交进 Git 是最常见的泄露源。正确做法：

  • 机密不进 Git；用 External Secrets Operator 把引用（ExternalSecret）入库，真实值留外部后端（见本站《External Secrets Operator》）。
  • 若必须加密入库，用 Sealed Secrets / SOPS，且私钥/密钥仅留集群或 KMS。
  • 对镜像与 Helm Chart 也跑 Trivy 扫描，防止依赖链与 IaC 误配置入库。

故障排查与应急 ​

现象可能根因处置
etcd 备份含明文 Secret未启用静态加密立即启用 KMS，重写存量，轮换已泄露凭据
某人读走大量 SecretRBAC 过宽 / Pod 创建权滥用收紧 RBAC，查审计定位，轮换密钥
镜像里发现密钥构建把密钥打进层从镜像删密钥，扫历史，轮换
直连 apply 绕过 CI缺准入控制加 Kyverno 策略，限制 apply 权限
bash
# 紧急轮换：列出某命名空间可读取 Secret 的主体，核查并收回
kubectl auth can-i list secrets --as=system:serviceaccount:ci:default -n production
# 确认 etcd 中已加密
ETCDCTL_API=3 etcdctl get /registry/secrets/default/my-secret \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

泄露后第一动作

确认凭据泄露后，优先轮换密钥（改外部后端值或 KMS 密钥），再排查路径。仅删 Secret 不轮换，旧值仍可能已被复制。

安全与合规权衡 ​

  • 加密、扫描、审计都增加延迟与运维成本；CI 严格门禁可能拖慢交付，需按风险分级（CRITICAL 阻断、MEDIUM 周审）。
  • 准入控制过严会误伤正常部署，策略需先在 audit 模式试运行。
  • 所有防护均不替代“密钥定期轮换”与“最小权限”的根本原则。

替代方案与权衡 ​

  • 外部密钥 + CSI Driver：密钥不落原生 Secret，进一步缩小 apiserver 暴露面。
  • 机密计算 / KMS 信封：更高保证但更复杂。
  • 商业方案（Snyk、Prisma）：集中看板，适合强合规，但引入厂商锁定。

FAQ ​

Q：启用审计会拖慢 apiserver 吗？ RequestResponse 级对 Secret 写盘量大，建议仅对 Secret 资源用该级、其余用 Metadata。[未实测]具体开销取决于审计后端吞吐。

Q：kube-bench 能替 Trivy 吗？ 不能。kube-bench 查控制面/节点 CIS 合规；Trivy 查工作负载 CVE 与清单误配置，二者互补。

参考资料 ​

基于 VitePress 构建 · 托管于阿里云 ECS

Copyright © 2026 CrazySRE