IAM を使用したリソースへのアクセスの保護

Kubernetes ユーザーとサービス アカウントには、Config Connector リソースを管理するための権限が必要です。Config Connector を使用すると、Kubernetes のロールベース アクセス制御（RBAC）を使用する ID で、プロジェクトのコントロール プレーンを管理できます。また、Identity and Access Management（IAM）ポリシーを参照することもできます。

IAMPolicy と IAMPolicyMember を参照できるリソースは、リソース リファレンスに一覧表示されています。これらのリソースには、「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 は、リソースを管理するNamespace Config Connector に置き換えます。

  2. 次のコマンドの出力に no が含まれていることを確認して、pubsub-topic-service-account が PubSubTopic リソースを作成できないことを確認します。

    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 は、リソースを管理する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 は、リソースを管理するNamespace Config Connector に置き換えます。

  6. 次のコマンドの出力が yes であることを確認して、pubsub-topic-service-account が PubSubTopic リソースの作成を許可されていることを確認します。

    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 は、リソースを管理する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 は、リソースを管理する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 は、リソースを管理する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

マルチテナント分離のセキュリティに関するベスト プラクティス

不正な権限昇格を防止し、テナントの分離を適用するには、次のベスト プラクティスに従ってください。

  • 名前空間モードを適用する: マルチテナント環境ではクラスタモードを避けます。クラスタモードでは、すべての Namespace が 1 つの IAM サービス アカウントを共有します。任意の Namespace で Config Connector リソースを作成できるユーザーは、そのサービス アカウントの完全な IAM 権限で操作できます。

  • IAM リソースの RBAC を制限する: Kubernetes のロールベース アクセス制御（RBAC）を使用して、IAMPolicy、IAMPartialPolicy、IAMPolicyMember リソースの作成権限と変更権限を制限します。デベロッパーがこれらのリソースに対する広範な書き込みアクセス権を持っている場合、 Google Cloud IAM バインディングを変更できます。

  • Workload Identity Federation for GKE の IAM バインディングのスコープを設定する: これらのバインディングは、特定の Namespace 内の指定された Kubernetes ServiceAccount に対してのみ構成します。Namespace が指定されたモードでは、各 IAM サービス アカウントをその Namespace の 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 が Namespace に使用する IAM サービス アカウントの名前。
    • PROJECT_ID: クラスタと IAM サービス アカウントを含むプロジェクトの ID。
    • CC_NAMESPACE: Config Connector がリソースを管理する Namespace。

    cnrm-system Namespace 内のすべての Pod など、プリンシパル セットに roles/iam.workloadIdentityUser ロールを付与しないでください。名前空間モードでは、すべての名前空間の Config Connector コントローラが cnrm-system で実行されるため、このタイプのバインディングにより、すべての名前空間のコントローラが IAM サービス アカウントになりすますことができます。

次のステップ

Secret を使用して、 Google Cloud リソースに情報を安全に渡します。