2025年12月18日玄貓（BlackCat）

GCP 與 Azure 雲端秘密儲存 Kubernetes 整合應用

本文探討 GCP Secret Manager 和 Azure Key Vault 在 Kubernetes 中的應用，涵蓋基本架構、實際案例、稽核日誌分析、加解密操作、IAM 許可權管理、高用性和災難還原等方面，並提供詳細的設定步驟和程式碼範例，最後比較兩者差異，幫助讀者理解如何在 Kubernetes

雲端技術容器技術

Kubernetes GCP Azure Secret Manager Key Vault 雲端安全

在現代雲端原生應用程式中，保護敏感資料至關重要。GCP Secret Manager 和 Azure Key Vault 提供了安全儲存和管理機密資訊的解決方案。本文將探討如何在 Kubernetes 環境中整合和使用這兩種服務，包含設定流程、存取控制、日誌記錄和監控等實務層面。GCP Secret Manager 提供了細粒度的 IAM 許可權控制、高用性和災難還原能力，以及完整的日誌記錄和監控功能。透過工作負載身份，Kubernetes Pod 可以直接使用 Google Cloud 身份驗證存取 Secret Manager，簡化了設定並提升了安全性。Azure Key Vault 則提供了類別似功能，允許透過 Service Principal 或 Managed Identity 進行身份驗證，並支援使用 KMS 進行秘密加密。兩種服務都提供了稽核日誌，方便追蹤和監控對機密資料的存取。選擇哪種服務取決於具體需求和雲端平台的選擇。

心得結語

本文探討瞭如何在 Azure 中設定和使用雲端秘密儲存，特別是與 AKS 叢集的整合。透過組態 Key Vault、OIDC 憑證和 CSI 外掛，我們能夠安全地在 Kubernetes 工作負載中存取秘密。此外，我們還設定了診斷設定來進行稽核和日誌記錄，確保安全性和合規性。

希望這篇文章能夠幫助你更好地理解和應用 Azure 的雲端秘密管理技術。如果你有任何問題或建議，歡迎留言討論！

Azure 中的雲端機密儲存探索

在 Azure 中管理機密資料是現代雲端應用程式的重要挑戰之一。Azure Key Vault 提供了一個安全且可靠的解決方案來儲存和管理敏感資訊。本文將探討如何使用 Azure Key Vault 來加密 Kubernetes 中的機密資料，並透過實際案例和技術分析來展示其應用。

Azure Key Vault 的基本架構

Azure Key Vault 是一個雲端服務，用於安全地儲存和管理機密資料，包括金鑰、密碼和憑證。Key Vault 提供了多層次的安全保護，確保只有授權的應用程式和服務能夠存取這些敏感資訊。

實際案例：機密資料的儲存和檢索

假設我們有一個 Kubernetes 叢集，並且我們希望將敏感資訊（如資料函式庫連線字串）儲存在 Azure Key Vault 中。以下是如何設定和使用 Azure Key Vault 的基本步驟：

建立 Azure Key Vault：首先，我們需要建立一個 Azure Key Vault 例項。這可以透過 Azure 門戶或使用 Terraform 等工具來完成。

resource "azurerm_key_vault" "ksm_key_vault" {
  name                = "ksm-key-vault"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  tenant_id           = data.azurerm_client_config.current.tenant_id
  sku_name            = "Standard"
}

儲存機密資料：接著，我們可以將機密資料儲存到這個 Key Vault 中。

resource "azurerm_key_vault_secret" "db_password" {
  name         = "db-password"
  value        = "supersecretpassword"
  key_vault_id = azurerm_key_vault.ksm_key_vault.id
}

檢索機密資料：在 Kubernetes 叢集中，我們可以使用 Service Principal 或 Managed Identity 來存取 Azure Key Vault 中的機密資料。以下是如何設定 Managed Identity 的範例：

resource "azurerm_user_assigned_identity" "keyvault_reader" {
  name                = "keyvault-reader"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
}

resource "azurerm_role_assignment" "keyvault_reader_role" {
  principal_id                     = azurerm_user_assigned_identity.keyvault_reader.principal_id
  role_definition_name             = "Key Vault Secrets User"
  scope                                = azurerm_key_vault.ksm_key_vault.id
}

稽核日誌分析

Azure 提供了詳細的稽核日誌，幫助我們監控和追蹤對 Key Vault 的存取和操作。以下是一個稽核日誌範例：

