Kubernetes 原生加密方案深度解析與實踐

– 13 分鐘閱讀

Kubernetes 提供多種原生加密方案，從簡單的 Identity 提供者到根據 aesgcm 和 aescbc 的加密，以及更進階的外部 KMS 整合。Identity 提供者直接將 Secret 存放於 etcd，安全性較低，適用於開發測試環境。aesgcm 和 aescbc 使用 AES 加密演算法，安全性中等，但需要謹慎管理加金鑰並定期輪換。KMS 提供者則利用外部金鑰管理服務，安全性更高，適合生產環境，特別是 KMSv2 版本，藉由 DEK 快取機制大幅提升效能。實務上，選擇合適的加密方案需考量安全性需求、效能影響以及管理複雜度。

除了 Kubernetes 原生加密機制，etcd 資料函式庫的安全性也至關重要。由於 etcd 儲存所有 Kubernetes 叢集的狀態資訊，保護 etcd 的安全等同於保護整個叢集的安全。除了網路層面的安全防護，硬碟層級的加密也是必要的。全磁碟加密（FDE）可以防止磁碟被盜取後資料洩露，而檔案系統加密（例如 LUKS）則可以提供更細粒度的資料保護。建議結合 FDE 和 LUKS 技術，並搭配 Auditd 和 Selinux 等工具進行監控和存取控制，才能最大程度地保障 etcd 資料安全。此外，Linux 系統本身的安全性也需要加強，例如使用 SCAP 等工具進行安全稽核和強化，並遵循 CIS Benchmarking 和 NIST 等安全規範。

Kubernetes 原生加密方案解析

Kubernetes 原生加密（Kubernetes-native encryption）是一個強大的功能，能夠保護敏感資料，避免未經授權的存取。這裡我們將探討 Kubernetes 原生加密的提供者選項，並詳細分析其工作原理及應用場景。

獨立原生加密

Kubernetes 原生加密可以在不依賴任何額外軟體的情況下啟用，無論是控制平面還是外部 Kubernetes 叢集。

Identity 提供者

Identity 提供者是 kube-apiserver 的預設組態，意思是在將資料儲存到 etcd 之前，不會對任何資料進行加密處理。這種方式等同於不對任何 Secret 資料進行加密。

玄貓認為，這種方法雖然簡單，但無法真正保護敏感資料。在實務中，我們需要更高的安全性來保護 Secret 資料。以下是 Identity 提供者的工作流程：

  1. 使用者建立一個 Secret 物件。
  2. kube-apiserver 檢查 EncryptionConfiguration 提供者列表。
  3. 提供者指向 identity。
  4. kube-apiserver 將 base64 編碼的 Secret 直接儲存到 etcd 中。
  graph TD
    A[使用者建立 Secret] --> B[kube-apiserver 檢查 EncryptionConfiguration]
    B --> C[指向 identity]
    C --> D[kube-apiserver 將 Secret 儲存到 etcd]

此圖示展示了 Identity 提供者的工作流程。使用者建立 Secret 後，kube-apiserver 會檢查 EncryptionConfiguration 組態並將 Secret 直接儲存到 etcd 中。

aesgcm 和 aescbc 提供者

aesgcm 和 aescbc 提供者使用 Golang 的 AES 加密函式庫來對列出的資源進行加密處理。這些提供者使用高階加密標準（AES），並提供兩種模式：CBC 和 GCM。CBC 模式雖然快速但相對弱一些，而 GCM 模式在實施金鑰輪換時更快且安全。

aesgcm 和 aescbc 的組態與使用

aesgcm 和 aescbc 的組態相對簡單：

  1. 生成一個 32 位元組（或更多）隨機加金鑰，並以 base64 編碼。
  2. 在 EncryptionConfiguration 組態檔案中設定所選的提供者（aescbc 或 aesgcm）。
  3. 參照該鑰。
  4. 若未啟用自動過載，則重啟 kube-apiserver。

以下是一個範例組態：

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
providers:
- aesgcm:
    keys:
    - name: key-20230616
      secret: DlZbD9Vc9ADLjAxKBaWxoevlKdsMMIY68DxQZVabJM8=
