在 Kubernetes 環境中,保護敏感資料至關重要。GCP Secret Manager 提供安全的秘密儲存機制,結合 GKE 的 Workload Identity 功能,可以讓 Kubernetes Pod 直接存取 Secret Manager 中的秘密,無需額外管理服務帳戶金鑰。本文將逐步說明如何使用 Terraform 建立 GKE 叢集,並整合 GCP Secret Manager 與 Workload Identity,同時提供監控和評估秘密使用情況的最佳實務。首先,我們會建立一個 GKE 叢集,並啟用 Workload Identity 功能,讓 Pod 可以繼承 GCP 服務帳戶的許可權。接著,我們會在 Secret Manager 中建立秘密,並設定必要的許可權,允許 GKE 叢集中的 Pod 讀取秘密。然後,我們會使用 Kubernetes Secrets Store CSI 驅動程式將 Secret Manager 中的秘密掛載到 Pod 中,讓應用程式可以輕鬆存取。最後,我們會探討如何使用 GCP 的日誌和監控功能來追蹤秘密的使用情況,並利用 GKE 安全態勢儀錶板強化叢集安全性。透過這樣的整合,我們可以簡化秘密管理流程,並提升 Kubernetes 應用程式的安全性。
進階 Google Cloud 秘密管理:整合 Workload Identity 與 Kubernetes
Workload Identity 簡介
在 Google Kubernetes Engine (GKE) 上,Workload Identity 允許我們將 Kubernetes 工作負載與 Google Cloud 資源進行許可權繫結。這是根據 Google Cloud 的服務帳戶概念,服務帳戶用於機器與資源的互動。無論是計算引擎、Lambda 函式還是應用程式引擎,都可以繫結具有特定許可權的服務帳戶,從而與 Google Cloud 資源進行互動。
在 Kubernetes 中,我們可能會使用多種佈署方式來執行應用程式,如 Deployment、StatefulSet、DaemonSet 等。這些佈署方式背後都會建立 Pod,而 Pod 是 Kubernetes 中執行應用程式的基本元件。Pod 可以繫結服務帳戶,透過 Workload Identity 和 Kubernetes 服務帳戶與 Google Cloud 服務帳戶的繫結,Pod 就能根據 Google Cloud 服務帳戶的許可權與 Google Cloud 資源進行互動。
這一概念對於 GCP Secret Manager 特別有幫助。透過 Kubernetes CSI 和 Workload Identity 的整合,我們的 Kubernetes 工作負載能夠授權並存取 Secret Manager。
整合 GKE 與 GCP Secret Manager
透過 CSI Secret Store 外掛,我們可以將 Secret Manager 與 Kubernetes 叢集進行整合。Google Cloud 提供的 Kubernetes 支援是 Google Kubernetes Engine (GKE),我們將使用這個叢集來整合 Secret Manager。
以下是使用 Terraform 建立 GKE 叢集的步驟:
組態 Terraform 專案
首先,我們需要組態 Terraform 提供者,指向 GCP 認證檔案和專案:
provider "google" {
credentials = "/path/to/credentials/file"
project = "your-gcp-project"
region = "us-central1"
}
初始化 Terraform:
$ terraform init
若未指定認證檔案,則預設為使用 gcloud auth login 命令登入的使用者認證。另一個選擇是指定服務帳戶檔案。
組態網路
在 Google Cloud 上組態網路。網路是全域性資源,而子網則是區域資源:
resource "google_compute_network" "vpc" {
name = "${var.project_id}-vpc"
auto_create_subnetworks = false
project = var.project_id
}
建立子網來託管 Kubernetes 的節點:
resource "google_compute_subnetwork" "subnet" {
name = "${var.project_id}-subnet"
region = var.region
network = google_compute_network.vpc.name
ip_cidr_range = "10.10.0.0/24"
project = var.project_id
}
在 Secret Manager 中建立秘密
在 Secret Manager 上建立秘密:
resource "google_secret_manager_secret" "my_secret" {
secret_id = "my-secret"
replicas {
location = var.location
}
replicas {
location = "us-east1"
}
}
這樣設定使得秘密在兩個區域中都有副本,增加了秘密使用的韌性。
新增秘密版本
為秘密新增版本:
resource "google_secret_manager_secret_version" "my_secret_version" {
secret = google_secret_manager_secret.my_secret.id
secret_data = "secret-data"
}
組態服務帳戶
建立一個具有檢索秘密許可權的服務帳戶:
resource "google_service_account" "my_service_account" {
account_id = "read-secrets-service-account"
}
resource "google_secret_manager_secret_iam_binding" "my_secret_reader" {
role = "roles/secretmanager.secretAccessor"
secret_id = google_secret_manager_secret.my_secret.id
members = [
"serviceAccount:${google_service_account.my_service_account.email}"
]
}
建立 GKE 叢集
最後,我們可以建立 GKE 叢集了。完成這些步驟後,我們的 Kubernetes 工作負載將能夠授權存取 GCP Secret Manager 中的秘密。
建立 GKE 叢集
resource "google_container_cluster" "primary" {
name = "${var.project_id}-gke-cluster"
location = var.region
node_config {
machine_type = "n1-standard-1"
service_account_email = google_service_account.my_service_account.email
oauth_scopes = [
"https://www.googleapis.com/auth/cloud-platform",
]
tags = ["gke-node"]
metadata = {
disable-legacy-endpoints = true
}
workload_metadata_config {
node_metadata = "GKE_METADATA_SERVER"
}
}
}
摘要
玄貓在本文中詳細介紹瞭如何利用 Workload Identity 和 Google Kubernetes Engine (GKE) 與 Google Cloud Secret Manager 整合。這不僅能提升安全性,還能讓我們更靈活地管理和存取秘密資料。透過 Terraform 的組態和實施步驟,我們可以順利地佈署和管理整個叢集環境。
如果你對技術細節有任何疑問或需要進一步的幫助,歡迎隨時聯絡玄貓!
探索 GCP 上的雲端機密儲存
在 Google Cloud Platform (GCP) 上,管理機密資訊是確保應用程式安全的關鍵。本文將探討如何在 GCP 上建立和管理 Kubernetes 秘密,並結合 Google Kubernetes Engine (GKE) 和 GCP Secret Manager 來實作這一目標。
設定 GKE 叢集
首先,我們需要在 GCP 上建立一個 GKE 叢集。這個叢集將作為我們的工作負載執行環境。以下是使用 Terraform 建立 GKE 叢集的基本步驟:
resource "google_container_cluster" "gke_cluster" {
name = "secrets-cluster"
location = var.region
remove_default_node_pool = true
initial_node_count = 1
network = google_compute_network.vpc.name
subnetwork = google_compute_subnetwork.subnet.name
workload_identity_config {
workload_pool = "kube-secrets-book.svc.id.goog"
}
}
在這段程式碼中,我們建立了一個名為 secrets-cluster 的 GKE 叢集,並設定了初始節點數量為1。此外,我們啟用了 workload_identity_config,這允許我們使用 Kubernetes 工作負載身份來存取 GCP 資源。
內容解密:
name: 指定叢集的名稱。location: 指定叢集的區域。remove_default_node_pool: 設定為true,表示移除預設節點池。initial_node_count: 初始節點數量。network和subnetwork: 指定叢集所在的 VPC 網路和子網路。workload_identity_config: 啟用工作負載身份組態。
接下來,我們需要建立一個自定義的節點池來替代預設節點池。這樣可以更靈活地調整節點池的引數:
resource "google_container_node_pool" "primary_nodes" {
name = "${google_container_cluster.gke_cluster.name}-nodes"
cluster = google_container_cluster.gke_cluster.name
version = data.google_container_engine_versions.gke_version.release_channel_latest_version["STABLE"]
node_count = 1
node_config {
oauth_scopes = [
"https://www.googleapis.com/auth/logging.write",
"https://www.googleapis.com/auth/monitoring",
]
machine_type = "n1-standard-1"
tags = ["gke-node", "${var.project_id}-gke"]
disk_size_gb = 10
metadata = {
disable-legacy-endpoints = "true"
}
}
}
內容解密:
name: 指定節點池的名稱。cluster: 指定此節點池所屬的叢集。version: 指定 Kubernetes 的版本。node_count: 指定初始節點數量。oauth_scopes: 指定 OAuth 指令碼範圍。machine_type: 指定機器型別。tags: 指定標籤。disk_size_gb: 指定磁碟大小。metadata: 自定義後設資料。
整合 GKE 和 GCP Secret Manager
完成叢集建立後,我們可以使用以下命令登入叢集並檢視節點狀態:
$ gcloud container clusters get-credentials secrets-cluster --region us-central1 --project kube-secrets-book
$ kubectl get nodes
這些命令會將叢集憑證下載到本地並列出所有節點的狀態。
安裝 CSI 外掛
接下來,我們需要安裝 Kubernetes Secrets 的 CSI 外掛。CSI 外掛允許我們將秘密掛載到 Pod 中。以下是安裝步驟:
$ helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts
$ helm install csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver --namespace kube-system
$ kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp/main/deploy/provider-gcp-plugin.yaml
安裝完成後,我們需要建立一個 Kubernetes 傳統服務帳戶並進行註解:
$ kubectl create serviceaccount read-secret --namespace=default
$ kubectl annotate serviceaccount read-secret \
--namespace=default \
iam.gke.io/gcp-service-account=read-secrets-service-account@test-gcp-project.iam.gserviceaccount.com
這樣,Kubernetes 傳統服務帳戶就能代替 GCP 傳統服務帳戶來存取 Secret Manager 中的秘密。
建立 SecretProviderClass
SecretProviderClass 是一種自訂資源型別,提供 CSI 驅動程式組態和引數。以下是一個示例組態:
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: app-secrets
spec:
provider: gcp
parameters:
secrets: |
- resourceName: "projects/project-i/secrets/my-secret/versions/latest"
path: "good1.txt"
建立 Pod 搭配 SecretProviderClass
最後,我們需要建立一個 Pod,並使用上述 SecretProviderClass 搭配 Secret Manager 中的秘密:
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
serviceAccountName: mypodserviceaccount
containers:
- name: mycontainer
image: myimage
volumeMounts:
- mountPath: "/var/secrets"
name: mysecret
readOnly: true
csi:
driver: secrets-store.csi.k8s.io
volumeAttributes:
secretProviderClass: "app-secrets"
內容解密:
serviceAccountName: 指定服務帳戶名稱。volumeMounts: 指定掛載路徑和卷名稱。csi.driver: 指定 CSI 驅動程式。volumeAttributes.secretProviderClass: 指定 SecretProviderClass 名稱。
評估與監控秘密使用情況
完成秘密掛載後,我們可以透過稽核日誌和監控來評估秘密的使用情況。Google Cloud 提供了強大的日誌和稽核功能,可以幫助我們追蹤所有與秘密相關的操作。
日誌查詢範例
protoPayload.methodName="io.k8s.core.v1.secrets.create"
protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
resource.type="k8s_cluster"
這個查詢可以幫助我們找到所有與建立秘密相關的操作日誌。
GKE 安全態勢儀錶板
GKE 安全態勢儀錶板是一個強大的工具,能夠幫助我們提升叢集的安全性。它會掃描叢集和工作負載,提供具體的安全建議。以下是儀錶板的一些主要功能:
- Kubernetes 安全態勢: 掃描並顯示叢集中的漏洞。
- 工作負載漏洞掃描: 檢查執行中的容器映像和程式語言套件中的漏洞。
權重與轉向圖表說明
graph TD;
A[GKE 叢集] --> B[Kubernetes 安全態勢];
A --> C[工作負載漏洞掃描];
B --> D[漏洞掃描結果];
C --> E[容器映像漏洞];
C --> F[程式語言套件漏洞];
權重與轉向圖說明:
此圖示展示了GKE 安全態勢儀錶板如何掃描叢集與工作負載並提供安全建議。從GKE 叢集開始, 儀錶板會掃描Kubernetes 安全態勢以及工作負載漏洞掃描。Kubernetes 安全態勢部分會顯示漏洞掃描結果, 而工作負載漏洞掃描則會檢查容器映像及程式語言套件中的漏洞。
透過這些步驟和工具,我們可以在 GCP 上有效地管理和監控 Kubernetes 底下的機密資訊,確保應用程式的安全性。