Kubernetes Secret 安全管理與合規性最佳實務

– 10 分鐘閱讀

Kubernetes Secret 的安全管理對於保障容器化應用程式至關重要。不當的 Secret 管理可能導致敏感資訊洩露，例如在 Pod 中執行除錯指令時，Secret 輸出到標準輸出或標準錯誤，進而被記錄到日誌系統中，造成廣泛的存取風險。此外，將 Secret 下載到本地也可能違反組織的資安政策。因此，除了基礎的 Secret 管理外，更需深入瞭解安全與合規性考量、風險緩解策略以及災難還原與備份計劃。本文將探討如何強化 Secret 安全性，並介紹 CIS Benchmarks 等安全基準，以建立更完善的 Secret 管理流程。更進一步說明如何組態加密提供者、建立稽核策略、優先使用檔案掛載存取 Secret，以及考慮外部 Secret 儲存方案，以提升整體安全性。同時，文章也強調了資安與資安風險管理的差異，並以實際案例說明不同部門如何根據業務需求遵守 HIPAA、GDPR、PCI-DSS 等相關法規標準。最後，文章也提醒讀者，實體層面的安全控制同樣重要，並建議更新安全架構圖，以反映持續的安全合規性工作。

避免洩露敏感資訊

在 Kubernetes 環境中，避免洩露敏感資訊是非常重要的，特別是在排除錯誤時。當你遇到 Kubernetes Secret 的問題時，很容易會想要在 Pod 中開啟一個終端機會話並執行排除錯誤的指令。容器內部產生的日誌會被寫入標準輸出（stdout）及標準錯誤（stderr）流。Kubernetes 與許多流行的日誌解決方案如 AWS CloudWatch、Datadog 和 Google Cloud Monitoring 等整合良好。如果在 Pod 中輸出 Secret，這些 Secret 會被寫入這些流並最終被傳送到整合的日誌解決方案中。而日誌解決方案可能在組織內部廣泛可存取，比直接存取 Kubernetes 叢集中的 Secret 更容易遭受洩露風險。一旦發生這種情況，Secret 就必須被復原，造成額外的負擔。

另一個最佳實踐是避免在排除錯誤時將 Secret 下載到本地。將 Secret 下載到本地可能會違反組織制定的資訊安全政策。

Kubernetes Secrets 在生產環境中的進階主題

在此部分，玄貓將探討更多與 Kubernetes Secrets 相關的進階主題，包括安全與合規性考量、風險緩解策略及災難還原與備份計劃。最後，玄貓將學習如何緩解安全風險以及如何為 Kubernetes Secrets 建立災難還原計劃和備份策略。

本部分內容包括：

  • 第五章 安全、稽核與合規

  • 第六章 災難還原與備份

  • 第七章 管理 Secrets 的挑戰與風險

安全、稽核與合規

在前幾章中，玄貓已建立了從設計、實作及營運角度處理 Kubernetes Secrets 管理挑戰的基礎。此外，我們也針對全端架構各層級挑戰指出關鍵注意事項，並考慮減少或緩解安全曝露的路徑。然而，無論我們投入多少努力，以下問題總是環繞著：

  • 我們如何讓 IT 環境足夠安全？

  • 控制和稽核角度的最佳實踐為何？

  • CISO 的需求為何？

本章以「CISO 的需求」這個問題為基礎，開啟進階主題手冊。通常回答會以另一個問題呈現，「我的組織需要遵守哪些法規？」這意味著法律觀點。

本章將探討以下主題：

  • 認識網路安全與網路風險管理

  • 最常見的合規標準

  • 控制、稽核及緩解安全風險的最佳實踐

技術要求

為完成本章實作部分，玄貓將利用一系列常用工具和平台來互動容器、Kubernetes 和 Secrets 管理。對於本章節仍將使用相同的一組工具：

  • Docker 或 Podman 作為容器引擎。
    • 兩者都可以使用；不過玄貓個人偏好 Podman，因其無需守護程式（無需複雜安裝步驟）、無需 root 模式（增加安全性）、完全符合 OCI 標準、準備好用於 Kubernetes 以及能夠在使用者層級與 systemd 整合自動啟動容器/Pods。
  • Podman Desktop 是一款開源軟體提供圖形化使用者介面來建置、啟動及除錯容器、執行本地 Kubernetes 情境、簡化從容器到 Pods 的轉換過程以及連線到遠端平台如 Red Hat OpenShift、Azure Kubernetes Engine。
  • Git 是版本控制系統，本文示範案例中會使用且亦用於尋找 Secrets 管理方案。
  • Kube-bench 是社群工具可以根據 CIS 基準測量您的 Kubernetes 叢集。
  • Compliance Operator 是社群工具測量及修復 Kubernetes 叢集中的安全控管。
  • HashiCorp Vault 是社群版 Vault 提供企業版用於安全儲存憑證、代幣及更多功能。
  • Trousseau 是 KMS 提供者外掛利用外部 KMSs 如 HashiCorp Vault、Azure Key Vault 和其 AWS 對應版本。

