管理配置和秘密

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+加密+輪換+策略模式。共享公共和秘密,加密一切,以原子方式和可轉換的方式應用配音,最大限度地減少信用權限和壽命,自動輪換和審核。然後，變化將變得快速而安全，泄漏和跌落的風險最小。

管理配置和秘密