返回文章列表
玄貓（BlackCat）

Kubernetes 安全與可觀測性最佳策略

本文探討 Kubernetes 安全與可觀測性的最佳策略，涵蓋異常檢測、安全框架、威脅矩陣、叢集強化、主機安全、網路安全、憑證輪換、靜態加密、稽核日誌和雲端後設資料存取限制等關鍵導向，提供全面的 Kubernetes 安全防護。

Kubernetes 資安
安全 可觀測性 異常檢測 MITRE ATT&CK 威脅矩陣 RBAC

Kubernetes 環境的安全性與可觀測性密不可分。透過可觀測性工具收集的指標資料，可以訓練機器學習模型進行異常檢測，及早發現潛在威脅。此外，安全框架如 MITRE ATT&CK 和 Kubernetes 威脅矩陣，能幫助理解攻擊模式並建立有效的防禦策略。本文也探討了主機強化、叢集強化和網路安全等多個層面的安全措施，涵蓋作業系統選擇、非必要程式移除、防火牆設定、網路外掛整合等最佳實踐。最後，文章強調了靜態加密、憑證輪換、稽核日誌記錄以及雲端後設資料 API 存取限制的重要性，並提供了程式碼範例和圖表說明，以協助讀者更好地理解和實施 Kubernetes 安全策略。

Kubernetes 安全與可觀測性策略：整體防禦的重要性

在動態環境如 Kubernetes 中，應用程式的安全佈署需要同時考慮安全性和可觀測性。舉例來說，我們需要「觀察」叢集以找到最佳方式來實施控制措施以確保叢集安全。Kubernetes 作為一個排程引擎，因其宣告式特性而被廣泛採用，允許使用者指定更高層級的結果。

機器學習與異常檢測

機器學習是一種技術，系統能夠從一段時間內的資料中匯出模式。其輸出是一個機器學習模型，可以用於進行預測並檢測真實資料中的偏差。我們建議考慮將根據機器學習的異常檢測應用於各種指標，以檢測異常活動。一個簡單而有效的方法是將根據機器學習的技術（如基準測試）應用於個別指標。這樣，您就不必擔心為每個指標設定規則和閾值；系統會為您完成這項工作，並將偏差報告為異常。

程式碼範例：異常檢測模型訓練

from sklearn.ensemble import IsolationForest
import pandas as pd

# 載入資料
data = pd.read_csv('metrics.csv')

# 訓練 Isolation Forest 模型
model = IsolationForest(contamination=0.1)
model.fit(data)

# 預測異常
data['anomaly'] = model.predict(data)

#### 內容解密：
此程式碼使用 Isolation Forest 演算法進行異常檢測。首先，我們載入包含指標資料的 CSV 檔案。然後，使用 `IsolationForest` 類別初始化模型，並設定 `contamination` 引數來定義資料中異常值的比例。接著，呼叫 `fit` 方法訓練模型。最後，使用訓練好的模型對資料進行預測，將結果儲存在 `anomaly` 列中。其中，`-1` 表示異常，`1` 表示正常資料。

安全框架

我們希望您瞭解提供行業通用方法和術語的安全框架，用於最佳安全實踐。安全框架是理解攻擊技術和最佳防禦實踐的好方法。您應該使用它們來建立和驗證您的安全策略。

MITRE ATT&CK 框架

MITRE 是一個根據真實世界網路攻擊觀察的敵對策略和技術知識函式庫。MITRE ATT&CK 矩陣對於企業非常有用，因為它為網路安全殺傷鏈的每個階段提供了分類別的策略和技術。殺傷鏈是對網路攻擊階段的描述，用於建立有效的防禦措施。

#### MITRE ATT&CK 矩陣階段

Kubernetes 的威脅矩陣

另一個框架是 Kubernetes 特有的威脅矩陣，它是通用 MITRE 攻擊矩陣的應用。它由微軟團隊根據安全研究和真實世界攻擊發布。這是另一個用於建立和驗證您的安全策略的優秀資源。