- identity: {}

  graph TD
    A[使用者建立 Secret] --> B[kube-apiserver 檢查 EncryptionConfiguration]
    B --> C[指向 aesgcm]
    C --> D[kube-apiserver 加密資料]
    D --> E[kube-apiserver 將加密後的 Secret 儲存到 etcd]

此圖示展示了 aesgcm/aescbc 提供者的工作流程。使用者建立 Secret 後，kube-apiserver 會檢查 EncryptionConfiguration 組態並使用指定的加金鑰進行加密處理，然後將加密後的 Secret 儲存到 etcd 中。

加金鑰管理與安全性考量

aesgcm 和 aescbc 提供者雖然易於實施，但也存在一些安全風險。這些提供者使用 base64 編碼的加金鑰並儲存在本地檔案系統中。若系統或磁碟/檔案系統遭到突破，惡意攻擊者可能會取得這些加金鑰並解密資料。此外，這些提供者還可能面臨填充攻擊、生日攻擊等多種漏洞。因此，我們需要採取適當的自動化鑰輪換策略來增強安全性。

內容解密：

Identity 提供者
  • 工作原理：Identity 提供者不對任何資料進行加密處理，直接將 base64 編碼的 Secret 儲存在 etcd 中。
  • 應用場景：適合於開發或測試環境中，不需要高度安全性保護的情況下使用。
  • 技術選型考量：由於沒有真正的加密操作，因此不適合生產環境。
  • 實務錯誤教訓：實務中發現，即使在開發環境中使用 Identity 提供者也可能帶來資料洩露風險。
aesgcm 和 aescbc 提供者
  • 工作原理：aesgcm 和 aescbc 提供者使用 AES 加密函式庫對列出的資源進行加密處理。
  • 應用場景：適合於需要簡單且快速的資料保護需求。
  • 技術選型考量：由於鑰管理和安全性問題，需要採取自動化鑰輪換策略和其他安全措施。
  • 實務錯誤教訓：曾經因為未及時輪換鑰而導致資料被破解。

外部元件輔助的原生加密

除了內部提供者外，Kubernetes 原生加密還可以透過外部元件來實作更高的安全性。以下我們將探討如何利用外部 KMS（Key Management Service）來進一步保護敏感資料。

KMS 提供者

KMS 提供者透過呼叫外部 KMS（如 Azure Key Vault、HashiCorp Vault 或 AWS KMS）來實作信封加密方案。這種方案使用兩個鑰：

  1. 資料加金鑰（DEK）：用於加密列出資源中的資料負載。DEK 在 kube-apiserver 本地生成並且 Kubernetes 叢集關聯。
  2. 鑰加金鑰（KEK）：用於加密 DEK。KEK 在遠端 KMS 上生成和託管。
KMSv1 與 KMSv2 的區別

Kubernetes 專案引入了 KMSv2 作為最新版本的 KMS 提供者。雖然高層次功能相同，但兩者在設計和實作上有所不同：

  • KMSv1：每次建立 Secret 物件時都會生成專屬 DEK，並透過 KEK 加密 DEK。這種方式在處理大規模 Kubernetes 叢集時會影響效能。
  • KMSv2：kube-apiserver 在啟動時（或重新載入時）生成 DEK，並透過遠端 KEK 加密 DEK。DEK 則被快取在記憶體中進行加/解密操作，僅在重啟或輪換鑰時才呼叫 KMS 。這種設計大幅提升了大規模叢集下的效能和穩定性。
  graph TD
    A[使用者建立 Secret] --> B[kube-apiserver 檢查 EncryptionConfiguration]
    B --> C[指向 KMSv2]
    C --> D[kube-apiserver 生成 DEK 或從快取中取得 DEK]
    D --> E[kube-apiserver 加/解密資料]

此圖示展示了 KMSv2 的工作流程。使用者建立 Secret 後，kube-apiserver 會檢查 EncryptionConfiguration 組態並從快取中取得 DEK 或新生成 DEK ，然後進行加/解密操作。

內容解密：

KMS 提供者
  • 工作原理：KMS 提供者透過呼叫外部 KMS 來實作信封加密方案。
  • 應用場景：適合需要高度安全性保護且具有多租戶需求的企業級應用。
  • 技術選型考量：需選擇可靠且具有良好安全記錄的 KMS 做為遠端服務提供商。
  • 實務錯誤教訓：曾經因為 KMS 問題而導致整個叢集無法正常執行。

