今天，讓我分享如何運用外部秘密運算元（External Secret Operator，ESO）與Hashicorp Vault建立一個安全與自動化的機密管理機制。

為何需要進階的機密管理方案

在協助企業匯入GitOps時，我經常被問到如何安全地管理機密資訊。傳統的作法往往過於簡單，例如直接將加密後的機密存放在Git中，或是使用基本的Kubernetes Secret。這些方法都存在明顯的安全隱憂與管理困擾。

現有方案的侷限性

傳統的機密管理方式主要存在以下問題：

加密後的機密仍存在版本控制中，增加洩露風險
缺乏有效的機密輪換機制
許可權管理不夠精細
無法追蹤機密的使用狀況

外部秘密運算元的優勢

外部秘密運算元（ESO）是一個強大的Kubernetes控制器，能夠從多個外部供應商（如AWS、Azure、GCP、Vault等）擷取機密資訊，並將其轉換為Kubernetes可用的格式。在我的實務經驗中，ESO特別適合用於以下場景：

零信任架構的實作

ESO完美符合零信任架構的理念，因為：

完全避免在Git中儲存任何機密資訊
支援細緻的存取控制
提供完整的稽核追蹤能力
實作機密資訊的動態更新

自動化機密更新機制

一個常被忽視但極其重要的功能是自動化的機密更新。我曾經處理過一個案例，客戶的應用程式需要定期更新數百個API金鑰。透過ESO，我們實作了：

自動偵測機密變更
無需重新佈署即可更新機密
優雅的機密輪換機制
完整的變更歷史追蹤

Hashicorp Vault整合策略

在實務上，我建議將Hashicorp Vault作為核心的機密儲存系統。以下是我的整合建議：

建立安全的認證機制

最關鍵的是避免將任何認證資訊存放在Git中。我的做法是：

使用Kubernetes的服務帳號（Service Account）
設定Vault的Kubernetes認證方式
實作細緻的角色型存取控制（RBAC）
建立臨時性的動態憑證

自動化的機密生命週期管理

在玄貓的實務經驗中，優良的機密管理應該要像呼吸一樣自然與自動化。我們可以：

設定機密的自動輪換週期
建立機密洩露時的緊急復原機制
實作機密使用狀況的監控
自動化稽核日誌的收集與分析

在多年的雲端架構設計經驗中，玄貓深刻體會到金鑰管理對於系統安全的重要性。今天要和大家分享如何運用 External Secrets Operator (ESO) 搭配 HashiCorp Vault，建構一個既安全又靈活的 Kubernetes 金鑰管理方案。

ESO 的核心優勢

External Secrets Operator (ESO) 透過自定義資源定義（CRD）來管理金鑰來源（SecretStore）和外部金鑰（ExternalSecret）。在實作多個大型專案後，玄貓特別欣賞 ESO 的一個關鍵特性：無論金鑰來源為何，最終都會轉換為標準的 Kubernetes Secret。這樣的設計帶來許多實務優勢：

應用程式完全不需要知道 ESO 的存在
不需要實作特殊的金鑰存取 API
應用程式甚至不需要感知 Kubernetes 環境
支援從檔案系統或環境變數讀取金鑰

這種設計特別適合需要整合遺留系統的場景。在玄貓處理過的專案中，曾遇到一個無法修改程式碼的老舊系統，透過 ESO 就能優雅地整合現代的金鑰管理方案。

金鑰管理示範應用

讓我們來看一個實際的示範應用。這個應用程式採用檔案系統方式讀取金鑰，這是玄貓推薦的最佳實踐。原因在於檔案系統方式能夠監控檔案變更，讓應用程式在金鑰輪換時即時感知，無需重新佈署或重啟。

此應用程式需要管理三個金鑰：

資料函式庫網址
資料函式庫者名稱
資料函式庫

為了展示金鑰傳遞的完整流程，應用程式會顯示從 /secrets 目錄讀取的金鑰內容。在實際環境中，玄貓建議建立統一的金鑰來源標示規範，讓開發團隊能快速識別金鑰來源，這對於事件應變特別重要。

架構設計考量

