Kubernetes 安全性 Etcd 攻擊與防護策略

etcd 作為 Kubernetes 叢集的核心資料函式庫，儲存了所有重要的組態和狀態資訊，使其成為攻擊者的主要目標。攻擊者可能利用 etcdctl 工具，配合竊取的憑證，直接存取 etcd 資料函式庫，讀取敏感資訊，例如 Secrets 中的服務帳戶 Token。這些 Token 授予了在叢集內執行操作的許可權，一旦洩露，可能導致未經授權的存取和控制。此外，kubelet 的預設設定允許匿名存取其 API，也增加了叢集的風險。攻擊者可利用此漏洞在節點上的 Pod 中執行任意程式碼，造成嚴重的安全威脅。

Kubernetes 資料函式庫 etcd 的攻擊手法與資料外洩風險

Kubernetes 的 etcd 資料函式庫儲存了叢集中的所有組態資料、狀態和後設資料，這些資訊對於叢集的正常運作至關重要。然而，這些敏感資料也成為了攻擊者的目標。本文將探討如何攻擊 Kubernetes 的 etcd 資料函式庫，並分析其安全風險。

存取 etcd 中的資料

要存取 etcd 中的資料，首先需要具備足夠的許可權。預設情況下，etcd 的資料是加密儲存的，並且需要透過特定的憑證和金鑰來進行存取。攻擊者若能取得這些憑證，便可利用 etcdctl 工具來讀取 etcd 中的資料。

使用 etcdctl 工具

etcdctl 是 etcd 官方提供的命令列工具，用於操作 etcd 資料函式庫。當我們具備必要的憑證和金鑰時，可以使用以下命令來檢視 etcd 中的鍵值：

ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/apiserver-etcd-client.crt \
--key=/etc/kubernetes/pki/apiserver-etcd-client.key \
--endpoints=https://127.0.0.1:2379 get /registry/ --prefix | grep -a '/registry' | wc -l

內容解密：

此命令的作用是：

1. 設定 ETCDCTL_API 環境變數為 3，表示使用 etcd 的第三版 API。
2. 指定 CA 憑證、客戶端憑證和客戶端金鑰的路徑，以建立安全的連線。
3. 連線到本地的 etcd 服務（https://127.0.0.1:2379）。
4. 使用 get 命令取得 /registry/ 字首的所有鍵值，並透過 grep 篩選出包含 /registry 的結果，最後統計結果的行數。

檢視 Secrets

在 Kubernetes 中，Secrets 用於儲存敏感資訊，如驗證憑證和金鑰。攻擊者若能存取 etcd，便可進一步檢視這些 Secrets：

ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/apiserver-etcd-client.crt \
--key=/etc/kubernetes/pki/apiserver-etcd-client.key \
--endpoints=https://127.0.0.1:2379 get /registry/secrets/kube-system/weave-net-token-nmb26 | ./auger decode -o yaml

內容解密：

此命令用於：

1. 從 etcd 中取得特定的 Secret（weave-net-token-nmb26）。
2. 將取得的資料透過 auger decode 工具進行解碼，並以 YAML 格式輸出。

資料外洩

取得的 Secret 可能包含重要的驗證資訊，如服務帳戶的 Token。這些 Token 可能具備一定的許可權，例如檢視節點資訊的許可權。若攻擊者能夠利用這些 Token，便可進一步對叢集進行未授權的操作。

風險分析與防範措施

1. 限制 etcd 的存取許可權：確保只有必要的元件能夠存取 etcd，並且使用嚴格的憑證和金鑰管理。
2. 加密敏感資料：即使在 etcd 中，敏感資料也應該被加密儲存，以降低資料外洩的風險。
3. 定期輪換憑證和金鑰：定期更新和輪換用於存取 etcd 的憑證和金鑰，以減少憑證洩露帶來的風險。
4. 監控 etcd 的存取日誌：透過監控 etcd 的存取日誌，可以及時發現異常的存取行為，從而快速應對潛在的安全威脅。

Kubernetes 驗證機制解析與安全防護

Kubernetes 的驗證機制是確保叢集安全的重要環節，主要涉及對 API 伺服器的驗證。本文將探討 Kubernetes 中的兩種主要使用者型別：服務帳戶（Service Accounts）與普通使用者（Normal Users），並分析其驗證方法與相關安全防護措施。

Bearer Tokens 與服務帳戶

服務帳戶主要透過 Bearer Tokens 進行驗證。這些 Tokens 是 JSON Web Tokens（JWT），通常由三部分組成：標頭（Header）、負載（Payload）和簽名（Signature）。以下是一個範例 Token：

eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJ3ZWF2ZS1uZXQtdG9rZW4tbm1iMjYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoid2VhdmUtbmV0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiNjNiMmU2MTItOWJhNC0xMWU5LWJiMGQtMDI0MjMzZGY1OWViIiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOndlYXZlLW5ldCJ9.k0DdIgtmFdfm6nahDMJ9uUIFg2kzOP3YHFaVPxXZE0H53muAssoZFmNcYu1GwkheZByEcYcM9KilIWZmhR2inCONeZ6bELsl0GUpdsKeY-3P1LKHsBYUMVBjwu3WBuGItkrqql0sv3V0BdPiGEwE4NS2zZjlbkwW0vYQjpV5JotxFFy4KV4MlVn4KSRtPx_Gr3I10TsmmBQJzJtrRedcpT3rqU30ONIbKxXWWrbVHSSq34UPtnp5vYNdEVV8dgLwNcacHpoAH-8bfBrUg26Vmw7ymq4F--3XEoB1bNYUe3uh89v0nrsa-apAStlM33pCm1DZqSrNYkC4OnPjmrro4g

內容解密：

此 Bearer Token 經 base64 解碼後，可見其包含以下資訊：

• 發行者（Issuer）：kubernetes/serviceaccount
• 所屬名稱空間（Namespace）：kube-system
• 服務帳戶名稱（Service Account Name）：weave-net
• 服務帳戶 UID：63b2e612-9ba4-11e9-bb0d-024233df59eb
• 主體（Subject）：system:serviceaccount:kube-system:weave-net

這些資訊表明該 Token 的所有者及其許可權範圍。

普通使用者驗證

普通使用者主要透過 TLS 使用者端憑證進行驗證。憑證中的群組資訊可用於後續的授權檢查。其他驗證方法，如靜態檔案驗證，因其安全性較低，不建議在生產環境中使用。

安全防護措施

1. etcd 安全：確保 etcd 叢集不被未經授權的服務存取。使用 PKI（公開金鑰基礎設施）保護 etcd，並監控金鑰使用情況。

2. 網路過濾：佈署網路過濾規則，限制只有控制平面可以存取 etcd。

3. 雲端服務設定：檢查雲端服務提供商的設定，確保 etcd 叢集僅在虛擬私有雲（VPC）內可存取，而非全網際網路可存取。

4. 元資料服務保護：驗證元資料服務可存取的資料型別，並採取額外措施保護身份驗證資訊。

Kubernetes 認證機制的安全分析

Kubernetes 的認證機制是其安全架構中的重要一環，主要用於驗證使用者或服務帳戶的身份。本文將探討 Kubernetes 中的幾種主要認證方式，包括 Service Account Token、Certificate Authentication 和 Request Header Authentication，並分析其安全特性和潛在風險。

Service Account Token 認證

Service Account Token 是 Kubernetes 中用於識別和驗證服務帳戶的 JSON Web Token（JWT）。這些 token 由 kube-controller-manager 生成，並使用私鑰簽名。預設情況下，Kubernetes 會將這些 token 儲存在 etcd 中，並在認證過程中進行查詢驗證。

Token 結構分析

Service Account Token 由三部分組成：Header、Payload 和 Signature。Header 中通常包含演算法資訊，如 RS256。Payload 中包含服務帳戶的詳細資訊，如 namespace、secret.name 和 service-account.name 等。

{
  "alg": "RS256",
  "kid": ""
}

{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "kube-system",
  "kubernetes.io/serviceaccount/secret.name": "weave-net-token-nmb26",
  "kubernetes.io/serviceaccount/service-account.name": "weave-net",
  "kubernetes.io/serviceaccount/service-account.uid": "63b2e612-9ba4-11e9-bb0d-024233df59eb",
  "sub": "system:serviceaccount:kube-system:weave-net"
}

#### 內容解密：

1. Token 結構：Service Account Token 採用 JWT 格式，包含 Header、Payload 和 Signature 三部分。
2. Header 部分：指定簽名演算法（如 RS256）和金鑰 ID（kid）。
3. Payload 部分：包含發行者（iss）、namespace、secret.name、service-account.name 和 UID 等資訊，用於識別服務帳戶。
4. Signature 部分：使用私鑰對 Header 和 Payload 簽名，確保 token 的真實性和完整性。

安全特性與風險

• 私鑰保護：如果攻擊者取得私鑰（sa.key），就可以偽造任意服務帳戶的 token。
• 預設行為：Kubernetes 預設會在 etcd 中查詢 token，因此偽造 token 攻擊較難實作。
• 容器內 token 位置：容器內預設會掛載服務帳戶 token，位於 /run/secrets/kubernetes.io/serviceaccount/token。

防範措施

1. 限制服務帳戶許可權：使用最小許可權原則組態服務帳戶，避免過度授權。
2. 停用自動掛載 token：在 Pod spec 中設定 automountServiceAccountToken: false，避免不必要的 token 暴露。

Certificate Authentication