Kubernetes 原生加密：深入解析與實踐

在現代雲端環境中，資料安全是每個技術人員最關心的議題之一。Kubernetes 作為目前最流行的容器協調平台，其內建的加密功能能夠有效保護敏感資料，特別是 Secret 和 ConfigMap 等物件。以下將詳細探討 Kubernetes 原生加密的實作方式、組態複雜性及其應用場景。

Kubernetes 原生加密流程

Kubernetes 原生加密流程主要涉及以下幾個步驟：

  1. 資料加密準備：當 Kubernetes API 伺服器（kube-apiserver）接收到需要加密的資料時，會先產生一個資料加密金鑰（Data Encryption Key, DEK）。

  2. DEK 加密：DEK 會被送往外部金鑰管理系統（Key Management System, KMS）進行加密，這個過程需要一個金鑰加密金鑰（Key Encryption Key, KEK）。

  3. KEK 存取：KMS 使用 KEK 加密 DEK，然後將加密後的 DEK 傳回給 kube-apiserver。

  4. DEK 儲存：kube-apiserver 將加密後的 DEK 儲存在 etcd 中。

  5. 資料加密：kube-apiserver 使用 DEK 加密資料的負載部分，然後將加密後的 Secret 儲存在 etcd 中。

KMS 提供者外掛組態

KMS 提供者外掛增加了組態上的複雜性，但這種方法符合所有要求外部金鑰管理的法規，並且涵蓋了大部分的安全需求。以下是一些常見的 KMS 提供者外掛：

  • HashiCorp Vault：提供強大的金鑰管理功能。
  • Azure Key Vault：適合在 Azure 雲端環境中使用。
  • AWS KMS：適合在 AWS 雲端環境中使用。

這些外掛通常會佈署在控制平面節點上，透過本地 UNIX Socket 與 kube-apiserver 直接互動，避免了網路暴露帶來的潛在安全風險。例如，Trousseau 是一個社群專案，提供了與 HashiCorp Vault、Azure Key Vault 和 AWS KMS 的整合能力。

組態例項

在 Git 儲存函式庫中的 ch03 資料夾中，你可以找到一個詳細的教學，指導如何使用 Podman 或 Docker 佈署一個新的 Kind 叢集。這個教學包括如何組態 kube-apiserver 的特定旗標以及如何掛載組態檔案到 Pod 中。這些步驟將幫助你在未來與其他 Kubernetes 分佈版本進行互動。

加密秘密資料

在 Kubernetes 中，Secret 是用來儲存敏感資料的物件。當你建立或更新 Secret 時，kube-apiserver 會根據組態中的提供者列表來決定如何處理這些資料。

提供者順序

  1. 建立新 Secret：當建立新 Secret 時，kube-apiserver 會使用第一個列出的提供者來進行加密。如果提供者是 identity（即不進行任何加密），則不會對資料進行加密。

  2. 讀取現有 Secret：當讀取現有 Secret 時，kube-apiserver 會檢查 Secret 標頭以確定使用的 KMS 提供者、版本和相關金鑰。如果找到比對項，則嘗試解密資料；如果沒有比對項，則傳回錯誤。

  3. 替換現有 Secret：所有現有 Secret 可以透過更改提供者列表順序來替換為新版本。例如，可以引入 aesgcm 提供者並替換所有未加密的 Secret。

深入保護 etcd

除了應用層面的加密外，etcd 本身也需要進一步保護。以下是一些需要考慮的安全風險及其緩解措施：

  • 本地佈署或雲端佈署：無論是自行佈署還是使用雲端服務，etcd 的資料檔案都可能暴露於攻擊者面前。確保這些檔案受到適當的保護是非常重要的。
  • 管理 Kubernetes 例項：當使用雲端提供商提供的管理 Kubernetes 例項時，控制平面由提供商負責。但是，不同服務之間可能存在差異，因此需要仔細檢查它們如何處理於休息狀態下的資料加密。

安全硬化參考資源

為了進一步增強系統安全性，以下書籍可以作為參考：

  • 《Mastering Linux Security and Hardening》由 Donald A. Tevault 撰寫。
  • 《Practical Linux Security Cookbook》由 Tajinder Kalsi 撰寫。

