在當代軟體開發的生命週期中，CI/CD 管道已經成為不可或缺的基礎設施，然而這個自動化的流程同時也為密碼管理帶來了前所未有的挑戰。密碼洩漏的風險可能來自於組態設定錯誤、惡意貢獻者的蓄意攻擊，或是使用了不可信任的第三方軟體元件。特別是在採用 GitOps 工作模式的環境中，當我們整合 Sealed Secrets、外部密碼儲存服務以及 Helm Secrets 等解決方案時，每個環節都需要經過嚴謹的安全評估。生產環境與 CI/CD 環境必須使用完全不同的密碼組合，這不僅是為了避免單點故障，更是為了在發生資安事件時能夠有效控制影響範圍。過度授權的 CI/CD 管道可能導致災難性的後果，因此嚴格遵循最小許可權原則是絕對必要的。此外，供應鏈攻擊已經成為近年來最為猖獗的威脅型態之一，攻擊者可能透過滲透 CI/CD 管道中的任何環節來達到目的，因此確保每個軟體元件的來源可信賴度，並建立完整的驗證機制，是現代企業必須正視的課題。本文將深入探討如何有效降低這些風險，並提供一系列經過實戰驗證的最佳實踐方案，包括使用專屬的 CI/CD 密碼、落實最小許可權原則、建立定期輪換機制、實施持續監控與稽核，以及建構可信賴的軟體供應鏈。同時，我們將以 Square 公司開發的 Keywhiz 系統作為實際案例，詳細說明如何在企業環境中實踐安全且高效的密碼管理架構。
CI/CD 環境中的密碼管理架構與風險評估
在持續整合與持續部署的環境中，密碼管理已成為資安治理的核心議題。密碼作為應用程式與基礎設施運作所必需的敏感資訊，一旦遭到洩漏或不當使用，極可能引發嚴重的資安事件。本文將從技術架構與實務風險兩個層面，深入探討密碼管理與 CI/CD 整合所面臨的各項挑戰。
GitOps 架構下的密碼管理整合策略
GitOps 作為一種以 Git 儲存庫作為唯一真實來源（Single Source of Truth）的基礎設施管理方法，透過自動化機制將儲存庫中的組態變更應用於實際執行環境。這種模式對密碼管理方案提出了特殊的相容性要求。針對不同的密碼管理解決方案，在 GitOps 架構中的整合方式也各有差異。
Sealed Secrets 方案在 GitOps 環境中展現出極佳的整合性，這歸功於其控制器能夠自動偵測並應用儲存庫中任何新建立的密封密碼物件。外部密碼儲存方案則因其架構特性而不受 GitOps 工作流程影響，畢竟敏感資訊實際上儲存在獨立的元件中。至於 Helm Secrets 的支援程度則取決於所選用的 GitOps 工具，以 Argo CD 為例，雖然原生支援 Helm 圖表，但必須進行額外的組態調整，才能正確處理透過 Helm 圖表分發的加密密碼資訊。
CI/CD 管道中的密碼洩漏風險分析
CI/CD 管道中的密碼洩漏風險遠比多數人想像的更為嚴重。雖然現代 CI/CD 平台通常會對密碼資訊進行特殊處理，例如在 GitHub Actions 的工作流程中，任何嘗試輸出密碼內容的行為都會被自動遮蔽，但這種保護機制並不足以構成完整的安全防線。技術熟練的攻擊者可以透過修改管道組態，將密碼值儲存至檔案後再進行輸出，輕易繞過遮蔽機制。更為棘手的是，CI/CD 平台通常會保留完整的作業歷史紀錄與日誌檔案，在某些平台中，這些歷史紀錄甚至無法手動刪除，或只能在特定時間後才會自動清除，這無疑為密碼外洩後的應變處置增加了極大困難。
另一個常見的洩漏途徑是將密碼作為 CI/CD 管道生成的建構产物之一。當密碼被不慎打包進應用程式執行檔或容器映像時，任何能夠存取這些产物的使用者都可以從中擷取出敏感資訊。這類組態錯誤所導致的密碼洩漏事件，往往必須立即啟動密碼輪換程序，同時還需要徹底檢視並修正管道組態，以防止類似事件再次發生。
生產環境密碼與 CI/CD 環境分離的重要性
在 CI/CD 環境中存放生產環境使用的密碼，是相當高風險的做法。生產環境密碼的用途與 CI/CD 環境有本質上的差異，前者用於實際營運系統的運作，後者僅用於軟體建構、測試與部署流程。當 CI/CD 環境擁有生產環境密碼時，一旦管道發生組態錯誤，極可能直接影響實際營運系統。更嚴重的是，在密碼洩漏的情境下，若採用專門為 CI/CD 作業設計的密碼，其風險影響範圍相對可控；但若洩漏的是生產環境密碼，則可能導致整個營運系統遭受入侵。
實際攻擊案例分析與防禦機制
惡意貢獻者攻擊手法深度剖析
CI/CD 管道已成為攻擊者竊取密碼的重要目標。透過提交提取請求（Pull Request）來觸發管道執行，攻擊者可以獲得多種竊取密碼的機會。這類攻擊在開源專案中尤其常見，惡意貢獻者可能將竊取密碼作為主要目的，或是將其納入更大規模的供應鏈攻擊計畫中。
以防範此類攻擊，必須對涉及敏感資訊存取的 CI/CD 作業實施嚴格的保護措施。分支保護政策應當強制執行，同時將特定管道獨立分離，以實現更細緻的許可權控管，防止試圖透過 CI/CD 作業竊取密碼資訊的攻擊者得逞。以 GitHub Actions 為例，來自分支工作流程的執行作業預設無法存取密碼資訊。此外，GitHub Actions 提供了提取請求工作流程執行作業的核准機制，這項功能可以有效防止來自公開分支的惡意程式碼在未經審查的情況下執行。
不可信任軟體引發的供應鏈攻擊風險評估
CI/CD 管道的安全性取決於其所使用軟體元件的可信賴程度。網際網路上存在大量現成的 CI/CD 軟體函式庫與 Docker 容器映像，這些元件可能存在已知的安全漏洞，或是已經被攻擊者植入惡意程式碼，成為供應鏈攻擊的載體。
舉例而言，一個看似正常的 Jenkins 外掛或 GitHub Actions 自訂動作，可能在背景讀取管道中的密碼資訊並傳送至外部伺服器。同樣的風險也存在於任何未經信任或已被破壞的工具中。因此，必須嚴格限制只使用來自可信賴來源的軟體元件，並透過雜湊值驗證等方式確認其真實性。此外，管道中使用的所有軟體都應保持最新版本，並及時套用必要的安全性更新。
過度授權管道引發的權限擴散風險
CI/CD 管道在現代軟體開發中扮演關鍵角色，因此通常需要與 Kubernetes 等基礎設施互動以存取密碼資訊。然而，當 CI/CD 作業被賦予超出其實際需求的密碼存取權限時，可能引發嚴重的安全問題。
舉例來說，某個用於測試目的的 CI/CD 作業需要從外部密碼儲存服務中刪除測試環境的密碼。若管道被賦予過於廣泛的權限，使其同時擁有刪除生產環境密碼的能力，一旦發生組態錯誤，極可能導致資料遺失甚至生產環境停擺的重大事故。
企業級密碼管理最佳實踐架構
密碼管理核心原則與實作策略
理解 CI/CD 整合所帶來的各項風險後，企業應建立一套完整的最佳實踐框架。首要原則是為每個 CI/CD 作業配置專屬的密碼，確保不同作業間不會共用憑證。這種隔離機制能夠在某個作業遭到入侵時，有效限制攻擊者的橫向移動範圍。
最小許可權原則的落實同樣至關重要，必須確保每個 CI/CD 作業僅擁有完成其任務所需的最低限度權限，從而降低過度授權或未使用權限所帶來的風險。定期輪換密碼與憑證是減少長期暴露風險的有效手段，企業應建立自動化的輪換機制，確保密碼在預定的生命週期後自動更新。
完整的監控與稽核機制不可或缺，必須對密碼與憑證的使用情況進行持續監控，並保留詳細的稽核日誌。這些日誌應定期檢視，以便及時發現任何可疑的活動模式。最後，嚴格控管軟體來源的可信賴度，確保只從經過驗證的來源使用軟體元件。
威脅防範的具體實施建議
為了有效防範上述各項威脅，企業應採取多層次的防禦策略。定期更新與修補所有相關軟體與函式庫，確保已知漏洞能夠及時獲得修復。實施嚴格的權限管理制度，確保只有必要的人員才能存取敏感資料與執行關鍵操作。
建立完整的監控與記錄系統，詳細記錄所有對敏感資料的存取與操作行為。對開發人員與維運人員進行持續的安全教育與培訓，提升整體資安意識。引入自動化測試機制，定期檢查潛在的安全漏洞並驗證系統的安全性組態。
企業級密碼管理系統實作案例
Square Keywhiz 系統架構深度解析
在持續整合與持續交付作業中，與 Kubernetes 密碼系統互動時，密碼管理的安全性至關重要。玄貓團隊在實務經驗中發現，許多組織在轉向容器化協調平台時，都需要建立更為堅固的密碼管理系統。Square 公司開發的 Keywhiz 系統，正是解決這類需求的典型範例。
Square 開發 Keywhiz 的主要目的，在於保護重要的數位鑰匙與密碼資訊，例如用於保護網站服務的 TLS 憑證與私密金鑰。該系統確保只有特定的服務元件能夠存取這些敏感資料，並且所有通訊都必須透過安全的連線進行。
業務驅動因素與核心價值
Square 建立 Keywhiz 的業務理由，在於讓重要密碼資訊變得難以被未經授權的對象存取。這些敏感資料不應該出現在開發人員的個人電腦或直接暴露於網際網路上，而應該限制為只有真正需要這些資料的特定服務才能存取。特別是在使用安全連線來保護資料的服務中，Keywhiz 提供了一種直接存取這些密碼的方式，無需經過多重步驟或其他中介服務。
Keywhiz 的另一項核心價值在於避免密碼資訊的散佈。透過集中化的管理方式，更容易追蹤與保護這些敏感資料。此外，該系統還具備檢查數位鑰匙與密碼健康狀態的能力，例如驗證密碼強度是否足夠或是否需要更新。
完整的存取紀錄是 Keywhiz 的重要特性之一，系統會詳細記錄每次密碼存取的相關資訊，確保所有操作都可追溯。Keywhiz 的設計理念是為了與 Square 的各類服務無縫整合，從網站保護到資料庫存取控制，提供全方位的密碼管理解決方案。
技術實作細節解析
Square 的 Keywhiz 系統對於數位密碼的安全性採取了極為嚴格的控制措施。系統首先將密碼進行明確的分類，這不僅是為了管理上的整潔，更重要的是能夠精準識別 Square 內部哪些服務需要存取哪些密碼。
所有密碼都儲存在中央化的儲存位置，這種設計避免了密碼分散在各處而可能被遺忘或未經授權存取的風險。在密碼儲存至資料庫之前，系統會使用 AES-GCM 加密演算法為每個密碼加上一層保護，這種加密方式如同將信件放入只有特定人員才能開啟的保險箱。
每個密碼都擁有唯一的加密金鑰，這些金鑰透過 HKDF（基於 HMAC 的金鑰衍生函式）方法產生。這種設計確保即使單一金鑰遭到破解，其他金鑰仍能保持安全。Square 更進一步使用硬體安全模組（HSM）來保護根金鑰的安全性。
在密碼傳輸過程中，Keywhiz 確保只有 Square 系統中正確的客戶端元件能夠存取這些資料。其存取控制結構圍繞三個核心元素：客戶端、群組與密碼。客戶端是指任何需要取得密碼的服務實體，這些客戶端可以屬於多個群組，而密碼必須與客戶端所屬的至少一個群組建立關聯，才能被該客戶端存取。
PKI 基礎的認證與授權機制
公共金鑰基礎設施（PKI）是 Square 認證流程中的核心元件，如同一個驗證系統，確保只有正確的服務才能存取所需的密碼。為了建立這種信任關係，Square 採用 mTLS 與 X.509 憑證作為服務身份識別的證明。
在授權資料模型方面，Keywhiz 的設計包含了明確的結構化層次。客戶端代表 Square 系統中需要存取密碼以正常運作的服務或應用程式，而客戶端憑證則如同系統的身份識別卡，用於驗證客戶端的合法性。
驗證流程中，PKI 確保了身份的真實性，而授權模型則根據角色與屬性進行精細的存取控制。每個客戶端都擁有明確定義的許可權集合，透過集中化的管理方式與持續監控機制，大幅增強了整體系統的安全性。
技術選型分析與未來發展趨勢
在技術選型層面，Keywhiz 結合 AES-GCM 加密與 PKI 基礎設施，展現了高度安全性與靈活性的平衡。展望未來，隨著容器協調技術與雲端運算的不斷演進，密碼管理領域將呈現幾個明確的發展方向。
自動化管理將成為主流，隨著自動化技術的成熟，密碼的生命週期管理將更加智慧化，從生成、分發到輪換都能自動完成。系統整合度也將持續提升，未來將有更多工具與服務與密碼管理系統深度整合，形成完整的生態系。
在加密技術方面，隨著運算能力的提升與量子運算的發展，更高階的加密演算法將被廣泛採用，以確保長期的安全性。
複雜度與成本效益考量
儘管 Keywhiz 提供了高度安全性與靈活性的功能，但這些優勢也伴隨著維運複雜度的提升與成本支出的增加。企業在導入此類系統時，必須仔細評估自身的技術能力與預算限制，確保能夠充分發揮系統價值。
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
actor "開發人員" as dev
participant "Keywhiz 系統" as keywhiz
participant "HSM 模組" as hsm
database "加密資料庫" as db
dev -> keywhiz : 發出密碼存取請求
note right : 包含客戶端憑證與請求資訊
keywhiz -> keywhiz : 驗證請求完整性
keywhiz -> keywhiz : 解析客戶端身份
keywhiz -> keywhiz : 檢查群組授權關係
keywhiz -> hsm : 請求金鑰解密操作
note right : 使用硬體保護的根金鑰
hsm --> keywhiz : 回傳解密後的金鑰資料
keywhiz -> db : 查詢加密後的密碼資料
db --> keywhiz : 回傳 AES-GCM 加密資料
keywhiz -> keywhiz : 使用衍生金鑰解密密碼
keywhiz -> keywhiz : 記錄完整存取日誌
keywhiz --> dev : 傳回解密後的密碼內容
note right : 透過 mTLS 加密通道傳輸
end note
end note
end note
@enduml此圖示解說 Keywhiz 系統的完整運作流程：
當開發人員或服務元件需要存取密碼時，首先會向 Keywhiz 系統發出請求，這個請求必須包含有效的客戶端憑證與明確的請求資訊。Keywhiz 系統接收到請求後，會先驗證請求的完整性，並解析客戶端的身份信息，接著檢查該客戶端所屬群組與目標密碼之間的授權關係。若授權檢查通過，系統會向硬體安全模組（HSM）請求金鑰解密操作，利用硬體保護的根金鑰來確保金鑰管理的安全性。取得必要的金鑰資料後，系統會從資料庫中查詢加密儲存的密碼資訊，這些資料均以 AES-GCM 演算法加密。Keywhiz 使用透過 HKDF 衍生的專屬金鑰來解密密碼內容，同時記錄完整的存取日誌以供後續稽核。最終，解密後的密碼透過 mTLS 加密的安全通道傳回給請求者，確保整個傳輸過程的安全性。
Kubernetes 環境中的密碼管理實作範例
以下提供一個在 Kubernetes 環境中實作密碼管理的實際範例，展示如何透過 Sealed Secrets 與外部密碼儲存服務的整合，建立安全的密碼管理流程。
# 這個 YAML 檔案展示了如何在 Kubernetes 中使用 Sealed Secrets
# 來保護敏感的密碼資訊，避免將明碼提交至 Git 儲存庫
# 首先，我們定義一個包含敏感資料的 Secret 模板
# 這個檔案在本機產生，不會提交到版本控制系統
apiVersion: v1
kind: Secret
metadata:
name: database-credentials
namespace: production
type: Opaque
data:
# username: admin (base64 編碼)
username: YWRtaW4=
# password: super-secret-password (base64 編碼)
password: c3VwZXItc2VjcmV0LXBhc3N3b3Jk
#!/usr/bin/env bash
# 這個腳本示範如何使用 kubeseal 指令將一般的 Secret 轉換為 Sealed Secret
# 这种方式可以確保只有叢集內的控制器能夠解密
# 使用 kubeseal 指令加密 Secret 檔案
# --controller-name 指定 Sealed Secrets 控制器的名稱
# --controller-namespace 指定控制器所在的命名空間
# --format yaml 指定輸出格式為 YAML
# --secret-file 指定要加密的 Secret 檔案
# > sealed-secret.yaml 將輸出重新導向至新檔案
kubeseal --controller-name=sealed-secrets-controller \
--controller-namespace=kube-system \
--format yaml \
--secret-file database-secret.yaml \
> sealed-database-secret.yaml
# 產生的 sealed-database-secret.yaml 可以安全地提交至 Git 儲存庫
# 因為它使用叢集的公開金鑰加密，只有叢集內的控制器能夠解密
# 這是產生的 Sealed Secret 檔案範例
# 這個檔案可以安全地提交至版本控制系統
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
name: database-credentials
namespace: production
spec:
encryptedData:
# 以下為加密後的資料，只有叢集內控制器能夠解密
username: AgBy3i4OJSWK+PiTySYZZA9rO43aaNlbGqunFS5pHvJ3QdKqT0nGG3QGhUGcFbF9J2G6L6XVcJ5wLD5bCuFEcMyG8ZtfF1Wq5TbqIBLHh3cJ6ZJL6mrjainFgNk5JPaZFG+Zr6ap80cjlbZ6GU9d57l0GVio8sCT69x9MjIYSgKyi8YD/89ku7fL8XxyzzRo3zTJ7G6ew3xSWPpJq2WKQcIWvQ6VN3v4JHTxK1d8sM6MnzJVvK3LCfCuT5JzsK/JKyY9JqSsPdTJM9KyLgJ9WQFTXJbBv7fJ6Wo7E6T6J6t4K6L6K6Q6J6G6E6N6S6T6R6O6N6G6
password: AgC7h8i9J0K1L2M3N4O5P6Q7R8S9T0U1V2W3X4Y5Z6A7B8C9D0E1F2G3H4I5J6K7L8M9N0O1P2Q3R4S5T6U7V8W9X0Y1Z2A3B4C5D6E7F8G9H0I1J2K3L4M5N6O7P8Q9R0S1T2U3V4W5X6Y7Z8A9B0C1D2E3F4G5H6I7J8K9L0M1N2O3P4Q5R6S7T8U9V0W1X2Y3Z4A5B6C7D8E9F0G1H2I3J4K5L6M7N8O9P0Q1R2S3T4U5V6W7X8Y9Z0A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5
template:
metadata:
name: database-credentials
namespace: production
type: Opaque
#!/usr/bin/env bash
# 這個腳本展示如何在 CI/CD 管道中安全地使用外部密碼儲存服務
# 例如 HashiCorp Vault 或 AWS Secrets Manager
# 設定 Vault 伺服器位址
export VAULT_ADDR="https://vault.production.example.com"
# 使用 JWT 認證方式登入 Vault
# 這種方式適合在 CI/CD 環境中使用，因為可以利用平台的身份認證
# -method=jwt 指定使用 JWT 認證方式
# -role=ci-cd-role 指定使用的角色，該角色應具有最小許可權
# jwt="$CI_JOB_JWT" 從 CI/CD 平台取得 JWT 權杖
vault write -field=token auth/jwt/login \
role=ci-cd-role \
jwt="$CI_JOB_JWT" > ~/.vault-token
# 從 Vault 讀取資料庫密碼
# -field=password 只取得密碼欄位，避免讀取不必要的資訊
# database/creds/app-role 是密碼在 Vault 中的路徑
# 這個路徑使用動態密碼，每次讀取都會產生新的帳號密碼
DB_PASSWORD=$(vault kv get -field=password secret/database/app)
# 使用取得的密碼執行資料庫遷移
# 這裡使用環境變數傳遞密碼，避免出現在命令列參數中
export PGPASSWORD="${DB_PASSWORD}"
psql -h database.internal -U app_user -d production_db -f migrations.sql
# 執行完成後立即清除敏感資訊
# 使用 unset 移除環境變數
# 使用 shred 確保記憶體中的資料被覆寫
unset DB_PASSWORD
unset PGPASSWORD
shred -u ~/.vault-token
完整的 CI/CD 密碼管理架構圖
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100
actor "開發者" as developer
participant "Git 儲存庫" as git
participant "CI/CD 平台" as cicd
participant "密碼管理服務" as vault
participant "Kubernetes 叢集" as k8s
participant "Sealed Secrets 控制器" as sealedctrl
developer -> git : 提交程式碼與 Sealed Secret
git -> cicd : 觸發管道執行
cicd -> cicd : 執行靜態程式碼分析
cicd -> vault : 使用 JWT 進行認證
vault --> cicd : 回傳臨時存取權杖
cicd -> vault : 取得建構所需的密碼
note right : 資料庫密碼、API 金鑰等
cicd -> cicd : 執行測試與建構
cicd -> cicd : 產生容器映像
cicd -> k8s : 部署應用程式與 Sealed Secret
k8s -> sealedctrl : 偵測到新的 Sealed Secret
sealedctrl -> sealedctrl : 使用叢集私鑰解密
sealedctrl -> k8s : 建立一般的 Secret 物件
k8s -> k8s : Pod 啟動並掛載 Secret
k8s -> vault : 動態取得執行時期密碼（可選）
note right : 使用 Vault CSI Provider
cicd -> vault : 撤銷臨時憑證
cicd -> cicd : 清理建構環境
end note
end note
@enduml此架構圖展示了完整的企業級 CI/CD 密碼管理流程：
開發者將應用程式程式碼與 Sealed Secret 檔案提交至 Git 儲存庫，這個動作會觸發 CI/CD 平台開始執行自動化管道。管道首先執行靜態程式碼分析，檢查是否包含潛在的安全漏洞或密碼洩漏風險。接著，CI/CD 平台使用平台提供的 JWT 權杖向密碼管理服務（如 Vault）進行認證，取得臨時的存取權杖。透過這個權杖，管道可以安全地取得建構過程所需的各項密碼，包括資料庫連線資訊、第三方 API 金鑰等敏感資料。
取得必要密碼後，管道執行完整的測試套件與應用程式建構流程，產生最終的容器映像。在部署階段，CI/CD 平台將應用程式與 Sealed Secret 一併部署至 Kubernetes 叢集。叢集內的 Sealed Secrets 控制器會自動偵測新建立的 Sealed Secret 物件，並使用叢集獨有的私鑰進行解密，然後在叢集內部建立一般的 Secret 物件，供應用程式掛載使用。
對於需要更高安全等級的環境，可以選擇使用 Vault CSI Provider，讓 Pod 在執行時期動態從 Vault 取得密碼，避免在 etcd 中儲存任何靜態密碼資料。部署完成後，CI/CD 平台會立即撤銷先前取得的臨時憑證，並徹底清理建構環境中的所有敏感資料，確保不會留下任何安全隱患。
安全性驗證與合規性檢查清單
#!/usr/bin/env bash
# 這個腳本提供 CI/CD 密碼管理的自動化安全檢查
# 可用於在部署前驗證密碼管理組態的正確性
# 設定錯誤處理機制，任何錯誤都會立即終止腳本執行
set -euo pipefail
# 定義顏色輸出函數，用於顯示不同等級的訊息
# 這些顏色定義符合多數終端機的 ANSI 色彩碼
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color
# 定義檢查結果陣列，用於收集所有檢查項目的結果
declare -a CHECK_RESULTS
# 檢查 Kubernetes Secret 是否包含明碼密碼
check_plaintext_secrets() {
echo "檢查 Kubernetes 設定檔中是否包含明碼密碼..."
# 使用 grep 搜尋常見的密碼欄位名稱
# -i 參數表示忽略大小寫
# -r 參數表示遞迴搜尋目錄
if grep -ri "password:\|passwd:\|secret:" k8s-manifests/ | grep -v "sealedsecret\|encrypted"; then
echo -e "${RED}發現明碼密碼！請立即使用 Sealed Secrets 或外部密碼管理服務。${NC}"
CHECK_RESULTS+=("FAIL: 發現明碼密碼")
return 1
else
echo -e "${GREEN}未發現明碼密碼，符合安全規範。${NC}"
CHECK_RESULTS+=("PASS: 無明碼密碼")
return 0
fi
}
# 檢查 Sealed Secrets 控制器是否正確安裝
check_sealed_secrets_controller() {
echo "檢查 Sealed Secrets 控制器狀態..."
# 使用 kubectl 檢查控制器是否在運行
if kubectl get pods -n kube-system -l name=sealed-secrets-controller | grep -q "Running"; then
echo -e "${GREEN}Sealed Secrets 控制器運行正常。${NC}"
CHECK_RESULTS+=("PASS: Sealed Secrets 控制器正常")
return 0
else
echo -e "${RED}Sealed Secrets 控制器未運行或異常！${NC}"
CHECK_RESULTS+=("FAIL: Sealed Secrets 控制器異常")
return 1
fi
}
# 檢查 Vault 存取政策是否遵循最小許可權原則
check_vault_policies() {
echo "檢查 Vault 存取政策設定..."
# 讀取 CI/CD 角色的政策設定
# 這個角色應該只有讀取特定路徑的權限
POLICY=$(vault policy read ci-cd-role 2>/dev/null || echo "")
# 檢查政策中是否包含危險的萬用字元路徑
if echo "$POLICY" | grep -q 'path "secret/*"'; then
echo -e "${YELLOW}警告：Vault 政策使用過於寬鬆的路徑萬用字元。${NC}"
CHECK_RESULTS+=("WARN: Vault 政策過於寬鬆")
return 1
else
echo -e "${GREEN}Vault 政策符合最小許可權原則。${NC}"
CHECK_RESULTS+=("PASS: Vault 政策符合規範")
return 0
fi
}
# 檢查密碼輪換機制是否正常運作
check_secret_rotation() {
echo "檢查密碼輪換機制..."
# 取得上次輪換時間戳記
LAST_ROTATION=$(vault read -field=last_rotation secret/database/app 2>/dev/null || echo "0")
CURRENT_TIME=$(date +%s)
TIME_DIFF=$((CURRENT_TIME - LAST_ROTATION))
# 計算天數差異
DAYS_DIFF=$((TIME_DIFF / 86400))
# 如果超過 90 天未輪換，發出警告
if [ $DAYS_DIFF -gt 90 ]; then
echo -e "${YELLOW}警告：密碼已超過 ${DAYS_DIFF} 天未輪換。${NC}"
CHECK_RESULTS+=("WARN: 密碼輪換逾期")
return 1
else
echo -e "${GREEN}密碼輪換機制正常，上次輪換於 ${DAYS_DIFF} 天前。${NC}"
CHECK_RESULTS+=("PASS: 密碼輪換正常")
return 0
fi
}
# 主執行流程
echo "開始執行 CI/CD 密碼管理安全檢查..."
echo "================================================"
echo ""
# 依序執行各項檢查
check_plaintext_secrets
echo ""
check_sealed_secrets_controller
echo ""
check_vault_policies
echo ""
check_secret_rotation
echo ""
# 產生檢查報告
echo "================================================"
echo "檢查結果摘要："
# 統計各類結果的數量
PASS_COUNT=0
WARN_COUNT=0
FAIL_COUNT=0
for result in "${CHECK_RESULTS[@]}"; do
if [[ $result == PASS:* ]]; then
((PASS_COUNT++))
echo -e "${GREEN}✓ $result${NC}"
elif [[ $result == WARN:* ]]; then
((WARN_COUNT++))
echo -e "${YELLOW}⚠ $result${NC}"
elif [[ $result == FAIL:* ]]; then
((FAIL_COUNT++))
echo -e "${RED}✗ $result${NC}"
fi
done
echo ""
echo "總計：$PASS_COUNT 項通過，$WARN_COUNT 項警告，$FAIL_COUNT 項失敗"
# 根據檢查結果決定腳本結束碼
if [ $FAIL_COUNT -gt 0 ]; then
echo -e "${RED}檢查未通過，請立即處理上述問題！${NC}"
exit 1
elif [ $WARN_COUNT -gt 0 ]; then
echo -e "${YELLOW}檢查通過，但存在需要改善的項目。${NC}"
exit 0
else
echo -e "${GREEN}所有檢查項目皆通過，密碼管理組態符合安全規範。${NC}"
exit 0
fi
這個自動化檢查腳本能夠在 CI/CD 管道執行初期就發現潛在的密碼管理問題，有效降低安全風險。腳本會檢查四個關鍵項目：是否有明碼密碼、Sealed Secrets 控制器狀態、Vault 政策設定，以及密碼輪換機制。透過這種自動化驗證，企業可以在問題發生前就予以修正，確保整體密碼管理架構的穩健性。
結論與建議
在台灣的企業環境中實作 CI/CD 密碼管理時，必須特別考量本地的法規要求與產業特性。金融業受到金管會的嚴格監管，必須確保所有密碼管理流程符合相關法令；高科技製造業則需要面對複雜的供應鏈資安要求。建議企業採取分階段導入策略，先從非關鍵的測試環境開始，逐步建立團隊的技術能力與操作經驗，再擴展至生產環境。
同時，應建立跨部門的資安工作小組，納入開發、維運、資安與法遵等相關單位，共同制定符合企業實際需求的密碼管理政策。透過這種協作模式，才能確保技術方案不僅能夠有效提升安全性，更能符合企業的營運需求與法規遵循義務。
最終，成功的密碼管理不僅依賴於先進的工具與技術，更需要建立完整的治理框架、培養團隊的安全意識，並持續監控與改善相關流程。唯有將技術、流程與人員三個層面緊密結合，才能在當前複雜的威脅環境中，有效保護企業最關鍵的數位資產。
