秘密管理

秘密管理

1）为什么以及确切地认为是"秘密"

保密-任何导致系统或数据受损的材料：密码，API令牌，OAuth/JWT私人密钥，SSH密钥，证书，加密密钥（KEK/DEK），webhook签名密钥，DSN基地/缓存，供应商密钥（付款，邮件提供商/SMS），Cookie 盐/pepper，机器人/聊天令牌，许可证。
秘密生活在代码，密码，环境，容器图像，CI/CD，Terraform/Ansible，标志/转储中-秘密管理任务：会计→存储→交付→使用→轮换→召回→审计→处置。

2）架构原则

集中化。一个可信任层（Vault/Cloud Secret Manager/KMS）用于存储、发行和审核。
最小特权（PoLP）。仅访问所需的服务/角色,时间最短。
短暂的生活。TTL/lease的动态/时间秘密是首选。
Crypto-agility.无需停机即可更改算法/密钥长度。
将秘密与代码/映像分开。没有存储库中的密码或Docker映像中的密码。
可观察性和审计。每个机密签发/读取操作都是合乎逻辑的，并且会变异。
自动旋转。轮换是管道的过程，不是手动动作。

3）示范决定和组成部分的作用

KMS/HSM.根信任，加密/密钥包装操作（envelope）。
Secret Manager/Vault.秘密版本存储，ACL，审计，动态秘密（DB，Cloud-IAM，PKI），轮换模式。
PKI/CA.签发简短的mTLS/SSH/JWT签名证书。
Agent/sidecar。将秘密传递给rantime （tmpfs文件,in-memory k/v, hot-reload）。
CSI驱动程序/运算符。与Kubernetes（秘密商店CSI驱动程序，证书管理器）集成。
Git中的加密层。SOPS/age，git-crypt（用于基础架构代码）。

4）分类和政策

• TTL/lease和轮换频率；
• 发行方式（动态vs静态），格式，媒体；
• 访问策略（谁/何地/何时/为什么），mTLS要求和相互身份验证；
• 审计（我们计算有多少人保留，是谁）；
• 破玻璃程序和召回。

5）秘密生命周期

1.创建：通过Secret Manager API和元数据（所有者,标签,scope）。
2.存储：以加密形式（envelope：DEK包裹着KMS/HSM的KEK）。
3.交付：应授权实体（OIDC/JWT, SPIFFE/SVID, mTLS）的要求。
4.使用：仅在内存/tmpfs中；禁止编写/转储。
5.轮换：通过TTL或事件（损害）；并行版本支持（N-1）。
6.召回/锁定：立即到期,目标系统上的帐户/密钥的dizabl。
7.处置：销毁版本/材料,清晰的审计链条。

6）动态秘密（默认推荐）

• TTL 15-60分钟的DB凭证（Postgres/MySQL）。
• 按服务角色划分的临时云密钥（AWS/GCP/Azure）。
• SSH证书（5-30分钟），X.509证书（小时/天）。
• 请求签名，会话票券经纪人的临时JWT。
• 优点：最小爆炸辐射,简化的召回（什么都不会留在世界上）。

7）将秘密传递给rantime

Kubernetes:

Secret Store CSI Driver →将秘密从外部管理器装载到pod作为文件（tmpfs）。
避免Kubernetes Secret作为唯一的来源（base64 ≠加密）；如有必要-包括etcd的KMS提供程序。
Sidecar Agent （Vault Agent/Secrets Store）,带有自动升级租赁和热发布。
VM/Bare-metal：系统代理+mTLS到Vault/Secret Manager,内存大小,最小TCB。
Serverless：将云与透明的机密替换作为环境/文件变量进行集成，但避免长寿命的内存-最好是文件/内存。

示例（Kubernetes+CSI,概念上）

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8） CI/CD和IaC集成

CI：用户通过OIDC（工作负载身份）获得短寿命令牌。禁止进入日志的"蒙面"秘密；"泄漏扫描"步骤（trufflehog/gitleaks）。
CD：deploy在发布时拿起秘密，没有将它们写入文物。
IaC：Terraform将变量存储在Secret Manager中；状态（state）被加密并受到访问限制。
SOPS/age：对于回购,存储加密清单,密钥运行KMS。

示例（SOPS片段）

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9）工作负载访问策略和身份验证

Workload identity: SPIFFE/SPIRE, Kubernetes SA→OIDC→IAM-роль, mTLS.

时间令牌：短TTL，狭窄的标语。
Secret Manager中的ABAC/RBAC："谁可以读取Y环境中的X密码"与"谁可以创建/轮换"分开。
多租户：每个租户分别命名/关键戒指；个别政策和报告。

10）轮换，版本和兼容性

共享机密ID及其版本（'secret/app/db#v17'）。
支持两个活动版本（N和N-1）进行不间断的旋转。
事件轮换：解雇，损害，提供商变更，算法迁移。
自动化：Vault/Secret Manager+webhook 应用程序重启/reneval触发器中的cron/旋转后端。

