使用 IAM 保護資源存取權

Kubernetes 使用者和服務帳戶必須具備管理 Config Connector 資源的權限。有了 Config Connector，您就能使用 Kubernetes 角色式存取控管 (RBAC) 的身分，管理專案的控制層。您也可以參考 Identity and Access Management (IAM) 政策。

可參照 IAMPolicy 和 IAMPolicyMember 的資源，列於資源參考資料。這些資源具有「Can Be Referenced by IAMPolicy/IAMPolicyMember」屬性。

本主題說明如何使用 Identity and Access Management，保護 Google Cloud 資源的存取權。

事前準備

在叢集上安裝 Config Connector。

使用 RBAC 保護控制層存取權

在本範例中，您將建立服務帳戶，並授予管理 PubSubTopic 的權限。這個服務帳戶無法管理其他類型的 Config Connector 資源。

  1. 建立名為 pubsub-topic-service-account.yaml 的檔案，並加入以下內容：

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: pubsub-topic-service-account
  namespace: default

    套用這項設定，建立 pubsub-topic-service-account 服務帳戶：

    kubectl apply -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE

    將 CC_NAMESPACE 替換為 Config Connector 管理資源的命名空間。

  2. 確認 pubsub-topic-service-account 無法建立 PubSubTopic 資源，方法是驗證下列指令的輸出內容是否包含 no：

    kubectl auth can-i get pubsubtopics --as=system:serviceaccount:default:pubsub-topic-service-account

  3. 接著，建立可建立 Pub/Sub 主題的 ClusterRole。

    ClusterRole 只能管理在 rules.apiGroups 和 rules.resources 中指定值的資源。如要找出 apiGroups 和 resources 的值，請參閱資源參考資料。

    建立名為 pubsub-topic-editor-role.yaml 的檔案，並在當中加入下列內容：

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: pubsub-topic-editor
rules:
- apiGroups:
  - pubsub.cnrm.cloud.google.com
  resources:
  - pubsubtopics
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete

    套用 pubsub-topic-editor.yaml 建立 ClusterRole：

    kubectl apply -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE

    將 CC_NAMESPACE 替換為 Config Connector 管理資源的命名空間。

  4. 接著，在 ClusterRole 和服務帳戶之間建立 RoleBinding。建立名為 pubsub-topic-editor-rolebinding.yaml 的檔案，並加入以下內容：

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pubsub-topic-editor-rolebinding.
subjects:
- kind: ServiceAccount
  name: pubsub-topic-service-account
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pubsub-topic-editor

  5. 將 pubsub-topic-editor-rolebinding.yaml 套用至叢集。

    kubectl apply -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE

    將 CC_NAMESPACE 替換為 Config Connector 管理資源的命名空間。

  6. 確認 pubsub-topic-service-account 有權建立 PubSubTopic 資源，方法是確認下列指令的輸出內容為 yes：

    kubectl auth can-i get pubsubtopics \
  --as=system:serviceaccount:default:pubsub-topic-service-account

清除所用資源

使用 kubectl delete 移除服務帳戶、IAM 角色和角色繫結。

kubectl delete -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE

將 CC_NAMESPACE 替換為 Config Connector 管理資源的命名空間。

使用 IAM 政策保護資料層

在這個範例中，您會使用先前授予的權限建立 PubSubTopic，並透過 IAMPolicyMember 資源限制其存取權。

  1. 建立名為 pubsub-topic-sample.yaml 的檔案，並加入下列內容：

    apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: pubsubtopic-sample

    使用 kubectl 套用 pubsub-topic-sample.yaml：

    kubectl apply -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE

    將 CC_NAMESPACE 替換為 Config Connector 管理資源的命名空間。

  2. 建立名為 iampolicymember.yaml 的檔案，並加入下列內容，將 EMAIL_ADDRESS 替換為您的 Google Cloud 帳戶電子郵件地址：

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: iampolicymember-sample
spec:
  resourceRef:
    apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
    kind: PubSubTopic
    name: pubsubtopic-sample
  role: roles/pubsub.admin
  member: "user:EMAIL_ADDRESS"

  3. 套用 iampolicymember.yaml。

    kubectl apply -f iampolicymember.yaml  --namespace CC_NAMESPACE

    將 CC_NAMESPACE 替換為 Config Connector 管理資源的命名空間。

  4. 執行下列指令，並在輸出內容中尋找您的電子郵件地址，確認政策已套用至 Google Cloud 。請將 PROJECT_ID 替換為您的專案 ID：

    gcloud beta pubsub topics get-iam-policy projects/PROJECT_ID/topics/pubsubtopic-sample

現在，Pub/Sub 主題的存取權已受到IAMPolicyMember保護。

清除所用資源

使用 kubectl delete 從 Google Cloud 專案中移除 Pub/Sub 主題和 IAMPolicyMember。

kubectl delete -f iampolicymember.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE

多租戶隔離的安全性最佳做法

為防止未經授權的提權，並強制執行租戶隔離，請遵循下列最佳做法：

  • 強制執行命名空間模式：在多租戶環境中避免使用叢集模式。在叢集模式中，所有命名空間都會共用單一 IAM 服務帳戶。任何使用者只要能在任何命名空間中建立 Config Connector 資源，就能以該服務帳戶的完整 IAM 權限執行操作。

  • 限制 IAM 資源的 RBAC：使用 Kubernetes 角色式存取控管 (RBAC)，限制 IAMPolicy、IAMPartialPolicy 和 IAMPolicyMember 資源的建立和修改權限。如果開發人員對這些資源具有廣泛的寫入權限，就能變更 Google Cloud IAM 繫結。

  • 設定 Workload Identity Federation for GKE 的 IAM 繫結範圍：請務必只為特定命名空間中的指定 Kubernetes ServiceAccount 設定這些繫結。在命名空間模式下，請只將各個 IAM 服務帳戶繫結至其命名空間的 Config Connector Kubernetes ServiceAccount：

    gcloud iam service-accounts add-iam-policy-binding \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member="serviceAccount:PROJECT_ID.svc.id.goog[cnrm-system/cnrm-controller-manager-CC_NAMESPACE]" \
    --role="roles/iam.workloadIdentityUser"

    更改下列內容：

    • GSA_NAME：Config Connector 用於命名空間的 IAM 服務帳戶名稱。
    • PROJECT_ID：叢集和 IAM 服務帳戶所在專案的 ID。
    • CC_NAMESPACE：Config Connector 管理資源的命名空間。

    請勿將 roles/iam.workloadIdentityUser 角色授予主體集，例如 cnrm-system 命名空間中的所有 Pod。在命名空間模式中，所有命名空間的 Config Connector 控制器都會在 cnrm-system 中執行，因此這類繫結可讓每個命名空間的控制器模擬 IAM 服務帳戶。

後續步驟

使用密鑰將資訊安全地傳遞至 Google Cloud 資源。