此書 GitHub 儲存函式庫包含此書相關數位素材：Kubernetes-Secrets-Handbook。

網路安全 vs 網路風險管理

儘管網路（網路）安全及網路風險管理有充足的出版資料可以參考，但兩者常被誤認為相同事物。

本文目的

目的是幫助你重新構思傳統從 IT 偏重觀點進行網路安全作業方式，轉向在瞭解組織需求和要求後進行網路安全作業方式。這將有助於你進行動態風險評估以適當實施安全措施。

此圖示展示了網路安全與風險管理之間關聯：

  graph TD
    A[IT 資產] --> B[資安需求]
    B --> C[法律規範]
    C --> D[風險評估]
    D --> E[適當措施]
    E --> F[持續監控]
    F --> A

此圖示解析：

  1. IT 資產：這包括所有需要保護的資產如伺服器、網路裝置等。
  2. 資安需求：根據IT 資產確定其所需的安全措施。
  3. 法律規範：確保所有措施符合現行法律和法規要求。
  4. 風險評估：對可能存在的風險進行評估。
  5. 適當措施：根據評估結果制定並實施適當的安全措施。
  6. 持續監控：持續監控系統狀態以確保措施有效並隨時更新。

透過以上步驟可以確保系統全面性地進行網路安全防護工作，並在發現問題後能夠快速回應並改善系統組態。

資安 vs. 資安風險管理

在現代數位經濟中，資安與資安風險管理是兩個相關但不同的概念，理解它們的差異對於建立有效的防禦策略至關重要。這篇文章將探討這兩者的區別，並提供實務上的建議。

資安的挑戰

大多陣列織將資安工作交由IT部門負責，這樣的做法通常會限制資安任務的範圍，導致以下三個主要問題：

  1. 範圍限制：僅專注於基礎設施層面，忽略了對關鍵業務應用的考量。
  2. 知識不足：對組織的業務持續計劃瞭解有限。
  3. 反應能力不足：營運團隊在面對安全事件時反應不足。

這種模式通常採取以下兩種策略：

  1. 事件驅動或反應式：僅在發生事件後才採取行動。
  2. 全面封鎖：為了應對監控和發現安全漏洞的能力不足，封鎖一切可能的漏洞。

由於資安被視為一種約束，因此只有在內部發生事件或公共參考案例出現時，才會進行大幅度變更。雖然一些組織聲稱已經有監控和流程來識別和解決事件，但缺乏模擬演練來訓練IT人員，類別似於災難還原計劃（DRP）的情況。

資安風險管理

為了更有效地管理資安風險，需要從業務角度考慮風險管理，以滿足各部門的治理和合規要求。這種方法能夠幫助優先設計和實施安全措施，並賦予組織層級的適當技能。這需要了解組織的運作機制，從財務到售後支援，以防止技術專家過度或不足投資於不適合不同業務單位的安全工具。

資安與資安風險管理的比較

資安模型

在傳統資安模型中，可能會實施強力的登入憑證政策，如每30天更新密碼並附加多因素驗證（MFA），但這種方法在不同業務團隊中可能效果不同。例如，工程團隊可能適應這種方式，但主要使用網頁解決方案的業務團隊可能會遇到問題。

資安風險管理模型

在資安風險管理模型中，可能會採用一次性密碼（OTP）方法來實施強力的登入憑證政策。這種解決方案對於使用網頁解決方案的員工來說提供了足夠的安全性。此外，還可以根據需要實施額外的多因素驗證和安全稽核。

合規標準

合規性是指組織如何在尊重特定法律和政策的前提下運作，這些法律和政策根據其行業、總公司位置以及其業務國家來制定。合規要求通常決定組織治理中的大部分要求。

合規標準示例

  • 美國《健康保險便攜性與責任法》（HIPAA）：處理病人記錄。
  • 歐盟《一般資料保護條例》（GDPR）：收集、處理和儲存第三方個人使用者資料。
  • 支付卡行業資料安全標準（PCI-DSS）：支付卡交易。
  • 歐盟AI法案：規範AI使用。
  • 網路與資訊系統指令2（NIS2）：確保關鍵基礎設施的安全和事件管理最佳實踐。

中心網際網路安全（CIS）基準

CIS基準幫助IT部門從安全控制角度衡量其當前的安全狀態以及相關技術組態、攻擊細節和緩解措施。這些控制與最常見的法規框架相對映，如HIPAA、PCI-DSS、ISO 27000等。

  graph TD;
    A[企業] --> B[財務];
    A --> C[產品開發];
    A --> D[售後支援];
    B --> E[HIPAA];
    C --> F[GDPR];
    D --> G[PCI-DSS];

內容解密：

此圖示展示了一個企業如何根據不同部門和活動遵守不同法規標準。財務部門必須遵守HIPAA標準以處理病人記錄；產品開發部門需要遵守GDPR以保護個人資料；售後支援則需要遵守PCI-DSS標準以確保支付卡交易安全。

融入具體案例與資料支援