這些書籍提供了豐富的實踐經驗和技巧，幫助你構建更安全的 Linux 和 Kubernetes 環境。

Kubernetes 原生方式的秘密加密

Linux 系統硬化

Linux 系統硬化的藝術在於將存取欺詐的風險降至零。在此情境下，這意味著不允許透過作業系統對 etcd 資料檔案進行遠端存取。值得注意的是，Linux 發行版提供了安全組態檔案的概念，利用像是 SCAP 這樣的標準，並在系統安裝的早期階段進行相關的強化。這些組態檔案根據組織的需求，提供一系列行業專屬的組態檔案，例如 CIS Benchmarking 和 NIST，在佈署時幫助組態作業系統以符合所選擇的規範。這些規則在使用圖形使用者介面時會有詳細解釋，或可以在供應商檔案中找到。

不論選擇哪種安裝方式——文字、圖形或 kickstart 安裝——都能從這些強化自動化中受益。這種方法有助於減輕營運團隊的壓力。透過自動化相關的 100+ 具體組態規則，可以輕鬆地遵循像是 PCI-DSS 這樣的規範要求，而不需要閱讀其 360 頁的要求檔案。這將補充 Red Hat 安全強化參考的 190+ 頁內容。

一旦系統以適當的安全策略佈署完成並符合組織行業需求，就可以使用 OpenSCAP bench 工具套件來掃描整個安裝基礎設施，提供以下內容：

  • 每個 Linux 發行版的定製審核
  • 包含風險評分系統的可分享審核檔案
  • 最常見工具套件（Shell 指令碼、Puppet、Ansible 等）的緩解策略

參考資料如下：

  • OpenSCAP：https://www.open-scap.org/
  • OpenSCAP PCI-DSS 規格：http://static.open-scap.org/ssg-guides/ssg-rhel9-guide-pci-dss.html
  • Red Hat Enterprise Linux 安全強化：https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/security_hardening

Linux 系統硬化包括安裝前後的任務。為避免重新佈署作業系統，請在安裝過程中啟用適當的安全組態檔案和磁碟加密。大多數 Linux 發行版，例如 Red Hat Enterprise Linux 9，都有一個圖形使用者介面來設定特定的安全組態檔案並提供必需的組態變更清單以符合所選擇的組態檔案。

再進一步保護 etcd

GitHub 儲存函式庫中 ch03 資料夾有兩個範例，展示瞭如何使用安裝者圖形介面和 kickstart 檔案來硬化 Linux 系統。

Linux 資料加密

盜取磁碟或伺服器是一個嚴重問題，且發生得比我們所能想像得更頻繁。但這不僅僅是本地佈署基礎架構；雲端虛擬磁碟也可能因為超級管理程式漏洞而被盜取，意味著所有您關鍵業務系統中的憑證也會洩露。

由於 etcd（目前）並未提供任何加密功能，因此將儲存在控制平面節點檔案系統中的資料檔案可以被存取並輕鬆讀取以還原 Secret 物件負載。這意味著任何物理佈署情境（無論是在本地或邊緣計算），當攻擊者盜取磁碟或節點時都會產生安全風險。

為瞭解決此問題，磁碟和檔案系統都需要加密。為什麼需要兩者？雖然全磁碟加密（FDE）看起來似乎是一個簡單解決方案，但已有各種攻擊成功地無需盜取整個系統即可存取資料。增加檔案系統加密將降低資料洩露包括用於存取雲端、應用程式和儲存帳戶 Secret 物件的風險。

全磁碟加密

FDE（全磁碟加密），也稱為自動加密磁碟（SED），是一個有趣的起點來提供完全從主機上移除加密處理程式（降低攻擊面），對作業系統和應用程式透明（無需維護任何驅動或函式庫）。FDE 保證高度相容性、可維護性和跨不同硬體和軟體組合之間可攜性。

所有 FDE/SED 磁碟都附帶零長度驗證金鑰/密碼以簡化初始設定（特別是如果沒有使用者需求）。當定義驗證金鑰或密碼時，DEK（資料加密金鑰）會儲存在磁碟上並由所定義的自訂使用者金鑰保護。

此工作流程的優點如下：

  • 防止物理磁碟被盜
  • 在開機之前保護資料
  • 提供強制事件和合規目的下重新金鑰選項

