Kubernetes 密碼安全管理與風險緩解最佳實務

Kubernetes 的密碼管理需要謹慎處理許可權設定，避免使用星號（*）代表所有資源的過度授權，尤其在涉及 Secrets 時，更應透過 RBAC 建立自訂角色，精細地控制 Secrets 的檢視、建立、編輯和刪除許可權。此外，Kubernetes 的原生機制缺乏針對密碼的稽核和變更管理功能，一旦密碼以明文形式被記錄或傳輸，就可能產生安全漏洞。更重要的是，Kubernetes 缺乏零信任機制，即使授權人員也可能以未加密的形式存取密碼，這凸顯了更嚴格存取模型的重要性，確保每個環節都經過驗證。為提升安全性，建議採用中央密碼儲存系統，例如 HashiCorp Vault、CyberArk、AWS Secrets Manager 和 Azure Key Vault 等，並搭配 Kubernetes 特定的組態，例如禁止 Pod 的根使用者、加密靜態和傳輸中的密碼，以及透過 RBAC 實施嚴格的存取控制。同時，名稱空間隔離和網路策略也有助於降低密碼暴露的風險。最後，完善的監控和稽核機制，搭配詳細的日誌記錄，能有效追蹤密碼存取行為，並在事件發生時提供重要的調查依據。

Kubernetes 中的密碼管理挑戰與風險

在 Kubernetes 中，雖然預設的密碼（Secrets）管理系統允許使用 RBAC 來建立自訂角色及繫結，但必須謹慎避免授予過於廣泛的許可權，例如將所有資源（包括 Secrets）授予「*」許可權。自訂角色應特別針對控制對 Secrets 的存取許可權進行設計，明確定義誰有權檢視、建立、編輯或刪除這些密碼。

記錄和稽核問題也帶來額外的挑戰。一旦密碼被存取，它可能會以明文形式被記錄下來或傳輸給不可信任的第三方，從而變得易受攻擊。此外，Kubernetes 並不提供直觀的稽核或變更管理功能來處理密碼。

最後，Kubernetes 中缺乏零信任機制來管理密碼存取，這意味著授權人員通常可以以未加密的形式存取這些密碼。這種情況表明有必要採用更嚴格的存取模型。在這樣的模型中，即使是授權人員也應該以確保安全的方式處理這些明文密碼，符合零信任原則，即每個階段都需要驗證。

緩解策略

在 Kubernetes 環境中確保密碼的安全管理時，應考慮多種策略。

首先，建議使用具備先進安全功能的中央密碼儲存系統來管理 Kubernetes 的密碼。這種方法不僅減少了未經授權存取的風險，還簡化了管理流程並提供了全面的安全觀點。常用於此目地的工具包括 HashiCorp Vault、CyberArk、AWS Secrets Manager 和 Azure Key Vault。

此外，應使用 Kubernetes 平台特定的組態來限制潛在風險因素：

禁止 Pod 的根使用者

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-sample
  labels:
    app: nginx
    environment: production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            runAsNonRoot: true
      restartPolicy: Always

加密密碼

加密在傳輸過程中的密碼和靜止狀態下的密碼是至關重要的。Kubernetes 原生秘密加密或第三方工具都可以完成這項工作。加密確保即使未經授權的人取得了存取許可權，這些秘密資料仍然無法解讀，除非擁有適當的解金鑰匙。

以下是啟用 EncryptionConfiguration 的範例：

在主節點上放置 EncryptionConfiguration YAML 檔案（Kubernetes API 伺服器執行所在）。
修改 API 伺服器啟動引數以包含 --encryption-provider-config ，指向 EncryptionConfiguration YAML 檔案的路徑。
執行以下命令以啟用加密組態：

kube-apiserver --encryption-provider-config=/etc/kubernetes/encryption-config.yaml

啟用 API 伺服器上的加密組態後，現在可以組態使用加密資源（如 Secrets）在 Kubernetes 叢集中：

# 注意：這是範例組態。
# 不要將此用於自己的叢集！
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - providers:
      - aesgcm:
          keys:
            - name: key1
              secret: c2VjcmV0IGlzIHNlY3VyZQ==
            - name: key2
              secret: dGhpcyBpcyBwYXNzd29yZA==
resources:
  - secrets

嚴格存取控制

透過機制如 RBAC（根據角色的存取控制）來限制對 Secrets 的存取是必不可少的。應定義細緻的許可權，明確指示誰可以存取、建立或修改 Secrets。

在 Kubernetes 中，專門針對秘密存取進行稽核涉及詳細記錄每次與秘密資源互動的行為。稽核捕捉關鍵資訊，例如誰存取了秘密、何時進行了存取以及存取行為本身。稽核有助於管理員確定每個操作的詳細情況，如發生了什麼以及何時發生、誰發起了操作以及其來源和目的地。

監控和稽核對於監督秘密的存取時間和用途至關重要，有助於快速調查可疑活動以保護 Secrets。

