密钥管理与供应链安全：从 Vault 到 SBOM 的零信任实践

典型泄露路径：硬编码 DB 密码 → 仓库泄露 → 拖库
              .env 提交进 Git → 历史记录永久存在 → 反复泄露
              镜像里 baked 进密钥 → 推到公共 Registry → 全公开
本质：密钥一旦泄露，谁都能冒充你的服务访问数据
  所以"写入"一侧严防、"使用"一侧隔离、"审计"一侧追踪

第一层 防写入：禁止密钥进 Git / 镜像 / 日志（Secrets Scanning）
第二层 防滥用：运行时最小权限注入，泄露了也用不了多久（动态密钥）
第三层 防扩散：零信任——密钥访问要身份验证、授权、审计

小团队/单体：环境变量 + 加密存储（够用）
K8s 平台：Secrets Store CSI + 云 KMS（省心）
多环境/强审计：HashiCorp Vault（动态密钥是杀手锏）
混合云/多云：Vault 做统一抽象层，后端接各云 KMS

# 误区一：以为 K8s Secret 是加密的
apiVersion: v1
kind: Secret
metadata: { name: db-credentials }
type: Opaque
data:
  password: c3VwZXItc2VjcmV0  # base64 不是加密！
---
# 误区二：把 Secret 当备份库（etcd 里明文可读）
# 正确姿势：Secret 只做"传输中介"，明文放在外部 KMS/Vault
# 关键认知：任何人能读 etcd / 有 RBAC 权限就能看明文
# → 生产务必开启 etcd 加密（EncryptionConfiguration）或直接用 CSI/Vault

Vault 的关键部件：
  - Seal/Unseal：数据加密密钥由主密钥保护，启动需 Unseal
  - Secrets Engine：KVv2（静态）、database（动态）、aws/pki 等
  - Auth Method：token、kubernetes、approle、OIDC 等认证方式
  - Policy：HCL 编写的权限策略，决定"谁能读哪个路径"
  - Audit Device：把每次访问写入审计日志（file/syslog/socket）

# 启用 KVv2 引擎
vault secrets enable -path=secret kv-v2

# 写入 / 读取（带版本）
vault kv put secret/shop/db username=admin password=SuperS3cret!
vault kv get secret/shop/db
vault kv metadata get secret/shop/db   # 看版本历史

# 版本回滚
vault kv rollback -version=2 secret/shop/db

# 配置数据库引擎 + 角色（角色定义授权的最小权限 + 默认/最大 TTL）
vault secrets enable database
vault write database/config/shop-postgres \
  plugin_name=postgresql-database-plugin \
  connection_url="postgresql://{{username}}:{{password}}@pg:5432/shop?sslmode=verify-full" \
  allowed_roles="shop-readonly"
vault write database/roles/shop-readonly \
  db_name=shop-postgres \
  creation_statements="CREATE ROLE \"{{name}}\" LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" max_ttl="24h"

# 应用拿到的动态密码 1 小时后自动失效 → 泄露窗口大大缩短

# vault-policy.hcl：只允许读 shop 应用的 DB 动态密钥
path "database/creds/shop-readonly" { capabilities = ["read"] }
path "secret/data/shop/*" { capabilities = ["read"] }

vault policy write shop-app shop.hcl
# 与 Kubernetes Auth 绑定：serviceaccount=shop 的 Pod 才给这个 Policy

生命周期：生成 → 分发 → 使用 → 轮换 → 撤销 → 归档（定期/事件触发循环）

轮换触发条件：
  - 定期：高敏密钥 30/60 天，普通密钥 90 天
  - 事件：疑似泄露、员工离职、合规审计要求
  - 动态密钥：自动轮换（TTL 到期即失效，无需人工）

轮换要点：先写新值、再切引用、后删旧值（双写窗口）
  数据库密码轮换"先建新账号，验证后切流量，最后删旧账号"，要有失败回滚预案

{
  "time": "2026-09-27T09:30:12.334Z",
  "type": "response",
  "auth": { "policies": ["shop-app"], "metadata": { "serviceaccount": "shop" } },
  "request": { "path": "database/creds/shop-readonly", "operation": "read" }
}

审计价值：谁、何时、读了哪个密钥 → 出事可追溯
  异常频率（同一 SA 疯狂取密钥）→ 疑似滥用告警；接 SIEM 做关联分析

GitOps"一切进 Git"与"密钥不能进 Git"的矛盾：
  ArgoCD 拉取 manifests → 塞明文密码就是灾难
  解法：加密文件进 Git，解密发生在"需要时"

SOPS（Mozilla SOPS）是事实标准：
  只加密 value 保留 YAML 结构（diff 友好），密钥来自 age 或云 KMS

# 生成 age 密钥并配置 .sops.yaml
age-keygen -o ~/.config/sops/age/keys.txt
#   .sops.yaml 指定加密字段与公钥：
#   creation_rules:
#     - path_regex: secrets\.yaml$
#       encrypted_regex: "^(password|apiKey|token)$"
#       age: age1qy...publickey