Kubernetes 支援使用 TLS 證書進行使用者認證。使用者需使用由組態的 Certificate Authority（CA）簽發的證書，才能透過 API Server 的認證。

證書結構分析

使用 openssl 命令可以檢視證書詳細資訊，包括 Subject、Issuer 和 Validity 等。

$ openssl x509 -text -in client.crt

#### 內容解密：

1. 證書內容：使用 openssl 命令解析證書，顯示其版本、序列號、簽名演算法、發行者和主體資訊等。
2. Subject 欄位：包含 CommonName 和 Organization 資訊，用於 Kubernetes 中的授權檢查。
3. Validity 欄位：定義證書的有效期，過期的證書將無法透過認證。

安全特性與風險

• CA 安全：CA 私鑰的安全至關重要，一旦洩露，攻擊者可簽發任意使用者證書。
• 使用者證書管理：需要妥善管理使用者證書，避免無效或過期證書被誤用。

Request Header Authentication

Kubernetes 的聚合層（Aggregation Layer）允許擴充套件 API Server，透過組態特定的命令列引數，可以啟用 Request Header 認證。

組態引數

• proxy-client-cert-file
• proxy-client-key-file
• requestheader-client-ca-file
• requestheader-allowed-names
• requestheader-group-headers
• requestheader-username-headers

安全特性與風險

• 組態複雜度：錯誤的組態可能導致認證機制被繞過或錯誤應用。
• 私鑰洩露風險：若 proxy-client-key-file 私鑰洩露，攻擊者可偽造任意使用者身份。

Kubernetes 安全漏洞：kubelet 驗證與授權機制探討

Kubernetes 的 kubelet 元件預設不要求驗證，允許匿名存取其 API。這使得攻擊者能夠輕易存取底層的 Pod。若 kubelet 的 HTTP 服務可被匿名存取，或攻擊者擁有必要的憑證，便可執行程式碼於節點上的 Pod。

kubelet 設定與安全風險

預設的 kubelet 設定可能如下：

apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: true
authorization:
  mode: AlwaysAllow

此設定允許匿名存取並總是允許授權，可能導致安全風險。

利用 kubelet API 執行程式碼

攻擊者可利用 kubelet 的 /pods 端點列出正在執行的 Pod。接著，使用 /run 或 /exec 端點在指定的 Pod 中執行程式碼。以下是一個利用 /run 端點執行 env 指令的例子：

curl -k https://localhost:10250/run/default/my-nginx-5754944d6c-bngfr/nginx -d "cmd=env"

內容解密：

1. curl -k：使用 curl 指令忽略 SSL 憑證驗證，直接存取 HTTPS 端點。
2. https://localhost:10250/run/default/my-nginx-5754944d6c-bngfr/nginx：存取 kubelet 的 /run 端點，指定 namespace 為 default，Pod 名稱為 my-nginx-5754944d6c-bngfr，容器名為 nginx。
3. -d "cmd=env"：傳遞引數 cmd=env，表示在容器內執行 env 指令。
4. 回應內容包含容器的環境變數，如 PATH、HOSTNAME、KUBERNETES_SERVICE_HOST 等。

Kubernetes 授權機制

Kubernetes 使用多種授權模式來驗證使用者是否能執行特定操作。常見的授權模式包括：

• Node：用於控制 kubelet 對資源的存取。
• Role-based access control (RBAC)：最常使用的授權模式，用於管理使用者和服務帳戶的許可權。

利用 etcd 探索 RBAC 設定

etcd 是 Kubernetes 的資料儲存中心，儲存了所有的叢集資料，包括 RBAC 設定。攻擊者可利用 etcdctl 工具檢視 RBAC 設定。例如，檢視 ClusterRole 和 ClusterRoleBinding：

ETCDCTL_API=3 ./etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/apiserver-etcd-client.crt --key=/etc/kubernetes/pki/apiserver-etcd-client.key --endpoints=https://127.0.0.1:2379 get /registry/clusterroles/weave-net | ./auger decode -o yaml

內容解密：

1. ETCDCTL_API=3：指定使用 etcdctl 的 API 版本 3。
2. ./etcdctl：執行 etcdctl 工具。
3. --cacert、--cert、--key：指定用於驗證的 CA 憑證、客戶端憑證和私鑰。
4. --endpoints=https://127.0.0.1:2379：指定 etcd 的端點。
5. get /registry/clusterroles/weave-net：取得 weave-net ClusterRole 的資料。
6. ./auger decode -o yaml：將取得的資料解碼為 YAML 格式。

風險與對策

• 風險：kubelet 的匿名存取和寬鬆的授權設定可能導致未經授權的存取和程式碼執行。
• 對策：應關閉 kubelet 的匿名存取並使用適當的授權模式（如 RBAC）來限制存取許可權。