管理配置和秘密

1）为什么需要它

配置和秘密是prod平台的"血液"。Config中的错误落在p95中，泄漏的秘密是P1级事件。目的是使config/secret：

可预见（方案，验证，版本）。
安全（加密，最低权限，轮换）。
托管（GitOps，审计，回滚）。
在需要时是动态的（功能标记，极限参数化）。

2）工件分类

公共configs：fichi，急流，taymauts，feature flags（无秘密）。
敏感configs：改变关键路径行为的参数（例如付款限制）。
保密：密码/密钥/令牌/证书/加密材料。
信任工件：根/中间证书、PKI策略、KMS密钥。

分离储存和权利原则：公共≠敏感≠机密。

3）配置层次结构

构造层的"金字塔"：

1.Global defaults (org-wide).

2.Environment (`prod/stage/dev`).

3.Region (`eu-central-1`, `us-east-1`).

4.Tenant/Brand（用于多重性）。

5.服务（特定的微服务）。

6.超时（runtime）-临时开关。

合并规则："低于胜率"，冲突仅通过MR/approval。

示例（YAML）

yaml defaults:
http:
timeout_ms: 800 retry: 2 prod:
http:
timeout_ms: 1200 service: payments-api overrides:
eu-central-1:
http:
timeout_ms: 1500

4）方案和验证

每个config都是计划合同（JSON Schema/OPA/CI中的验证者）。

类型、范围、必填字段、默认值。
"Guard规则"（不能提供"retry> 5"，"p95_target <50 ms"）。
自动验证CI和应用（admission-webhook/KRM）。

JSON Schema片段

json
{
"type":"object",
"properties":{
"http":{"type":"object","properties":{"timeout_ms":{"type":"integer","minimum":100,"maximum":10000},"retry":{"type":"integer","minimum":0,"maximum":5}},"required":["timeout_ms"]},
"feature_flags":{"type":"object","additionalProperties":{"type":"boolean"}}
},
"required":["http"]
}

5）Configs交付模型

静态（image-baked）：可靠但需要重新启动。
Push/Watch： Agent/sidecar接收更新（stream/poll）并向应用程序发出信号。
启动时拉动：开始时我们会得到快照（简化热路径）。
用于地理分布式负载的Edge cache/proxy。

主要是：狙击手的原子和旋转性，兼容性控制和快速回滚。

6）工具和角色

Config存储：Git（真相来源）+GitOps （Argo/Flux）, Parameter Store/Config Service。
秘密存储：Vault、AWS Secrets Manager/SSM、GCP Secrets、Azure KV。
加密：KMS/HSM，SOPS（age/GPG/KMS），Sealed Secrets，Transit加密（Vault）。
交付：CSI Secrets Store, Vault Agent Injector/Sidecar, init容器。
标志/扬声器：幻灯片平台（包括紧急杀手开关）。

7）加密： 模型和实践

在rest： KMS密钥项目/环境,envelope加密。
Transit： TLS/mTLS具有相互验证。
使用：尽可能晚地解密，最好在进程/sidecar内存（不写入磁盘）中解密。
关键层次结构：root（HSM）→ KMS CMK →数据键（DEK）。
轮换：日历（90/180天）+事件（工作人员危害/离职）。

8）秘密管理： 模式

8.1 GitOps+SOPS（静态狙击）

Git仅存储密文。
在CI/CD或群集（KMS/age）上解密。
通过控制器（Flux/Argo）→ Kubernetes Secret应用。

yaml apiVersion: v1 kind: Secret metadata: { name: psp-keys, namespace: payments }
type: Opaque data:
apiKey: ENC[AES256_GCM,data:...,sops]

8.2 Vault Agent Injector（动态发射）

服务帐户（JWT/SA）在Vault中进行了身份验证。
Sidecar将信条放入tmpfs中，并通过TTL进行更新。
动态信用支持（DB, cloud-隔离和短期）。

yaml annotations:
vault. hashicorp. com/agent-inject: "true"
vault. hashicorp. com/role: "payments-api"
vault. hashicorp. com/agent-inject-secret-db: "database/creds/payments"

8.3 CSI Secrets Store

将秘密装载为卷，旋转透明。
对于PKI-自动更新证书/密钥。

9）Kubernetes： 实际方面

ConfigMap仅为公共/不敏感数据。
秘密-敏感（具有base64-非加密；启用Encryption at Rest for etcd）。
Checksum注释：更改config时重新启动部署。
管理控制：禁止从"白名单"中装载秘密,禁止清单中的"平原"密码。
NetworkPolicy：限制对秘密提供商（Vault/CSI）的访问。

