秘密管理

秘密管理

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認證」
• "；請求的簽字和核實"；