迷你配方"双舱"webhook轮换

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11） Rantime外存储： 备份和工件

永远不要进入文物（图像，登录档案，转储物）。
Secret Manager备份-加密，存储密钥超出同一轮廓（separation of duties）。
标签和DLP扫描：检测S3/Blob/GCS、Git、CI工件中的秘密。

12）可观察性、审计和SLO

度量标准：发出/保密/服务次数、过期租赁比例、平均TTL、轮换时间、收敛时间（新版本"采用"之前的秒/分钟）。
审计记录：谁/什么/何时/何地/为什么；单独存储，也是加密的。
SLO：99%的<200毫秒；0个日志泄漏；100％ 的秘密具有所有者/TTL/标签；100%的关键秘密是30天≤动态或轮换。
Alerts：密码到期<7天（对于静态）、对存储的身份验证失败激增、没有秘密读取>N天（死）、意想不到的地理/ASN来源。

13）频繁的错误以及如何避免错误

Git/图像中的秘密。使用SOPS/age和扫描仪；禁止裸线的政策。
Envvars作为一种持久的媒介。偏爱tmpfs/in-memory文件；用叉子/转储清洁周围环境。
dev/stage/prod的相同秘密。按周围环境划分。
长寿命静态密码。过渡到动态/短暂生命。
单个主键"全部"。按租户/项目/服务划分。
没有热播。该应用程序要求在旋转时重新启动→漏洞窗口。

14）积分示例（示意图）

Vault动态访问Postgres

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

查询的JWT签名（短时间）

私钥存储在Secret Manager中；该服务请求简短的签名令牌和本地代理签名payload（密钥不会作为字符串传输到应用程序）。

Admins的SSH证书

通过SSO（OIDC）发出10分钟的SSH证书，而无需分发永久密钥。

15）边缘安全

Logi/Traces/度量：消毒剂，已知密钥/模式的过滤器；"秘密"字段-在APM中掩盖。
转储/碰撞报告：默认切断；如果需要-加密和清洁。
客户端应用程序/移动：最大限度地减少离线秘密,使用平台存储（Keychain/Keystore）,绑定设备,TLS-pinning和紧急启动。

16）合规性

PCI DSS：禁止非加密存储PAN/保密；严格控制出入和轮换。
ISO 27001/SOC 2：资产管理，日志，访问控制，配置更改的要求。
GDPR/本地监管机构：最小化，按需访问，审核。

17）流程和运行手册

调试

1.秘密清单（存储库，CI，图像，运行时，备份）。
2.分类和标签（所有者，环境，tenant，rotation-policy）。
3.存储选择（Vault/Cloud SM）+与KMS/HSM集成。
4.设置工作负载身份签发（OIDC/SPIRE）。
5.包括DB/云/PKI的动态秘密。
6.自动旋转和热放置；演示中的异常。
7.设置泄漏扫描仪和数据目录/DS。

紧急情况

怀疑泄漏：访问停止列表，立即轮换，召回证书/密码，超额发行令牌，包括高级审计，RCA。
无法使用Secret Manager：小型TTL内存中的本地Kesh、功能降级、限制新连接、手动断面步骤。
Root Key Credit： key-hierarchy再生,rewrap所有DEK,检查风险窗口的所有签名。

18）支票单

出售前

• 从代码/映像中删除秘密；包括泄漏扫描仪。
• 对于关键秘密，包括动态机制。
• 通过sidecar/CSI/tmpfs交付,带有热插拔,没有持久的envvvars。
• 配置了IAM/ABAC策略,绑定到工作负载身份。
• 自动旋转和双版本（N, N-1）以实现兼容性。
• 包括度量/Alerta/审计；退化测试已经通过。

运营

• 月度报告：业主，TTL，过期秘密，未使用。
• 周期性旋转和泄漏路径（日志、转储、人工制品）五角形。
• crypto-agility计划和紧急更换SA/根。

19) FAQ

问： 没有KMS的Secret Manager是否足够?

答：对于基层-是的，但最好使用envelope加密：KMS/HSM中的KEK，秘密包裹。这简化了召回和合规性。

问：选择什么-静态或动态？
答：默认情况下为扬声器。静态仅在没有支持提供商的情况下离开,并烧毁TTL直到数天/数小时+自动旋转。

问：如何安全地将秘密注入微服务？
О: Workload identity → mTLS к Secret Manager → sidecar/CSI → файлы в tmpfs + hot-reload.没有巢穴，没有envvvars"永远"。

问：可以在Kubernetes Secret中存储秘密吗？
答：仅在启用与KMS提供商和严格策略的etcd加密时。更喜欢外部存储和CSI。

问：如何"加密擦除"租户通道？
答：撤回/阻止Secret Manager的策略,使所有泄漏、密钥轮换/再生失效；使用KMS时,禁用相应的KEK的unwrap。

• "At Rest加密"
• "In Transit加密"
• "密钥管理和旋转"
• "S2S认证"
• "；请求的签字和核实"；