標準稽核記錄應顯示誰何時存取了什麼內容。在 Kubernetes 中，所有對 Secret 的存取都應被記錄下來，並且這些日誌可以用於潛在洩露事件時進行事故緩解。以下是一個秘密存取記錄日誌條目的範例：

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "metadata": {
    "creationTimestamp": "2023-12-01T12:34:56Z"
  },
  "level": "Metadata",
  "timestamp": "2023-12-01T12:34:56Z",
  "auditID": "abcd1234",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/default/secrets/mysecret",
  "verb": "get",
  "user": {
    "username": "admin",
    "groups": ["system:masters", "system:authenticated"]
  },
  "sourceIPs": ["192.0.2.0"],
  "objectRef": {
    "resource": "secrets",
    "namespace": "default",
    "name": "mysecret",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "status": "Success",
    "reason": ""
  }
}

要啟用稽核功能，請將 --audit-policy-file 標誌新增到 API Server 的啟動引數中，指定您要使用之稽核政策檔案路徑：

kube-apiserver --audit-policy-file=/etc/kubernetes/policy.yaml

啟用 API Server 的稽核政策後，使用者即可組態及指定特定資源存取之輸出日誌。以下是一個快速範例：考慮 Secret 的存取：

# 在請求和回應中記錄 Secret 的存取。
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
resources:
- resources:
- secrets

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
resources:
- group: ""
resources:
- secrets

名稱空間隔離與網路策略

名稱空間隔離可用於分隔敏感工作負載。此外可以利用網路策略來限制這些隔離名稱空間之間的通訊,從而降低 Secret 暴露在外界環境中的風險：

apiVersion: v1
kind: Secret
metadata:
name: test
namespace: test
type: Opaque
data:
password: dGVzdA==
username: dGVzdA==

秘密管理的挑戰與風險

在現代資訊科技環境中，秘密管理是確保系統安全的關鍵環節。秘密（Secrets）包括各種敏感資訊，如密碼、API 金鑰和加密金鑰等。這些資訊若未妥善管理，將面臨重大安全風險。本文將探討秘密管理的挑戰與風險，並提出有效的策略來加強其安全性。

避免在組態檔案中儲存秘密

首先，應避免在 JSON 或 YAML 等組態檔案中儲存秘密，因為這些檔案可能會被提交到版本控制系統或分享。相反，應使用環境變數或專門的秘密管理工具來儲存這些敏感資訊。

零信任系統

採用零信任系統概念也是至關重要的。零信任系統強調「不信任、永遠驗證」的原則，這意味著即使在內部網路中也應該對所有請求進行驗證。在實踐中，這可以透過解決方案來實作，這些方案僅在必要時解密秘密，並防止任何人直接解密秘密。

秘密存取後的防護措施

一旦秘密被存取，必須採取預防措施來確保其資料不會以明文形式記錄或傳輸給不受信任的方。這可以透過加密日誌記錄和使用安全傳輸協定來實作。

定期旋轉秘密

定期旋轉鑰匙和秘密是維持安全的重要措施。許多組織會按照稽核和合規政策在固定間隔（如30、60或90天）進行旋轉。美國國家標準與技術研究院（NIST）提供了詳細的鑰匙管理，包括最佳實踐和管理策略，如特別公告800-57 第1部分修訂版5和第2部分修訂版1中所述。這些有助於確保即使鑰匙被篡改，其風險敞口也會被最小化。

透過採用這些策略，組織可以在 Kubernetes 環境中建立一個強健且安全的秘密管理系統。

Kubernetes 環境中的秘密管理

Kubernetes 作為容器協調平台，廣泛應用於現代雲端運算環境中。在 Kubernetes 中，秘密管理涉及多個方面，包括建立、管理和分享應用程式和服務之間的敏感資訊。

Kubernetes Secret 的安全風險

Kubernetes Secret 本身也存在一些安全風險：

API 伺服器或節點暴露：如果未正確組態，Secret 可能會暴露在叢集的 API 伺服器或節點上。
根級別攻擊：若攻擊者取得了 root 許可權，可能會直接存取 Secret。
傳輸過程中的加密：未加密的 Secret 在傳輸過程中可能會被攔截。
不足的存取控制：未正確組態的存取控制可能會導致未經授權的人員存取 Secret。

應對策略

為了緩解這些風險，可以採取以下策略：

使用秘密管理工具：利用專門設計的工具來管理 Secret，例如 HashiCorp Vault 或 AWS Secrets Manager。
加密 Secret：確保 Secret 在儲存和傳輸過程中的加密。
實施存取控制：嚴格控制誰可以存取哪些 Secret。
監控和稽核：定期監控和稽核 Secret 的存取情況。

外部秘密儲存與 Kubernetes 整合

外部秘密儲存提供了一種更靈活且安全的方式來管理 Kubernetes 中的 Secret。以下是一些常見的外部秘密儲存選項及其優勢：

AWS Secrets Manager：提供強大的加密功能和版本控制。
Azure Key Vault：支援多種型別的敏感資訊並提供嚴格的存取控制。
Google Cloud Secret Manager：與 Google Cloud 平台無縫整合，提供高用性和可擴充套件性。

組態外部秘密儲存

要將外部秘密儲存與 Kubernetes 整合，需要以下步驟：

安裝 CSI 驅動程式：CSI（Container Storage Interface）驅動程式允許 Kubernetes 與外部秘密儲存進行互動。
組態工作負載身份驗證：確保 Kubernetes Pod 能夠安全地與外部秘密儲存進行身份驗證。
建立 Secret 資源：使用外部秘密儲存中的資料建立 Kubernetes Secret 資源。

玄貓

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