Kubernetes 密碼管理與原生加密技術應用

Kubernetes 提供 Secret 物件來管理敏感資訊，但僅使用 base64 編碼，安全性不足。透過 RBAC，可以精細控制不同服務帳戶對 Secret 的存取許可權，例如建立僅具備讀取許可權的角色並繫結至特定服務帳戶。此外，Kubernetes 稽核功能可記錄 Secret 操作，方便追蹤和稽核。然而，要真正保護 Secret 資料，需要使用原生加密技術。Kubernetes KMS 框架允許整合外部金鑰管理系統，實作更安全的加密儲存。透過組態 EncryptionConfiguration 檔案，可以指定加密提供者和加密目標資源，例如 Secret 和 ConfigMap。kube-apiserver 啟動引數中的 --encryption-provider-config 和 --encryption-provider-config-automatic-reload 則用於指定組態檔案路徑和啟用自動重新載入。選擇合適的加密提供者，例如 aes 或 KMS 外掛，對提升安全性至關重要。aes 提供者使用對稱加密，而 KMS 外掛則允許整合外部金鑰管理服務，提供更靈活的金鑰管理策略。設定加密提供者時，需要注意優先順序，kube-apiserver 會依序嘗試使用組態的提供者進行加密。使用 Kind 等工具可以方便地建立本地測試環境，驗證加密組態的正確性。在實際佈署中，需要確保每個控制平面節點都佈署了相同的加密組態。

Kubernetes 密碼管理及監控

在 Kubernetes 中，密碼（Secrets）是管理敏感資訊的重要工具。然而，僅僅依賴密碼並不足夠，我們還需要確保這些密碼的使用情況能夠被稽核和監控。本文將探討如何在 Kubernetes 中進行密碼管理及監控，並提供具體的實作案例與技術深度分析。

密碼管理概述

Kubernetes 提供了多種密碼型別，每種都有其特定的使用場景。以下是一些常見的密碼型別及其用途：

Opaque：通用型密碼，用於儲存任意資料。
kubernetes.io/service-account-token：用於服務帳戶的認證。
kubernetes.io/dockercfg：用於 Docker 登入的憑證。
kubernetes.io/basic-auth：用於基本認證的憑證。

在進行密碼管理時，我們需要考慮如何限制對密碼的存取許可權。這裡介紹如何使用角色根據存取控制（RBAC）來實作這一目標。

使用 RBAC 控制密碼存取

首先，我們建立一個服務帳戶並繫結到一個具有檢視許可權的角色：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: secret-viewer
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: secret-viewer-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: secret-viewer-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: secret-viewer
  namespace: default
roleRef:
  kind: Role
  name: secret-viewer-role
  apiGroup: rbac.authorization.k8s.io

接下來，我們建立一個 Pod 來測試這個角色的許可權：

apiVersion: v1
kind: Pod
metadata:
  name: kubectl-get-secrets
spec:
  containers:
  - name: kubectl
    image: bitnami/kubectl:latest
    args:
    - get
    - secret
    - secret-toview
    serviceAccountName: secret-viewer

內容解密：

上述程式碼展示瞭如何使用 RBAC 檢視特定名稱空間中的密碼。以下是每個部分的詳細說明：

ServiceAccount：定義了一個名為 secret-viewer 的服務帳戶。
Role：定義了一個角色 secret-viewer-role，該角色具有檢視 secrets 資源的許可權。
RoleBinding：將 secret-viewer 帳戶繫結到 secret-viewer-role。
Pod 組態：建立了一個 Pod，該 Pod 使用 secret-viewer 帳戶並執行 kubectl get secret secret-toview 命令。

這樣可以確保只有具備適當角色的人才能存取特定的密碼。

資料監控與稽核

除了控制存取許可權，我們還需要監控和稽核密碼的使用情況。Kubernetes 提供了稽核功能，可以記錄和監控叢集中的活動。

支援資料監控與稽核

要啟用對密碼的稽核，我們需要組態稽核策略。以下是一個簡單的稽核策略範例：

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
- "RequestReceived"
rules:
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets"]

在 Kubernetes 安裝中啟用稽核