安全與可觀測性的協同作用

在 Kubernetes 這樣的動態環境中，透過同時考慮安全性和可觀測性，可以實作應用程式的安全佈署。首先，您需要「觀察」您的叢集，以找到實施控制的最佳方式來保護叢集。

強化 Kubernetes 基礎設施安全

許多 Kubernetes 設定在預設情況下是不安全的。在本章中，我們將探討如何透過基礎設施層級的安全措施來強化 Kubernetes。透過主機強化、叢集強化和網路安全三個層面的結合，可以顯著提升 Kubernetes 的安全性。本章的內容同樣適用於自行託管的 Kubernetes 叢集和管理型 Kubernetes 叢集。

主機強化

主機強化涉及作業系統的選擇、避免在主機上執行非必要的程式，以及根據主機的防火牆設定。

叢集強化

叢集強化涵蓋了一系列的組態和政策設定，用於強化控制平面的安全性，包括組態 TLS 證書、鎖定 Kubernetes 資料儲存、靜態加密 Secret、憑證輪換，以及使用者認證和存取控制。

網路安全

網路安全涉及將叢集與周圍的基礎設施進行安全整合，特別是控制哪些網路互動被允許，用於控制平面、主機和工作負載流量。

讓我們進一步探討每個層面的細節，以建立一個安全的 Kubernetes 叢集基礎設施。

主機強化

一個安全的主機是建立安全 Kubernetes 叢集的重要根本。當我們談論主機時，我們關注的是組成 Kubernetes 叢集的工作負載。現在，我們將探討一些技術，以確保主機具有強大的安全態勢。

作業系統的選擇

許多企業在所有基礎設施上都標準化使用單一作業系統，這意味著作業系統的選擇可能已經被決定。然而，如果有選擇作業系統的靈活性，那麼考慮使用專為容器設計的現代不可變 Linux 發行版是值得的。這些發行版具有以下優勢：

  • 它們通常具有較新的核心，包含了最新的漏洞修復以及較新的技術（如 eBPF）的最新實作，可以被 Kubernetes 網路和安全監控工具所利用。
  • 它們被設計為不可變的，這為安全性帶來了額外的好處。在這種情況下，不可變性意味著根檔案系統被鎖定，應用程式無法更改。只有使用容器才能安裝應用程式。這將應用程式與根檔案系統隔離，顯著降低了惡意應用程式破壞主機的能力。
  • 它們通常包含自我更新到新版本的功能，上游版本針對快速發布以解決安全漏洞進行了最佳化。

內容解密：

選擇合適的作業系統對於確保主機安全至關重要。現代不可變 Linux 發行版（如 Flatcar Container Linux 和 Bottlerocket）因其安全性而受到推薦。它們具有較新的核心、不可變的設計以及自我更新的能力，這些都有助於提高安全性。

非必要程式

每個執行的主機程式都可能成為駭客的攻擊向量。從安全的角度來看，最好移除任何預設執行的非必要程式。如果某個程式對於成功執行 Kubernetes、管理主機或確保主機安全不是必要的，那麼最好不要執行它。如何停用該程式將取決於您的特定設定（例如，systemd 組態變更或從 /etc/init.d/ 移除初始化指令碼）。

內容解密：

停用非必要的程式可以減少潛在的攻擊面。如果使用的是為容器最佳化過的不可變 Linux 發行版，那麼非必要的程式已經被消除，您只能以容器的形式執行額外的程式或應用程式。

根據主機的防火牆設定

為了進一步鎖定託管 Kubernetes 的伺服器或虛擬機器，可以在主機上組態本地防火牆規則，以限制哪些 IP 位址範圍和埠可以與主機互動。

內容解密：

根據所使用的作業系統，可以使用傳統的 Linux 管理工具（如 iptables 規則或 firewalld 組態）來實作這一點。重要的是要確保這些規則與 Kubernetes 控制平面和所計劃使用的 Kubernetes 網路外掛相容，以免阻擋 Kubernetes 控制平面、Pod 網路或 Pod 網路控制平面。