缺點如下：

  • 引導需要使用者輸入驗證金鑰
  • 損失金鑰意味著損失資料
  • 駭客攻擊仍可能發生

檔案系統加密

除了全磁碟加密外，檔案系統層級也需要額外保護。LUKS 是常見且廣泛支援的一種方式來實作 Linux 檔案系統加密。LUKS 提供了強大且靈活的一套工具來管理加密和解密過程。

LUKS 的主要特點包括：

  • 支援多種加密演算法（如 AES）
  • 提供金鑰管理機制
  • 支援快照功能
  • 與多種檔案系統（如 ext4、XFS）相容

要在 LUKS 上進行初始設定，請遵循以下步驟：

  1. 安裝 cryptsetup 工具。
  2. 建立 LUKS 加密容器： 
    cryptsetup luksFormat /dev/sdX
  3. 初始化 LUKS 加密容器： 
    cryptsetup luksOpen /dev/sdX my_encrypted_disk
  4. 在 LUKS 加密容器上建立檔案系統： 
    mkfs.ext4 /dev/mapper/my_encrypted_disk
  5. 掛載加密容器： 
    mount /dev/mapper/my_encrypted_disk /mnt/my_encrypted_fs
小段落標題：如何管理 LUKS 加密容器？

為了確保資料安全性，您可以使用 LUKS 的各種功能來管理您的加密容器：

  • 更改 LUKS 密碼： 
    cryptsetup luksChangeKey /dev/sdX
  • 封閉 LUKS 加密容器： 
    cryptsetup luksClose my_encrypted_disk
  • 檢查 LUKS 加密容器狀態： 
    cryptsetup luksDump /dev/sdX

檔案資料函式庫分析工具

結合 FDE 和 LUKS 的混合方法能夠提供額外的一層安全性。使用像是 Auditd 或 Selinux 的工具可以監控和記錄對敏感資料存取行為。

小段落標題：Auditd 與 Selinux 工具

Auditd 是一個強大且靈活的監控工具，能夠捕捉和記錄系統事件。以下是一些 Auditd 的基本命令：

# 啟動 Auditd：
service auditd start

# 停止 Auditd：
service auditd stop

# 檢視 Audit 日誌：
ausearch -m AVC

# 檢視最近稽核事件：
aureport -f

Selinux 是一個強制存取控制機制，能夠限制使用者和程式對敏感資料存取行為。以下是一些 Selinux 的基本命令：

# 啟動 Selinux：
setenforce Enforcing

# 停止 Selinux：
setenforce Permissive

# 檢視 Selinux 狀態：
sestatus -v

####### 問答環節：


#### 小段落標題：常見問題與解答

1. **如何確保我的資料在開機之前就已經被保護？**
   - 採用 FDE 技術可以在開機之前保護您的資料。

2. **如果我忘記了 LUKS 的密碼該怎麼辦？**
   - 若您忘記了 LUKS 的密碼，則無法還原您的資料。因此建議您定期備份重要資料並保管好您的備份金鑰。

3. **如何確保我的磁碟在被盜之後仍然安全？**
   - 採用 FDE 和 LUKS 技術可以確保即使磁碟被盜取也不會洩露敏感資訊。

雙重強化：結合 FDE 和 LUKS 技術解決方案

玄貓認為兩者均應考慮採用完成雙重強化作業以達到最高等級之安全性！

概念圖示：

  graph TD;
    A[FDE] --> B[資料保護];
    A --> C[引導時間保護];
    D[LUKS] --> E[金鑰管理];
    D --> F[快照功能];
    G[Auditd] --> H[事件記錄];
    I[Selinux] --> J[存取控制];

此圖示展示了 FDE 和 LUKS 技術如何共同作用來增強資料安全性以及 Auditd 和 Selinux 提供額外的一層監控和存取控制。

概念圖示解釋：

  1. FDE：全磁碟加密提供了資料保護以及引導時間保護。
  2. LUKS：LUKS 提供了金鑰管理以及快照功能。
  3. Auditd：Auditd 用於事件記錄。
  4. Selinux：Selinux 用於存取控制。

總結來說，結合這些技術可以顯著提升資料安全性並防止未經授權存取。

玄貓

玄貓

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