在 Kubernetes 安裝中，我們可以透過 --audit-policy-file 標誌來啟用稽核：

kube-apiserver --audit-policy-file=/path/to/audit-policy.yaml --audit-log-path=-

對於 Minikube，我們可以在啟動時傳遞稽核組態：

minikube start \
--extra-config=apiserver.audit-policy-file=/etc/ssl/certs/audit-policy.yaml \
--extra-config=apiserver.audit-log-path=-

啟用稽核後，我們可以透過檢視日誌來監控密碼操作：

kubectl logs -f kube-apiserver-minikube -n kube-system | grep audit.

觸發與解讀稽核事件

我們可以透過執行密碼操作來觸發稽核事件：

kubectl get secret

然後在日誌中查詢相關事件：

{"kind":"Event",...,"verb":"list","user":{"username":"minikube-user","groups":["system:masters","system.authenticated"]},"sourceIPs":["192.168.49.1"],"responseStatus":{"metadata":{},"code":200},...}

這樣我們就可以追蹤和監控對密碼的操作。

Kubernetes 原生加密技術應用

在 Kubernetes 環境中，管理機密（Secrets）是確保應用程式安全運作的關鍵。然而，Kubernetes 的內建 etcd 資料函式庫僅對資料進行 base64 編碼，這與明文幾乎無異。為了提升資料安全性，我們需要採用原生的加密技術來保護資料。本文將探討如何在 Kubernetes 中實作原生的資料加密。

技術需求

在本文中，我們將使用一系列常見工具和平台來操作容器、Kubernetes 以及 Secrets 管理。以下是本章所需的工具：

Docker：Docker 和 Podman 皆可作為容器引擎使用。Podman 提供瞭如無守護程式的安裝、無根許可權以提高安全性等優點。
Podman Desktop：這是一個開源軟體，提供圖形化介面來構建、啟動和除錯容器，並且能夠執行本地 Kubernetes 例項。
Golang：Kubernetes 和大多數第三方元件都是用 Go 語言編寫的。
Git：我們將使用 Git 作為版本控制系統來還原書籍範例並探索 Secrets 管理解決方案。

此外，我們還會使用以下工具：

HashiCorp Vault：一個用於安全儲存憑證和令牌的社群版本工具。
Trousseau：一個 KMS 提供者外掛，用於連線外部 KMS 如 HashiCorp Vault、Azure Key Vault 或 AWS 對應服務。

讀者可以透過以下連結取得與本文相關的數位材料：

GitHub 儲存函式庫：https://github.com/PacktPublishing/Kubernetes-Secrets-Handbook

Kubernetes 原生加密

在 Kubernetes 中，etcd 是其核心資料函式庫，但它並不提供資料加密功能，僅對資料進行 base64 編碼，這幾乎等同於明文。為了提升資料安全性，Kubernetes 提供了一個 KMS 框架來處理加密問題。

加密提供者

Kubernetes 的 KMS 框架支援以下幾種加密提供者：

身份提供者（Identity Provider）：這是預設組態，表示不對資料進行任何加密。
aes 提供者：使用 AES 加密演算法（aesgcm 或 aescbc），並由使用者生成隨機加金鑰匙。
KMS 提供者外掛：連線 kube-apiserver 與外部 KMS，利用包裝加密原則。

組態 KMS 框架

要啟用 KMS 框架，需要在 kube-apiserver Pod 的啟動或重啟時進行組態。以下是啟用 kube-apiserver 加密功能的步驟：

參考 kube-apiserver：使用兩個組態旗標來啟用能力並參考組態檔案，以及在組態檔案變更時自動重新載入。
組態檔案：在每個控制平面節點上佈署組態檔案，路徑和名稱在組態旗標中定義。

組態檔案範例

以下是根據 YAML 的 EncryptionConfiguration API 物件的組態檔案範例：

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - Secrets
      - ConfigMap
providers:
  - identity: {}

這個 YAML 檔案定義了要加密的 Kubernetes API 物件（如 Secrets 和 ConfigMap），以及加密機制（如 identity）。

命令旗標