{
  "time": "2023-09-03T11:46:27.5820050Z",
  "category": "AuditEvent",
  "operationName": "KeyDecrypt",
  "resultType": "Success",
  "identity": {
    "claim": {
      "xms_az_rid": "/subscriptions/.../managedClusters/ksm-aks",
      "xms_az_nwperimid": []
    }
  },
  "properties": {
    "id": "https://ksm-key-vault.vault.azure.net/keys/ksm-encryption-key/0c24b95c67534a3eb85c71854dc8a7bd",
    "algorithm": "RSA-OAEP-256",
    ...
    "tlsVersion": "TLS1_2"
  }
}

透過這些日誌，我們可以識別哪些操作已經執行，誰執行了這些操作，以及這些操作針對哪些資源。

Azure Key Vault 用於秘密加密

除了儲存敏感機密資料外，Azure Key Vault 還可以用作金鑰管理服務（KMS），用於加密 etcd 中的秘密。以下是如何設定和使用 Azure Key Vault 作為 KMS 的步驟：

建立加密金鑰：首先，我們需要在 Key Vault 中建立一個金鑰，用於加密目的。

resource "azurerm_key_vault_key" "ksm_encryption_key" {
  name         = "ksm-encryption-key"
  key_vault_id = azurerm_key_vault.ksm_key_vault.id
  key_type     = "RSA"
  key_size     = 2048
  key_opts = [
    "decrypt",
    "encrypt",
    ...
    ]
    rotation_policy {
     automatic {
       time_before_expiry = "P30D"
     }
     expire_after        = "P90D"
     notify_before_expiry= "P29D"
   }
 }

設定 Kubernetes 叢集：在建立 Kubernetes 叢集時，我們可以使用這個金鑰來加密秘密。

resource "azurerm_kubernetes_cluster" "ksm_aks" {
  name                = "ksm-aks"
  ...
  key_management_service {
    key_vault_key_id         = azurerm_key_vault_key.ksm_encryption_key.id
    key_vault_network_access = "Public"
  }
  ...
}

稽核日誌中的加解密操作

透過稽核日誌，我們可以監控和驗證 Azure Key Vault 是否正確地進行了秘密的加解密操作。以下是一個日誌範例：

{
  ...
  operationName: “KeyDecrypt”
  ...
}

其中 KeyDecrypt 操作表示正在進行秘密的解密操作。相同地，對於加密操作也會有類別似的日誌記錄。

GCP 的雲端秘密儲存探索

在之前的文章中，玄貓探討了 Azure Key Vault 的使用方式及其與 Kubernetes 的整合。本文將轉向 Google Cloud Platform（GCP），探索 GCP Secret Manager 的功能及其在 Kubernetes 中的應用。

GCP Secret Manager 概述

GCP Secret Manager 是 Google Cloud 提供的一項服務，專門用於儲存和管理敏感機密資料。無論是佈署在 Compute Engine、Kubernetes、Cloud Functions 或其他形式上的應用程式，都可以利用 Secret Manager 安全地存取這些機密資料。

Secret Manager 的特性

GCP Secret Manager 提供了多項預設功能：

IAM（身份與存取管理）：允許細粒度地控制對秘密的存取許可權。
高用性：提供全球範圍內的高用性及災難還原功能。
日誌記錄與監控：內建完整的日誌記錄功能，方便稽核和監控。

IAM：身份與存取管理

GCP 的 IAM 功能允許我們在組織、專案或特定資源層級上分配許可權。以下是一些常見的 IAM 許可權：

組織級別：適用於整個組織內的所有資源。
專案級別：適用於特定專案的所有資源。
資源級別：適用於特定秘密或其他具體資源。

例如，當我們建立一個新秘密時，我們可以為該秘密指定特定的人員或服務帳戶進行存取控制。

高用性與災難還原

Secret Manager 提供全球範圍內的高用性功能。預設情況下，秘密會被複製到多個地區以確保可靠性。如果有特定地區無法存取某些資料時，還可以自行指定所需地區。

日誌記錄與監控

Google Cloud 提供內建日誌記錄功能來跟蹤應用程式及系統活動。針對 Secret Manager 的日誌記錄特別重要：

應用程式日誌：記錄應用程式運作時產生的活動。
稽核日誌：記錄所有對 Secret Manager 的操作行為。

要檢視稽核日誌需具備「私有日誌檢視者」許可權。

工具與技術需求

要進行本文中的實驗操作以及進一步瞭解 GCP Secret Manager 的工作方式, 需要以下工具:

