Kubernetes 秘密管理與 RBAC 安全控制實踐

– 8 分鐘閱讀

Kubernetes 秘密管理是確保應用程式安全的重要環節。本文從秘密的生命週期出發，探討如何使用 kubectl 工具編輯、更新和刪除秘密，並強調了設定 immutable 屬性以防止意外修改的重要性。同時，文章也介紹瞭如何備份和還原秘密，以應對意外情況。此外，文章還探討了在不同佈署環境（開發、測試、生產）中，如何維護秘密的一致性和安全性，並建議使用外部秘密管理解決方案，例如 HashiCorp Vault、GCP Secret Manager 和 AWS Secrets Manager 等，以提升秘密管理的效率和安全性。最後，文章也強調了 RBAC 的重要性，說明如何利用 RBAC 進行細粒度的許可權控制，確保只有授權的使用者和服務才能存取秘密。

Kubernetes 秘密管理概念深度解析

在 Kubernetes 中管理秘密（Secrets）是一項關鍵任務，特別是涉及到備份、追蹤狀態變更及防止意外編輯等需求。以下將詳細探討如何有效地管理 Kubernetes 秘密，並涵蓋不同佈署場景中的應用。

編輯 Kubernetes 秘密並追蹤狀態

為了備份目的及追蹤之前的狀態，編輯時可以使用 --save-config=true 引數：

$ kubectl edit secret plain-text --save-config=true
$ kubectl get secret plain-text -o yaml

在 kubectl.kubernetes.io/last-applied-configuration 欄位中，我們會備份之前的組態。這樣我們可以追蹤哪些命令導致了秘密的變更，同時也保留了最後應用的組態。

此圖示

  graph TD;
    A[編輯秘密] --> B[使用 --save-config=true 引數];
    B --> C[取得秘密 YAML 組態];
    C --> D[儲存最後應用的組態];

此圖示展示了編輯 Kubernetes 秘密並儲存組態的過程。首先，我們編輯秘密並使用 --save-config=true 引數，然後取得秘密的 YAML 組態，最後儲存最後應用的組態。

不可變更的 Kubernetes 秘密

在某些情況下，我們可能希望秘密保持不變，例如防止意外編輯。以下是如何實作這一點：

apiVersion: v1
kind: Secret
metadata:
  name: immutable-secret
type: Opaque
stringData:
  value: non-base64
immutable: true

如果嘗試編輯這個秘密，當我們嘗試儲存時會遇到以下錯誤訊息：

data: Forbidden: field is immutable when `immutable` is set

一旦將現有的秘密設為不可變更，就無法再編輯它；該秘密將永久成為不可變更。要修改不可變更的秘密，唯一的方法是刪除並重新應用它。

內容解密：

  • immutable: true：這個欄位表示該秘密是不可變更的。一旦設定為不可變更，就無法再進行任何修改。
  • stringData：這裡使用 stringData 欄位來定義明文值，而不需要進行 base64 編碼。
  • 錯誤訊息：當嘗試編輯不可變更的秘密時，Kubernetes 會傳回一個錯誤訊息，指出該欄位是不可變更的。

停止使用並刪除 Kubernetes 秘密

刪除 Kubernetes 物件的命令也適用於秘密。以下範例將刪除一個名為 immutable-secret 的 Kubernetes 秘密：

kubectl delete secret immutable-secret

刪除後，該秘密將永久從系統中移除。唯一能夠還原它的方法是透過還原 etcd 備份（假裝置份中包含該秘密）或應用手動備份：

kubectl get secret immutable-secret -o yaml

在不同佈署場景中的 Kubernetes 秘密組態

在軟體開發生命週期（SDLC）中，開發團隊可能會使用不同的環境來測試增量版本，然後再釋放到生產環境。與生產佈署類別似，其他環境也會有某些組態需求，包括秘密。

秘密在不同環境中的使用

確保秘密的永續性和完整性無論在哪個環境中都至關重要。不同環境中對秘密的處理方式可能會導致長期問題，團隊無法完全驗證秘密處理方式對安全性的影響。

例如，開發環境和生產環境之間可能會因為成本文約需求而存在差異，但秘密仍然需要安全儲存。還有一些情況下，秘密可能需要在多個環境之間分享。例如外部 SaaS 服務的專有鑰匙需要在多個環境之間分享。