在設計金鑰管理方案時，玄貓特別強調以下幾點：

金鑰來源的可追溯性：應用程式應清楚標示金鑰的載入來源
彈性的金鑰存取機制：支援檔案系統和環境變數兩種方式
統一的管理介面：透過 ESO 將不同來源的金鑰標準化

這些設計原則源自玄貓在處理各種規模專案時的實戰經驗，能有效降低維運複雜度，提升系統的可維護性。

接下來，讓我們進入實際的 HashiCorp Vault 和 ESO 佈署步驟。這個設定過程凝聚了玄貓多年的最佳實踐經驗，確保能建立一個穩固與安全的金鑰管理基礎。

Kubernetes 存取 Hashicorp Vault 的最佳實踐

在設定 Argo CD 與 Helm 圖表時，玄貓發現許多團隊對於如何管理 Vault 存取許可權感到困惑。讓我來分享多年實戰經驗中的關鍵心得。

Vault 在企業環境的正確佈署方式

在正式的企業環境中，Vault 通常由管理員統一佈署管理，開發團隊需向資安團隊申請存取許可權。不過在開發環境中，我們可以啟用 server.dev.enabled 選項來執行開發模式，這會略過 Vault 的封裝/解封(sealing/unsealing)機制。但玄貓必須強調，這種設定僅適用於開發測試，絕不能用於生產環境。

External Secret Operator 的整合策略

在將機密資訊傳遞給應用程式之前，我們需要為 ESO 設定正確的存取方式。這裡我們使用 Vault 的內建整合功能，關鍵在於建立 SecretStore 或 ClusterSecretStore 資源來定義驗證方式。

突破認證Token的困境

玄貓注意到許多教學文章在處理外部機密整合時，常陷入一個paradox：

使用預設 Token 存取 Vault
但這個 Token 本身又該如何安全存放？
若存在 Git 中，就違背了避免機密入函式庫衷
若寫死在叢集設定中，又會造成單點故障風險

根據信任的驗證機制

經過多年的系統架構經驗，玄貓建議採用根據信任而非靜態 Token 的驗證方式。主要考量：

優先評估支援 OIDC 協定的供應商
與資安團隊討論可用的驗證選項
確保驗證機制具備可擴充套件性

Kubernetes 與 Vault 的信任整合

在這個示範中，我們讓 Vault 透過 Kubernetes 驗證方式，信任執行 ESO 的叢集。ESO 會使用其 Pod 的服務帳號進行驗證，完全不需要儲存任何 Token。

這種方式確保了：

不需在任何地方硬編碼機密
維持了安全性與可靠性
簡化了維運流程

雖然 Vault 還提供了其他驗證選項，如信任外部叢集或其他 Vault 例項，但根據玄貓的經驗，在大多數場景下，根據 Kubernetes 的驗證機制已經能滿足企業需求。

此架構不僅解決了機密管理的技術難題，更重要的是符合現代雲原生應用的安全最佳實踐。在實際專案中，玄貓發現這種方式大幅降低了營運團隊的維護負擔，同時提供了更好的安全性保證。

在 Kubernetes 中設定 Vault 驗證

讓我們來設定 Kubernetes 與 Vault 的整合。首先，我們需要啟用 Kubernetes 驗證機制。在開發環境中，可以使用以下指令將 Vault UI 暴露出來：

kubectl port-forward -n vault vault-0 8200:8200

由於我們使用開發模式安裝 Vault，預設的 token 為 “root”。值得一提的是，Vault 的 Kubernetes 安裝版本已經預先內建了 Vault CLI，這讓我們能夠快速進行設定。

以下是啟用 Kubernetes 驗證的基本步驟：

# 進入 Vault Pod
kubectl exec --stdin=true --tty=true -n vault vault-0 -- /bin/sh

# 啟用 Kubernetes 驗證
vault auth enable kubernetes

# 設定 Kubernetes 驗證
vault write auth/kubernetes/config \
  kubernetes_host=https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT

# 建立示範角色
vault write auth/kubernetes/role/demo \
  bound_service_account_names=* \
  bound_service_account_namespaces=* \
  policies=default \
  ttl=1h