gcloud CLI (https://cloud.google.com/sdk/gcloud#download_and_install_the)
Terraform (https://www.terraform.io/)
kubectl (https://kubernetes.io/docs/reference/kubectl/)

工作負載身份與 GKE 整合

GKE（Google Kubernetes Engine）支援「工作負載身份」功能, 兒玩負載可以直接使用 Google Cloud 身分驗證, 不需要額外處理服務帳戶憑證檔案。這不僅簡化了流程, 同時提升了安全性:

啟動工作負載身份: 在 GKE 中啟動工作負載身份, Google Kubernetes Engine 則會自動為每一工作負載生成服務帳戶, 預設情況下與節點上的服務帳戶相同:

kubectl create namespace gke-namespace --dry-run=client -o yaml | kubectl apply -f -

組態 IAM 模擬:

gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member “serviceAccount:your-gcp-project-id.svc.id.goog[gke-namespace/workload-service-account]” \
your-workload-service-account@your-gcp-project-id.iam.gserviceaccount.com

3.分配工作負載身份

apiVersion: v1
kind: ServiceAccount
metadata:
name: workload-service-account
namespace: gke-namespace
annotations:
iam.gke.io/gcp-service-account: your-workload-service-account@your-gcp-project-id.iam.gserviceaccount.com

GKE 與 GCP Secret Manager 整合

佈署Secret Manager Client:

gcloud components install beta --quiet && gcloud components update beta --quiet && gcloud components install secretmanager --quiet && gcloud components update secretmanager --quiet &&

2.啟動並組態 Secret Manager API:

gcloud services enable secretmanager.googleapis.com --project your-gcp-project-id && \

3.設定環境變數:

export PROJECT_ID="your-gcp-project-id"
export LOCATION="global"
export SECRET_ID="your-secret-id"

4.建立 Secret:

echo -n 'my-secret-value' | gcloud secrets create $SECRET_ID --data-file=-
--replication-policy="automatic"

echo -n 'my-secret-value' | gcloud secrets versions add $SECRET_ID --data-file=- && \

5.建立Service Account:

gcloud iam service-accounts create secret-accessor \
--display-name “SA for Secret Access”

6.分配角色:

gcloud secrets add-iam-policy-binding $SECRET_ID \
--member=”serviceAccount:secret-accessor@$PROJECT_ID.iam.gserviceaccount.com” \
--role=roles/secretmanager.secretAccessor && \

7.佈署Pod:


apiVersion: v1

kind: Pod

metadata:

name: secret-demo-pod

spec:

containers:

– name: demo-container

image: busybox

command: ["/bin/sh", "-c", “sleep infinity”]

env:

– name: SECRET_VALUE

valueFrom:

secretKeyRef:

name: my-secret # The secret name created previously

key: my-secret-key # The key within the secret to use as the value.

次段落標題：內容解說：

在此段落中所描述的是如何組態IAM模擬以及分配工作負載身份給Kubernetes叢集中的Pod,同時也示範如何整合GKE與GCP Secret Manager, 在Pod中透過環境變數從Secret Manager取得所需之機敏值.

玄貓將繼續探討 GKE 與 KMS（Key Management Service）之間的整合方式及實踐細節。

小段落標題：繼續挖掘：GKE 與 KMS 整合實踐細節:

玄貓將繼續探討如何實際佈署與設定KMS為Kubernetes叢集中的Secret進行加解繫結流程(Encryption Decryption Binding).

小段落標題：改進點與未來發展：

如此強大而靈活之Secret Management工具, 不僅僅能提升開發者之效率,更強化了專案之安全性. 未來若有更多其他雲端平台(Such as AWS)出現類別似之工具(例如AWS Secrets manager),玄貓也會持續追蹤研究並撰寫相關文章. 到此玄貓已經完成深入研究GKE 與 KMS 、Secret manager之間之關係、佈署流程及安全考量.

小段落標題：結語：

雖然玄貓已經涵蓋了大量Kubernetes之雲端版本應用場景及工具實施手法, 但隨著時間推移,Kubernetes技術以及雲端平台不斷迭代更新, 玄貓希望大家都能夠持續學習,避免陷入學習陷阱. 若有任何問題,歡迎隨時在下方留言或撰寫新文章向玄貓請教.

此圖示展示從 Kubernetes 工作負載身份到 GCP Secret Manager 呼叫流程：

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title GCP 與 Azure 雲端秘密儲存 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 Pod 傳遞到 GCP Secret Manager 處理流程：Pod 傳遞到 Workload Identity， Workload Identity 傳遞到 Google Cloud Platform Service Account， Service Account 傳遞到調取 Google Cloud Platform Secret Manage API， Google Cloud Platform Secret Manage API 傳遞到 GCP Secret Manage，最後 GCP Secret Manage 處理完成傳回Secret Value給Pod