從開發到佈署

要佈署秘密，敏感資訊需要儲存在某個地方。這些資訊最終會由個人插入到系統中並應用到 Kubernetes 中。現在公司通常將敏感資訊儲存在專門設計來儲存此類別資訊的各種系統中。

生命週期管理與安全儲存

佈署如此敏感的 Kubernetes 秘密從檢索憑證開始，然後建立所需的 YAML 檔案並應用到 Kubernetes 中。在 CI/CD 工作流程中，大多數 CI/CD 提供者都提供了使用秘密值來完成工作流程的選項。這有助於我們向 CI/CD 工作流程提供憑據以與秘密儲存進行互動。

GitOps 是另一種正規化。Argo CD 是一個非常受歡迎的工具，可以自定義秘密佈署以便在解密後應用秘密。

在不同環境中處理秘密

無論是在哪個環境中處理秘密都應該遵循相同的方式。這有助於自動化和一致性。

需要管理秘密：安全儲存與存取控制

Kubernetes 叢集有責任安全地包含秘密並防止未經授權存取。每個託管在 Kubernetes 上的秘密都曾經由個人或自動化流程儲存過。

安全儲存

有各種工具專門用於安全儲存。例如 HashiCorp Vault、Google Cloud Platform (GCP) Secret Manager 和 Amazon Web Services (AWS) Secrets Manager 等外部秘密管理解決方案。這些解決方案可以作為獨立的秘密管理系統使用，也可以直接從 Kubernetes 中使用。

它們共同具有跨切面關注點如管理、版本控制、加密和存取控制能力。

授權控制

存取控制對於確保秘書儲存安全至關重要。永續性、靜態加密和傳輸中的加積合則使得與安全儲存系統互動更加安全；但這還不夠。我們需要對存取秘書具有細粒度控制。

不同環境中的 Secret 管理技巧

Kubernetes Secrets 在不同環境中的管理是確保系統安全性和穩定性的一部分。無論是在開發、測試還是生產環境中，Secret 的管理策略應該一致且嚴謹。

首先，保持 Secret 的不可變性（Immutability） 是非常重要的一步。這樣可以防止意外修改或漏洞攻擊者篡改 Secret 的內容：

apiVersion: v1
kind: Secret
metadata:
  name: immutable-secret
type: Opaque
stringData:
  value: non-base64
immutable: true

Secret 的永久刪除

當我們不再需要某個 Secret 的時候，永久刪除 是最簡單也是最直接的方法：

kubectl delete secret immutable-secret

備份與還原

雖然刪除後 Secret 無法直接還原，備份 是必要步驟：

kubectl get secret immutable-secret -o yaml > immutable-secret-backup.yaml

分析與改進

  • 版本控制：利用 CI/CD 工具自動化 Secret 的版本控制和佈署。
  • 稽核日誌：記錄每次 Secret 操作以便事後稽核。
  • 角色許可權：嚴格控制誰能夠讀取或修改 Secret。

零知識診斷：遇到問題如何排查？

當遇到問題時，首先檢查日誌。Kubernetes 提供豐富的日誌資訊來幫助排查問題：

kubectl logs <pod-name>

此外，檢查事件也是排查問題的一種手段：

kubectl describe pod <pod-name>
小段落標題：Secret 的日常維護建議
  • 定期檢查：定期檢查所有 Secret 是否符合最新的安全標準。
  • 更新策略：隨著時間推移更新 Secret 的策略以適應新的威脅。
  • 監控工具：使用監控工具來實時監控 Secret 的使用情況和異常行為。

透過以上方法，玄貓相信能夠更好地管理和保護 Kubernetes 中的 Secret，確保系統的安全性和穩定性。

Kubernetes 憑證管理與 RBAC 安全控制

在現代雲端運算環境中，Kubernetes 作為一個強大的容器協調平台，其安全管理是至關重要的。本文將探討 Kubernetes 憑證管理的概念及如何透過根據角色的存取控制（RBAC）來確保憑證的安全性。

Kubernetes 憑證管理概述

