Alertmanager ExternalSecret

概念概覽

方案架構

核心知識

方案架構

Terraform 產生密碼
    → 直接寫入 AWS Secrets Manager / SSM Parameter Store
    → ExternalSecret CR 同步到 k8s Secret
    → Alertmanager Helm chart 使用 useExistingSecret 掛載

整個路徑上**沒有人類經手密碼**，是業界安全做法。

ExternalSecret 配置要點

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: alertmanager-secret
  namespace: monitoring
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: alertmanager-secret  # 產生的 k8s Secret 名稱
  data:
    - secretKey: alertmanager.yaml
      remoteRef:
        key: /monitoring/alertmanager-config

# Alertmanager Helm values
alertmanager:
  useExistingSecret: true
  secretName: alertmanager-secret

與其他方案的比較

方案	優點	缺點
ExternalSecret + AWS SM	rotation 方便，零人工接觸	依賴 AWS，成本略高
Sealed Secrets	純 k8s，無雲端依賴	需管理加密金鑰，rotation 較複雜
Hardcode in git	簡單	嚴重安全風險，不可用於生產
人工 kubectl apply	靈活	無法審計，rotation 容易遺漏

經驗教訓

• Terraform 管理的 Secret 安全性高：密碼由 Terraform 產生並直接寫入 AWS SSM，整個路徑沒有人類經手

• 部署後要演練 test alert 驗收，確認 Alertmanager 真的能透過同步來的憑證發送通知

常見陷阱

• 只設定 ExternalSecret 但忘記 Alertmanager chart 要加 useExistingSecret: true，會導致 chart 自己建立空的 Secret 覆蓋掉同步來的

最佳實踐

• 使用 ExternalSecret + useExistingSecret 而非 hardcode 在 Helm values 或 git

• Secret rotation 要配合 ExternalSecret refreshInterval，確保 k8s Secret 會自動更新

相關概念

• EKS Node Group Migration Runbook
• Observability Maturity Framework

相關視角

以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：

• Terraform Secrets Management with random_password — 共享：aws-secrets-manager, terraform / 獨特：random-password, sensitive-value

來源 Sessions

日期	Session	貢獻摘要

| 2026-03-24 | 6295486a-8e60-49c7-a5da-f375c806641a | 確立 Alertmanager 憑證管理的最佳實踐：ExternalSecret + useExistingSecret 方案，搭配 Terraform 產生密碼並寫入 AWS SSM |

---

本概念頁面由 Semi-Brain Wiki 系統自動維護

最後更新: 2026-03-24