要啟用 kube-apiserver 的加密功能，需要使用以下命令旗標：

--encryption-provider-config=/etc/kubernetes/encryption/configuration.yaml
--encryption-provider-config-automatic-reload=true

以下是 Pod 定義片段，展示瞭如何放置這些旗標：

apiVersion: v1
kind: Pod
spec:
  containers:
    - command:
        - kube-apiserver
        - --advertise-address=10.89.0.2
        - --allow-privileged=true
        ...

#### 內容解密：

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - Secrets
      - ConfigMap
providers:
  - identity: {}

此段落定義了一個 EncryptionConfiguration API 物件。其 apiVersion 指定了該物件所屬的 API 版本為 apiserver.config.k8s.io/v1；kind 屬性則表明該物件為 EncryptionConfiguration。在 resources 下列出了需要加密的 API 資源型別，包括 Secrets 和 ConfigMap。最後在 providers 下指定了使用預設的身份提供者（identity）來處理資料加密。

--encryption-provider-config=/etc/kubernetes/encryption/configuration.yaml --encryption-provider-config-automatic-reload=true

這些命令旗標分別用來指定加密提供者的組態檔案路徑以及啟用自動重新載入功能。透過這些旗標可以確保在更新組態檔案後不需要重啟 kube-apiserver 即可自動應用新設定。

apiVersion: v1
kind: Pod
spec:
  containers:
    - command:
        - kube-apiserver
        - --advertise-address=10.89.0.2
        - --allow-privileged=true

以上內容展示瞭如何將命令旗標新增到 Pod 的 command 屬性中。這樣可以確保 kube-apiserver 在啟動時會載入所指定的加密組態檔案並啟用自動重新載入功能。

加密提供者順序

Kubernetes 的加密提供者列表具有優先順序結構。這意味著 kube-apiserver 會依序解析列表中的提供者，這可能會影響您的操作。

#### 內容解密：

「Providers」屬性下所列出的各項「EncryptionProvider」會以優先順序被依序檢查與執行。例如：若先列出了「aesgcm」和「aescbc」，則「aesgcm」會優先於「aescbc」執行；若伺服器無法正確執行前項「aesgcm」，則會切換至後項「aescbc」。這種方式可提升多樣化選項下之資料安全性及可靠性。

模擬測試環境

最簡單的方式是使用預設設定義來設定第一個 EncryptionConfiguration 檔案並確保其正確佈署到每個控制平面節點上。

模擬測試環境建立

當使用 Kind（Kubernetes in Docker）時，可以透過額外的卷定義來簡單參照該檔案。具體步驟如下：

建立名為 configuration.yaml 的檔案並在 /etc/kubernetes/encryption 資料夾中佈署。
在 Kind 組態中新增捲掛載以將該檔案掛載到正確位置。

#### 內容解秘：

利用 Kind 建立模擬測試環境時，我們需建立一個新的 Kind 叢集並將其佈署到本機電腦上。從而以 Docker 作為執行容器引擎支援多樣化操作需求及模擬真實環境以進行測試與研究。

分散式系統安全性

分散式系統中的安全性是複雜且多層次的問題。透過 Kubernetes 原生加密技術及適當組態資源與設計防護機制可以有效減少攻擊面、提高整體系統安全性與資料完整性保障。

#### 內容解秘：

分散式系統透過分散化結構可減少單點故障發生機率；透過 Kubernetes 原生安全技術設計及適當防護措施可有效保護系統及其內部流通之重要資料訊息。

未來趨勢預測

未來，隨著雲端運算和容器化技術的普及，Kubernetes 原生加密技術將變得更加重要。預計將有更多企業採用這些技術來保護其敏感資料和應用程式。

#### 內容解秘：

隨著數位轉型與雲端運算普及化趨勢增溫下；企業未來必將採取更多、更強大之自動化技術以提升系統及其資料之安全防護能力；而 Kubernetes 原生化、自動化之資訊安全防護措施將成為首要選項之一。

透過以上步驟和方法，玄貓希望能夠幫助讀者更好地理解和實作 Kubernetes 中的原生加密技術。

玄貓

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