Kubernetes 中的憑證（Secrets）用於儲存敏感資訊，例如密碼、金鑰及其他機密資料。確保這些憑證的安全性是保護整個系統的一個重要環節。以下是幾個關鍵點：

  • 使用者角色區分：需要區分不同使用者在組織中的角色，並根據角色分配不同的許可權。
  • 環境差異：不同環境下的許可權可能不同，因此需根據環境進行許可權管理。
  • 稽核與追蹤：需要能夠追蹤和稽核憑證的存取記錄，以防止未授權存取。

憑證儲存方式

除了使用安全的儲存系統外，還有一種常見的方法是將憑證以加密形式儲存在 Git 倉函式庫中。這樣可以利用 Git 的版本控制、存取控制及儲存保障等功能。以下是一些加密方式：

  • PGP 加密：使用 Pretty Good Privacy (PGP) 金鑰進行加密。
  • 硬體安全模組：使用硬體安全模組進行加密。
  • 雲端金鑰管理服務：使用現代雲端金鑰管理服務（KMS）進行加密。

實作案例：Mozilla SOPS

Mozilla Secrets OPerationS (SOPS) 是一個非常流行的工具，它利用雲端提供者的 KMS 以及 PGP 來進行憑證管理。SOPS 能夠將憑證以加密形式儲存在 Git 倉函式庫中，並且能夠透過 Git 的功能來管理版本、存取控制及儲存保障。

確保憑證存取安全

無論憑證如何儲存，確保其存取安全都是至關重要的。這意味著需要限制對憑證的存取，並且只有授權人員才能進行操作。RBAC 是 Kubernetes 提供的一種安全機制，用於控制對資源的存取。

RBAC 介紹

RBAC（根據角色的存取控制）是 Kubernetes 提供的一種安全機制，用於控制對資源的存取。RBAC 包括以下幾個核心元素：

  • Roles：定義在特定名稱空間內的許可權集合。
  • RoleBindings：將角色繫結到特定使用者或服務帳戶。
  • ClusterRoles：定義在整個叢集範圍內的許可權集合。
  • ClusterRoleBindings：將叢集角色繫結到特定使用者或服務帳戶。

Roles 與 RoleBindings

以下是一個 Role 的範例，該 Role 允許在 default 名稱空間內檢視 Secret：

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

RoleBindings 則將該 Role 與特定服務帳戶繫結：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: secret-viewer-binding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: secret-viewer
subjects:
- kind: ServiceAccount
  name: secret-viewer
  namespace: default

ClusterRoles 與 ClusterRoleBindings

以下是一個 ClusterRole 的範例，該 ClusterRole 允許在整個叢集範圍內管理 Secret：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-admin-cluster
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["*"]

ClusterRoleBindings 則將該 ClusterRole 與特定服務帳戶繫結：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: secret-admin-cluster-binding
subjects:
- kind: ServiceAccount
  name: secret-admin
  namespace: default
roleRef:
  kind: ClusterRole
  name: secret-admin-cluster
  apiGroup: rbac.authorization.k8s.io

RBAC 與 Secrets 的實作案例

我們可以透過以下步驟來建立並測試 RBAC 組態：

  1. 建立服務帳戶：
kubectl create sa secret-admin
  1. 應用 ClusterRole 組態：
kubectl apply -f ./secret-admin-cluster.yaml
  1. 建立 Pod，並附加 ClusterRole 物件：
apiVersion: v1
kind: Pod
metadata:
  name: kubectl-create-secret
spec:
  containers:
    - name: kubectl
      image: bitnami/kubectl:latest
      args:
        - create
        - secret
        - generic
        - test
        - --from-literal=literal1=text-for-literal-1
      serviceAccountName: secret-admin
  1. 檢查日誌以確認 Secret 已經成功建立：
secret/test created

雙向結合技術趨勢與實際應用

玄貓認為未來 RBAC 在 Kubernetes 中會越來越受到重視，特別是在多團隊協作及混合雲環境下。透過 RBAC 的精細化管理，可以有效地降低未授權存取的風險，並且提高系統的安全性和可維護性。

此外，結合雲端 KMS 技術進行憑證加密管理，能夠進一步提升資料的安全性和可靠性。隨著雲端技術的不斷發展，這些技術趨勢將會在實際應用中發揮越來越重要的作用。

玄貓

玄貓

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