Checksum示例（Helm）

yaml annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}

10）访问策略（RBAC/ABAC）

Least特权：该服务仅查看其秘密；通过namespace/label/prefix访问。
Split duties：创建秘密≠阅读内容；审核任何读数。
时间信条：带有TTL和自动旋转的动态登录点（DB，云）。
细分：不同项目/帐户/KMS密钥中的prod/stage。

11）审计，日志，可观察性

阅读/发布秘密的逻辑：谁/何时/何地/何地；与发布和事件的相关性。
指标：通话频率，过期秘密，过期证书，动态积分的比例。
安全事件：配额过高,IP/时间异常,多次不成功身份验证。

12）保密和证书轮换

标准化时间：API密钥为90天,DB密码为30天,TLS Serts为60-90天。
旋转轮廓：生成→测试→双发布（grace） →切换→撤销旧→验证。
无故障性：双重记录configs/secret，客户兼容性（接受new+old）。
PKI：自己的CA或与外部集成；通过CSI/Vault自动更新mTLS材料。

13）动态configs和功能flags

从config服务/标志平台中选择"热"参数（限制，定时器）。
本地缓存和stickiness（按哈希计算变体），TTL短。
SLO保护器更改敏感参数（自动回滚和杀手开关）。

14）与CI/CD和GitOps的集成

Pre-commit/CI：电路linter，SOPS检查，禁止"裸"秘密（扫描仪：gitleaks/trufflehog）。
Policy Gate： OPA/Conftest-禁止在没有方桉的情况下/没有所有者注释/没有环境标签的configs。
渐进式交付：将configs提升为人工制品（semver），canary更改参数。
发布注释：谁/哪个配音/秘密发生了变化；与p95/5xx的快速相关性。

15）示例

15.1 OPA政策：在config中禁止开放SG

rego package policy. config

deny[msg] {
input. kind == "SecurityGroupRule"
input. cidr == "0. 0. 0. 0/0"
input. port = = 5432 msg: = "Postgres open internet banned"
}

15.2 "snapshot" config的示例（可转换）

yaml version: 1. 12. 0 owner: payments-team appliesTo: [ "payments-api@prod" ]
http:
timeout_ms: 1200 retry: 2 withdraw:
limits:
per_txn_eur: 5000 per_day_eur: 20000 flags:
new_withdrawal_flow: false

15.3 Vault-DB动态信条

hcl path "database/creds/payments" {
capabilities = ["read"]
}
role issues user/password with TTL = 1h and auto-rollover

16）反模式

未加密的Helm/Ansible变量中的Git中的秘密。
适用于所有服务/环境的单个"大型秘密"。
没有TTL/旋转的长寿命令牌；"不朽"证书。
动态配对，没有电路/验证或更改审核。
etcd/KMS和没有mTLS的网络在休息时没有加密。
手动编辑商品中的configs（绕过GitOps）。
开发人员访问"以防万一"的程序秘诀。

17）实施清单（0-60天）

0-15天

包括configs的电路/验证器；启动回购"configs"和GitOps流。
提高KMS和加密：SOPS/Sealed Secrets/Encryption at Rest in etcd。
禁止CI（扫描仪）中的Playntext秘密,引入owners/approvals。

16-30天

拆分金库：公众对敏感的vs秘密。
实施Vault/Secrets Manager,选择交付路径（Agent/CSI/SOPS）。
自定义TLS/DB/PSP信条轮换；dashbords"寿命/到期"。

31-60天

带有SLO门控和自动回滚的动态混音和标志。
OPA/Conftest政策；零信任（namespace/label-scoped访问）。
游戏日：模拟秘密泄漏和强力旋转。

18）成熟度量

加密秘密的％，并且从Git=100％不直接访问。
电路/验证的configs覆盖率≥ 95％。
关键秘密的平均轮换时间（目标：小时，不是天）。
动态信用份额（DB/cloud）≥ 80％。
0起涉及"plain secrets"/过期证书的事件。
MTTR在回滚误差为5分钟的情况下。

19）团队角色和流程

Config Owner：域所有者/方桉/策略。
安全：策略，关键层次结构，访问审核。
Platform/SRE：GitOps，供应/注入，遥测。
App Teams：消费配音/秘密,兼容性测试。

20）结论

强大的配置和秘密轮廓是+GitOps+加密+轮换+策略模式。共享公共和秘密,加密一切,以原子方式和可转换的方式应用配音,最大限度地减少信用权限和寿命,自动轮换和审核。然后，变化将变得快速而安全，泄漏和跌落的风险最小。

管理配置和秘密