網路外掛與防火牆設定的整合

幸運的是，一些 Kubernetes 網路外掛可以幫助解決這個問題。例如，Weave Net、Kube-router 和 Calico 等多個 Kubernetes 網路外掛都包含了應用網路策略的功能。您應該檢視這些外掛，並選擇一個也支援將網路策略應用於主機本身（而不僅僅是 Kubernetes Pod）的外掛。這使得保護叢集中的主機變得更加簡單，並且在很大程度上與作業系統無關，包括與不可變 Linux 發行版的相容性。

內容解密：

選擇正確的網路外掛對於簡化主機的安全性至關重要。像 Weave Net、Kube-router 和 Calico 這樣的外掛提供了網路策略功能，並且能夠將這些策略應用於主機，從而增強了叢集的安全性。

Kubernetes 叢集安全強化

Kubernetes 預設設定並不安全，因此除了強化叢集節點的安全性之外，還需要強化叢集本身的安全性。這可以透過結合 Kubernetes 元件和組態管理、身分驗證和根據角色的存取控制（RBAC），以及保持叢集更新至最新版本的 Kubernetes，以確保叢集具備最新的漏洞修復。

保護 Kubernetes 資料儲存（etcd）

Kubernetes 使用 etcd 作為其主要資料儲存，儲存所有叢集組態和所需狀態。存取 etcd 資料儲存基本上等同於獲得所有節點的 root 登入許可權。如果惡意攻擊者獲得 etcd 資料儲存的存取許可權，幾乎所有在叢集中實施的其他安全措施都將失效。他們將完全控制叢集，包括在任何節點上以提升的許可權執行任意容器。

保護 etcd 的主要方法是使用 etcd 本身提供的安全功能。這些功能根據 x509 公鑰基礎設施（PKI），使用金鑰和憑證的組合。它們確保所有傳輸中的資料都使用 TLS 加密，並且所有存取都受到強大憑證的限制。最好為 etcd 設定兩套憑證（金鑰對和憑證），一套用於 etcd 例項之間的對等通訊，另一套用於來自 Kubernetes API 的客戶端通訊。

程式碼範例：etcd 組態

apiVersion: v1
kind: Config
clusters:
- name: my-etcd-cluster
  cluster:
    endpoints:
    - https://etcd-cluster:2379
    certificate-authority: /path/to/ca.crt
users:
- name: my-etcd-user
  user:
    client-certificate: /path/to/client.crt
    client-key: /path/to/client.key
contexts:
- context:
    cluster: my-etcd-cluster
    user: my-etcd-user
  name: my-etcd-context
current-context: my-etcd-context

內容解密：

  • apiVersion 和 kind 定義了組態檔案的版本和型別。
  • clusters 部分定義了 etcd 叢集的端點和憑證授權單位。
  • users 部分定義了用於存取 etcd 的客戶端憑證和金鑰。
  • contexts 部分定義了叢集和使用者的上下文，並指定了當前上下文。

一旦 etcd 組態正確，只有具有有效憑證的客戶端才能存取它。然後，您需要組態 Kubernetes API 伺服器使用客戶端憑證、金鑰和憑證授權單位，以便它可以存取 etcd。

保護 Kubernetes API 伺服器

在 etcd 資料儲存之上，下一個需要保護的是 Kubernetes API 伺服器。與 etcd 一樣，這可以使用 x509 PKI 和 TLS 來完成。具體的引導叢集的方法取決於您使用的 Kubernetes 安裝方法，但大多數方法都包括建立所需的金鑰和憑證並將它們分發到其他 Kubernetes 叢集元件的步驟。

加密 Kubernetes Secret 資料

Kubernetes 可以組態為加密儲存在 etcd 中的敏感資料，例如 Kubernetes Secret。這可以保護 Secret 資料免受可能獲得 etcd 存取許可權或離線 etcd 副本（如離線備份）的攻擊者的侵害。