假設一家美國軟體公司利用AI技術進入醫療領域，提供SaaS和本地化解決方案給全球醫療機構。這家公司需要遵守HIPAA、GDPR、PCI-DSS等多項法規標準。

資料支援：

  • HIPAA違規罰款：平均每次違規罰款高達40萬美元。
  • GDPR違規罰款：最高可達歐元4%的全球年營收或2000萬歐元（以較高者為準）。
  • PCI-DSS違規成本：平均每次違規成本為4萬至12萬美元。

技術選型分析及未來趨勢

隨著數位轉型加速，未來趨勢將包括更多自動化工具和AI技術來提高合規性和資安風險管理。企業需積極擁抱這些技術，以便在全球市場中保持競爭力。

個人獨特見解

玄貓認為，未來企業必須將合規性視為一種機會而非負擔。透過引入先進技術和平台如CIS基準和NIST框架，企業可以建立更強大且靈活的資安防禦系統。此外，定期進行模擬演練和員工培訓是確保組織在面對真實威脅時能夠迅速反應的一個重要因素。

Kubernetes 秘密管理的安全、稽核及合規性控制

在 Kubernetes 的世界裡，CIS Benchmarks 是一套非常重要的安全基準，版本 1.7.0 在撰寫本文時為最新。以下是針對 Secret 管理的控制措施概述，這些措施可以幫助我們確保 Kubernetes Secret 的安全性。

確保使用 –encryption-provider-config 引數

首先，我們需要確保 Kubernetes 的 etcd key-value store 是加密的。這可以透過設定 –encryption-provider-config 引數來實作。這個引數的設定可以確保 Secret 資料在儲存時是加密的，從而防止未經授權的存取。

內容解密：

  • 作用：此控制項旨在透過加密 etcd 的 key-value store 來保護 Secret 資料。
  • 實作：使用 –encryption-provider-config 引數來設定加密提供者。
  • 技術選型考量：選擇適當的加密演算法（如 aesgcm 或 kms）來確保資料的安全性。
  • 潛在改進點：定期更新加密演算法，以應對新的安全威脅。

組態加密提供者

接下來，我們需要確保加密提供者是正確組態的。這包括選擇適當的加密演算法，如 aesgcm、aescbc 或 kms。這些演算法可以確保 Secret 資料在傳輸和儲存過程中的安全性。

內容解密：

  • 作用：此控制項確保使用適當的加密演算法來保護 Secret 資料。
  • 實作：檢查並確認 –encryption-provider-config 引數中設定的加密提供者。
  • 技術選型考量：根據企業的安全需求選擇合適的加密演算法。
  • 潛在改進點：定期測試和更新加密演算法，以應對新的安全威脅。

建立稽核策略

為了確保 Secret 資料的安全性，我們需要建立一個稽核策略。這個策略應該能夠追蹤對 Secret、ConfigMap 和 TokenReview 的存取、修改和使用情況。

內容解密：

  • 作用：此控制項旨在透過稽核策略來監控和記錄對 Secret 資料的操作。
  • 實作：設定一個詳細的稽核策略，並定期檢查稽核日誌。
  • 技術選型考量：選擇適當的稽核工具和日誌管理系統。
  • 潛在改進點：增加稽核策略的詳細程度，以捕捉更多可能的安全事件。

優先使用檔案方式存取 Secret

為了避免將 Secret 作為環境變數注入 Pod 中，我們應該優先使用檔案方式來存取 Secret。這樣可以減少節點記憶體和應用程式日誌中的潛在洩露風險。

內容解密：

  • 作用：此控制項旨在減少將 Secret 作為環境變數注入 Pod 中的風險。
  • 實作：將 Secret 作為檔案掛載到 Pod 中，而不是作為環境變數。
  • 技術選型考量：選擇合適的檔案掛載方式，以確保資料的安全性。
  • 潛在改進點：定期檢查和更新檔案掛載方式，以應對新的安全威脅。

考慮外部秘密儲存

除了內建的 etcd key-value store，我們還可以考慮使用外部秘密儲存解決方案。這些解決方案通常由第三方提供，並且可以提供更高層次的安全性和靈活性。

內容解密：

  • 作用：此控制項旨在透過外部秘密儲存解決方案來提高 Secret 資料的安全性。
  • 實作：選擇並組態適當的外部秘密儲存解決方案。
  • 技術選型考量：評估不同外部秘密儲存解決方案的優缺點。
  • 潛在改進點：定期測試和更新外部秘密儲存解決方案，以應對新的安全威脅。

必須符合之合規標準

涵蓋物理層面安全控制

有些法規可能會包括物理層面的安全控制，例如資料中心和實體伺服器存取等。這些控制雖然不包含在 CIS Benchmarks 中，但它們與我們先前討論過的一些安全分析是相關聯的。

更新安裝安全架構圖

現在是時候更新我們之前討論過的一些安裝安全架構圖了。這些圖表應該包括代表持續努力以符合法規義務和標準的一些新層次。這些層次可以幫助我們持續進行發現、評估、分析和執行（緩解），從而定義和改進目前的安全和合規性狀態。

玄貓

玄貓

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