設定存取許可權

接下來，玄貓要為預設政策加入讀取機密的許可權。我們需要在預設政策中加入以下設定：

path "secret/*" {
  capabilities = [ "read", "list" ]
}

在實際的生產環境中，這些設定應該由專門的資安團隊依據最小許可權原則來管理。以上設定僅供示範使用，不建議在正式環境中使用。

設定 ClusterSecretStore

最後一個步驟是建立 ClusterSecretStore，告訴 External Secrets Operator 如何與 Vault 進行互動：

apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "http://vault.vault:8200"
      path: "secret"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "demo"

這個設定檔不包含任何敏感資訊，可以安全地存放在程式碼儲存函式庫

將 Vault 中的機密傳遞給應用程式

完成基礎設定後，玄貓將示範如何在應用程式中使用這些機密。首先，在 Vault 中建立所需的機密資料。接著，建立 External Secret 定義檔：

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: my-db-credentials
spec:
  refreshInterval: "15s"
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: mysql-credentials
  template:
    engineVersion: v2
    data:
      credentials: |
        db_con="{{.db_url }}"
        db_user="{{.db_username }}"
        db_password="{{.db_password }}"
  data:
    - secretKey: db_url
      remoteRef:
        key: mysql_credentials
        property: url
    - secretKey: db_username
      remoteRef:
        key: mysql_credentials
        property: username
    - secretKey: db_password
      remoteRef:
        key: mysql_credentials
        property: password

內容解密

讓玄貓為你解析這個 External Secret 設定：

refreshInterval: "15s" - 每 15 秒自動更新一次機密
secretStoreRef - 指定使用我們先前建立的 vault-backend ClusterSecretStore
target - 定義產生的 Kubernetes Secret 名稱為 mysql-credentials
template - 設定如何格式化機密資料
data - 定義要從 Vault 取得的具體機密專案：
- 資料函式庫RL
- 使用者名稱
- 密碼

這個設定會自動從 Vault 擷取資料函式庫，並建立對應的 Kubernetes Secret，供應用程式使用。

使用 External Secrets Operator 實作 GitOps 機密管理

在這篇文章中，玄貓將探討如何使用 External Secrets Operator (ESO) 與 HashiCorp Vault 來實作安全的 GitOps 機密管理。作為一個經常處理企業級佈署的技術工作者，我認為這種方案能有效解決 GitOps 中的機密管理難題。

機密範本與設定

首先，我們需要使用 ESO 的範本功能來設定機金鑰件。這個範本將對應用程式所需的屬性檔案格式。核心在於，這個設定檔本身不包含任何敏感資訊，而是作為 HashiCorp Vault 的參照指標。

佈署應用程式

接下來讓我們看如何使用 Argo CD 佈署應用程式。以下是關鍵的佈署設定：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitops-secrets-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gitops-secrets-app
  template:
    metadata:
      labels:
        app: gitops-secrets-app
    spec:
      containers:
      - name: gitops-secrets-app
        image: docker.io/kostiscodefresh/simple-secret-app:latest
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: mysql
          mountPath: "/secrets"
          readOnly: true
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
      volumes:
      - name: mysql
        secret:
          secretName: mysql-credentials

佈署設定解密

讓玄貓為你解析這個佈署設定的重要元素：

掛載設定：設定將 mysql-credentials 機密以檔案系統的形式掛載到容器的 /secrets 目錄
唯讀模式：為了安全性考量，掛載採用唯讀模式
健康檢查：包含活性與就緒性探針，確保應用程式穩定執行
容器映像：使用特定的應用程式映像，確保一致的佈署環境

佈署流程與機密處理機制

當我們完成佈署後，可以使用以下指令存取應用程式：

kubectl port-forward svc/gitops-secrets-service 8080:8080

實際運作時，整個流程是這樣的：

當 Argo CD 佈署應用程式時，會觸發一連串精密的機密處理流程。ESO 控制器偵測到 ExternalSecret 資源後，會與 Vault 進行安全通訊。由於 Kubernetes 身份驗證機制的存在，Vault 信任 ESO 的請求並提供機密資訊。