預設情況下，Kubernetes 不會加密靜態 Secret 資料。當啟用加密時，它只會在將 Secret 資料寫入 etcd 時進行加密。因此，在啟用靜態加密時，重寫所有 Secret 資料（透過標準的 kubectl apply 或 update 命令）以觸發它們在 etcd 中的加密是非常重要的。

Kubernetes 支援多種加密提供者。選擇根據加密最佳實踐的推薦加密提供者非常重要。目前主要的推薦選擇是使用 32 位元組金鑰的 AES-CBC 與根據 PKCS #7 的加密。這提供了非常強大的加密，並且相對較快。有兩個不同的提供者支援這種加密。

Kubernetes 叢集安全強化：加密儲存與憑證輪換

Kubernetes 作為現代容器協調平台，其安全性對於企業級應用至關重要。本篇文章將探討 Kubernetes 叢集的安全強化措施，特別是在加密儲存和憑證輪換方面的最佳實踐。

靜態加密：保護 Kubernetes Secret

Kubernetes 提供了靜態加密功能來保護敏感資料，特別是 Secret 物件。靜態加密有兩種主要的實作方式：

  1. 本地提供者（Local Provider）：將加密金鑰儲存在 API 伺服器的本地磁碟上。

    • 優點：實作簡單，無需額外元件。
    • 缺點：若 API 伺服器主機被攻破，所有加密的 Secret 都可能被洩露。

  2. 金鑰管理服務提供者（KMS Provider）：使用外部的金鑰管理服務來管理加密金鑰。

    • 工作原理：採用信封加密（Envelope Encryption）技術，每個 Secret 使用動態生成的資料加密金鑰（DEK）進行加密。DEK 再使用金鑰加密金鑰（KEK）加密，而 KEK 由 KMS 提供並儲存在外部。
    • 優點：KEK 不儲存在叢集內，提高了安全性。
    • 缺點：實作較複雜，需要與外部 KMS 服務整合。

程式碼範例：組態 KMS 提供者

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - kms:
        name: my-kms-provider
        endpoint: unix:///var/run/kms-plugin.sock
        cachesize: 1000
        timeout: 3s

內容解密：

  • apiVersion 和 kind 定義了該組態檔案的版本和型別。
  • resources 指定了需要加密的資源型別，在此例中為 secrets。
  • providers 列出了加密提供者，這裡使用了 kms 提供者。
  • name 和 endpoint 指定了 KMS 外掛程式的名稱和連線端點。
  • cachesize 和 timeout 用於最佳化效能和設定超時時間。

憑證輪換：提高安全性

定期輪換憑證是提高 Kubernetes 叢集安全性的另一個重要措施。短生命週期的憑證可以減少憑證洩露的風險。

輪換機制

  1. 本地提供者：支援多個金鑰，新寫入的 Secret 使用第一個金鑰加密。解密時按順序嘗試金鑰直到成功。

    • 需要重新寫入所有 Secret 以觸發使用最新金鑰的加密。

  2. KMS 提供者：可以輪換 KEK 而無需重新加密所有 Secret，降低了效能影響。

身份驗證與 RBAC

除了程式碼存取控制，Kubernetes 也需要遵循最佳實踐來確保使用者與叢集互動的安全性。這包括：

  • 為每個使用者建立獨立帳戶。
  • 使用 Kubernetes RBAC 授予使用者執行其角色所需的最小許可權。
  • 優先使用群組和角色來管理許可權，而不是直接指派給個別使用者。

圖表說明：RBAC 許可權管理流程

此圖示展示了 Kubernetes 中使用者請求存取資源時的 RBAC 許可權管理流程。

加強 Kubernetes 叢集安全性的最佳實踐

Kubernetes 叢集的安全性至關重要，因為它直接關係到整個系統的安全運作。在本章中，我們將探討多項加強 Kubernetes 基礎設施安全性的最佳實踐，涵蓋認證、雲端後設資料存取限制、稽核日誌記錄以及 Alpha 或 Beta 功能的存取限制等導向。