# 加密 / 解密 / 原地改某个字段
sops -e secrets.yaml > secrets.enc.yaml
sops -d secrets.enc.yaml
sops --set '["password"] "new-pass"' secrets.enc.yaml

# 方案一：kustomize secretGenerator + sops 插件
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
secretGenerator:
  - name: shop-secrets
    files: [secrets.enc.yaml]
---
# 方案二：argocd sops 解密插件 / Sealed Secrets / External Secrets Operator

# External Secrets Operator：Git 里只声明"要哪些密钥"
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata: { name: shop-db }
spec:
  secretStoreRef: { name: vault-store, kind: SecretStore }
  target: { name: shop-db-secret }
  data:
    - secretKey: password
      remoteRef: { key: secret/shop/db, property: password }

  - 依赖投毒：npm/pypi 包被替换，装到生产就中招
  - 镜像污染：公共 Registry 同名镜像被推送恶意层
  - 构建链污染：CI 服务器被黑，产出镜像被改

对策三板斧：SBOM（知道用了什么）+ 签名（cosign 验证没被改）+ 扫描（Trivy/Grype 找漏洞）

# syft 生成 SPDX 格式 SBOM
syft packages registry:shop/api:v1.2.3 -o spdx-json > sbom.json
# trivy 也能直接生成 CycloneDX
trivy image --format cyclonedx --output sbom.cdx.json registry:shop/api:v1.2.3

# cosign 签名（keyless 走 GitHub OIDC + 公钥透明度）
cosign sign --key cosign.key registry:shop/api:v1.2.3
cosign sign --yes ghcr.io/shop/api@sha256:abc123...

# 部署前验证签名 + 校验 SBOM 绑定
cosign verify --key cosign.pub registry:shop/api:v1.2.3
cosign verify-attestation --type spdxjson --key cosign.pub registry:shop/api:v1.2.3

# GitHub Actions 片段：扫描 + 门禁
- name: Scan image
  uses: aquasecurity/trivy-action@0.24.0
  with:
    image-ref: registry:5000/shop/api:${GITHUB_SHA}
    severity: CRITICAL,HIGH
    exit-code: '1'          # 有 CRITICAL/HIGH 漏洞就失败
    ignore-unfixed: true    # 没有修复版本的不算（避免卡死）

门禁策略：CRITICAL → 阻塞；HIGH 有修复版 → 阻塞，无修复版 → 风险接受放行
  新引入漏洞（相对基线）→ 一律阻塞

  - 永不信任，始终验证：每个访问都要认证（不再有"内网就安全"）
  - 最小权限：只给"完成工作"所需的最小密钥范围
  - 假设受损：密钥可能泄露，所以要动态、短期、审计

# Vault K8s Auth：Pod 用 ServiceAccount JWT 换 Vault Token
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      serviceAccountName: shop
      containers:
        - name: api
          image: shop/api:latest
        - name: vault-agent            # sidecar 自动取密钥渲染到文件
          image: hashicorp/vault:1.17.0
          args: ["agent", "-config=/etc/vault/agent.hcl"]

# agent.hcl：vault-agent 渲染密钥到 /vault/secrets/db.txt
vault { address = "https://vault.internal:8200" }
template {
  contents = "{{ with secret \"database/creds/shop-readonly\" }}password={{ .Data.password }}{{ end }}"
  destination = "/vault/secrets/db"
}

  - Vault 只暴露给受信网段（不在公网，或加 mTLS）
  - Pod 用 NetworkPolicy 限制只能访问 Vault 的 8200
  - 云 KMS 用 IAM 绑定服务身份，禁止开放全量权限
  - 审计设备独立存储，防止被"先删日志再作案"

# 本地扫描
gitleaks detect --source . --report-format json --report-path leaks.json
# CI 门禁：任何 commit 里有密钥 → 合并失败
gitleaks protect --staged --verbose

  - SOC 2：加密存储 + 轮换策略 + 审计日志留存
  - ISO 27001：访问控制（A.9）+ 密钥管理（A.10）
  - PCI-DSS：持卡人数据密钥强加密 + 定期轮换
  - 审计最看重：密钥不进日志/代码、轮换可证明、访问可追溯

□ 密钥禁止硬编码 / 进 Git / 进镜像 / 进日志
□ Gitleaks 进 pre-commit 与 CI 门禁；K8s Secret 只做传输中介 + etcd 加密
□ 生产密钥统一走 Vault / Secrets Store CSI / 云 KMS
□ Vault 动态密钥缩短泄露窗口；Policy 最小权限 + K8s Auth 绑定 SA
□ 轮换策略（定期 + 事件触发）并有回滚预案
□ GitOps 仓库用 SOPS 加密或 External Secrets 引用
□ 镜像构建：SBOM + cosign 签名 + Trivy/Grype 扫描
□ 全量审计日志 + 接 SIEM，异常取密钥行为告警

密钥管理 + 供应链安全 = "让密钥活得短、藏得深、看得见"，
让"别人写的代码"成为你唯一敢信任的代码。