ESO 接收到機密後，會根據預定義的範本建立標準 Kubernetes 機密。這個過程確保了機密資訊的安全傳遞，同時保持了 GitOps 工作流程的完整性。

最終，應用程式容器可以像讀取普通檔案一樣存取這些機密資訊，整個過程對應用程式來說是完全透明的。這種方式不僅確保了安全性，還維持了開發和營運的順暢銜接。

在我多年的企業級佈署經驗中，這種機密管理方案確實解決了傳統 GitOps 流程中的一個關鍵痛點。它既保證了安全性，又不會破壞 GitOps 的自動化特性，是一個相當優雅的解決方案。

透過這種機制，我們實作了將機密資訊與版本控制完全分離，同時保持了佈署過程的自動化與可重複性。這正是現代雲端原生應用程式所需要的安全性與便利性的完美平衡。

在多年的系統架構設計經驗中，我發現金鑰管理一直是個棘手的問題。今天就讓我分享一個優雅的解決方案：如何實作應用程式金鑰的動態更新，而無需執行重啟操作。

動態金鑰更新的關鍵技術

在實務開發中，僅使用金鑰是不夠的，我們還需要一個有效的機制來進行金鑰的輪替和復原。External Secrets Operator (ESO) 提供了一個絕佳的解決方案，它能夠在原始金鑰儲存函式庫金鑰發生變更時，自動更新應用程式使用的金鑰。

玄貓在實作這類別系統時，發現有兩個關鍵設計要點：

從檔案載入金鑰，而非環境變數
- 環境變數在程式啟動後就固定不變
- 要更新環境變數的唯一方法就是重啟應用程式
實作檔案變更監控機制
- 程式碼需要持續監控 /secrets/credentials 檔案的變更
- 當檔案內容更新時，自動重新載入新的金鑰值

實戰案例：資料函式庫更新

讓我用一個實際案例來說明。假設我們的資料函式庫遭到洩露，需要立即更新。在這種情況下，我們只需要在 Vault 中更新密碼即可。ESO 會在下一個更新週期（由 External Secret CRD 中的 refreshInterval 屬性定義）自動將新的密碼同步到應用程式。

透過這種設計，我們實作了資訊安全最佳實踐中的一個重要目標：能夠在不重啟應用程式、不重建容器的情況下，完成金鑰的輪替和復原。這不僅提高了系統的安全性，也大幅降低了維運的複雜度。

自動金鑰更新的實作建議

根據我多年的實戰經驗，在實作自動金鑰更新時，有幾個重要的考量點：

檔案監控機制要穩健
- 實作適當的錯誤處理
- 考慮檔案鎖定情況
- 處理並發讀寫問題
更新邏輯要安全
- 確保金鑰更新的原子性
- 保持舊金鑰的短暫有效期
- 實作優雅的降級機制
監控與告警
- 記錄金鑰更新事件
- 設定適當的監控指標
- 建立異常通知機制

在現代雲原生架構中，這種動態金鑰管理方案已經成為標準實踐。透過 ESO 和適當的應用程式設計，我們可以在確保安全性的同時，也維持系統的高用性。

在實務應用中，這種方案不僅適用於資料函式庫，還可以擴充套件到 API 金鑰、加密金鑰等各類別敏感資訊的管理。玄貓建議在設計系統時，將動態金鑰管理納入基礎架構的標準考量中。

透過這種方式，我們在 GitOps 的工作流程中實作了更安全的金鑰管理。在 Git 中，我們只存放金鑰的設定和掛載方式，實際的金鑰值則儲存在外部安全儲存系統中。若您的組織已經有既有的金鑰管理系統，建議檢視 ESO 是否支援整合，這樣可以快速匯入這套解決方案。

最後，動態金鑰更新不僅是一個技術問題，更是一個安全實踐的範例。它展示瞭如何在不影響系統可用性的前提下，實作高效的金鑰管理。這正是現代雲端架構中安全性和便利性的完美平衡。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。

在GitOps中整合Vault與外部秘密運算元的最佳實踐