避免使用靜態憑證

使用靜態憑證（如 Kubernetes 基本驗證或服務帳戶令牌）可能導致安全風險。外部身份驗證提供者通常具有更友好的憑證輪換支援，包括指定密碼強度和輪換頻率時間框架的能力。因此，建議採用外部身份驗證提供者來管理憑證。

程式碼示例：設定 Kubernetes 稽核策略

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

內容解密：

此 YAML 程式碼定義了一個 Kubernetes 稽核策略，設定所有請求的日誌記錄等級為「Metadata」。這意味著系統將記錄請求的後設資料（如使用者、時間戳、資源和動詞等），但不會記錄請求詳細資訊或回應主體。這種設定適合於需要監控叢集活動但又不想記錄過多敏感資訊的場景。

限制雲端後設資料 API 存取

大多數公有雲提供一個可從每個主機/虛擬機器例項本地存取的後設資料 API。這些 API 提供對例項的雲端憑證、IAM 許可權和其他潛在敏感資訊的存取。預設情況下，這些 API 可被執行在例項上的 Kubernetes Pod 存取。任何被攻陷的 Pod 都可能使用這些憑證來提升其在叢集內或對其他雲端服務的預期許可權級別。

為瞭解決這個安全問題，最佳實踐是：

  1. 按照雲端提供者的推薦機制提供所需的 Pod IAM 憑證。例如，Amazon EKS 允許為服務帳戶分配唯一的 IAM 角色，Microsoft Azure 的 AKS 允許為 Pod 分配受控身份，而 Google Cloud 的 GKE 允許透過工作負載身份分配 IAM 許可權。

  2. 限制每個例項的雲端許可權至最低所需，以減少因例項上的後設資料 API 存取被攻陷而產生的影響。

  3. 使用網路策略阻止 Pod 對後設資料 API 的存取。這可以透過每個名稱空間的 Kubernetes 網路策略來實作，或者最好使用 Kubernetes 網路策略的擴充套件，如 Calico 提供的功能，它允許單一網路策略應用於整個叢集。

啟用稽核功能

Kubernetes 稽核提供了一個所有叢集內動作的日誌，具有可組態的範圍和詳細程度。啟用 Kubernetes 稽核日誌記錄並將稽核日誌存檔在安全的服務上，建議作為在需要分析安全漏洞時的重要取證細節來源。

稽核日誌的法醫審查可以幫助回答諸如：

  • 在叢集內發生了什麼、何時、在哪裡？
  • 誰或什麼發起了它，從哪裡發起？

此外，Kubernetes 稽核日誌可以被主動監控，以使用自定義工具或第三方解決方案對可疑活動發出警示。

Kubernetes 稽核日誌流程

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Kubernetes 安全與可觀測性最佳策略

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

此圖示展示了 Kubernetes 稽核日誌中事件的不同階段，包括請求接收、回應開始、回應完成和發生 panic 等。

限制存取 Alpha 或 Beta 功能

每個 Kubernetes 發布版本都包含 Alpha 和 Beta 功能。是否啟用這些功能可以透過為個別 Kubernetes 元件指定功能門控標誌來控制。由於這些功能正在開發中，它們可能具有限制或錯誤，可能導致安全漏洞。因此，最好確保所有不打算使用的 Alpha 和 Beta 功能都被停用。

Alpha 功能通常（但並非總是）預設為停用。它們可能是錯誤的，並且對功能的支援可能會在沒有向後相容性的情況下發生根本變化，或者在未來的版本中被刪除。它們通常建議僅用於測試叢集，而不是生產叢集。

Beta 功能通常預設為啟用。它們仍然可能在版本之間以非向後相容的方式更改，但它們通常被認為是合理測試和啟用的。但是，與任何新功能一樣，由於它們的使用和審查較少，因此它們本質上更可能存在漏洞。