Workload Identityを試す

はじめに

GKE上のPodからGCSなどのGCPサービスを使いたい場合があると思います。
Workload Identityを使用するとGCPのサービスアカウントとKubernetesのサービスアカウントを使ってPodにGCPサービスに対する認可設定が可能です。

登場人物

GCPのサービスアカウント(GSA)
Kubernetesのサービスアカウント(KSA)

機能の概要

GCPのサービスアカウント(GSA)とKubernetesのサービスアカウント(KSA)を紐付けます。
GSAは、Cloud IAM Roleがアタッチされており、Cloud IAM Roleで許可されたGCPサービスの操作が可能となります。
KubernetesのPodは、KSAがアタッチされており、KSAとGSAが紐付けられGSAのIAM roleの権限をPod持つことになります。

チュートリアル

ClusterでWorkload Identityを有効にします。

$ gcloud beta container clusters update <Cluster名> --zone <ゾーン> --workload-pool=<Project ID>.svc.id.goog

GCPのサービスアカウント(GSA)を作成します。

$ gcloud iam service-accounts create test-gsa
Created service account [test-gsa].

GSAにGSAバケットがListできるIAM Roleを追加します

$ gcloud projects add-iam-policy-binding <Project ID> \
  --member serviceAccount:test-gsa@<Project ID>.iam.gserviceaccount.com \
  --role roles/storage.admin

テスト用のNamespaceを作成します。

$ kubectl create namespace sa-test
namespace/sa-test created

Kubernetesのサービスアカウント(KSA)を作成します。

$ kubectl create serviceaccount -n sa-test test-ksa
serviceaccount/test-ksa created

作成したGSAとKSAに対して、IAM RoleをBindingします。

$ gcloud iam service-accounts add-iam-policy-binding \
>   --role roles/iam.workloadIdentityUser \
>   --member "serviceAccount:<Project ID>.svc.id.goog[sa-test/test-ksa]" \
>   test-gsa@<Project ID>.iam.gserviceaccount.com
Updated IAM policy for serviceAccount [test-gsa@<Project ID>.iam.gserviceaccount.com].
bindings:
- members:
  - serviceAccount:<Project ID>.svc.id.goog[sa-test/test-ksa]
  role: roles/iam.workloadIdentityUser
etag: BwWf6tzrlyI=
version: 1

GSAとKSAに追加します。

$ kubectl annotate serviceaccount \
>   --namespace sa-test \
>   test-ksa \
>   iam.gke.io/gcp-service-account=test-gsa@<Project ID>.iam.gserviceaccount.com
serviceaccount/test-ksa annotated

確認します。Pod起動時にサービスアカウントとして作成したKSAを指定します。

kubectl run --rm -it \
  --generator=run-pod/v1 \
  --image google/cloud-sdk:slim \
  --serviceaccount test-ksa \
  --namespace sa-test \
  workload-identity-test

アクティブアカウントの情報を確認します。作成したGSAがアクティブアカウントとなっています。

# gcloud auth list
                   Credentialed Accounts
ACTIVE  ACCOUNT
*       test-gsa@<Project ID>.iam.gserviceaccount.com

To set the active account, run:
    $ gcloud config set account `ACCOUNT`

GCSのバケットリストを確認します。GSAにstorage adminが追加されているため、list表示できます。

# gsutil ls
gs://model/
gs://model-mnist/
gs://model_cloudbuild/

落ち穂拾い

gcloudでの確認

確認の対象で2つあります。

まずはプロジェクトに対して、GSAがどのIAMロールが割り当てられているかですが、こちらは「gcloud projects get-iam-policy」で確認できます。
test-gsa@は、storage adminの権限が割り当てられいます。つまり、test-gsa@を使うと、そのプロジェクトのGCSバケットの操作が全て可能になっています。
こちらは、GSAをリソースとして確認しています。

$ gcloud projects get-iam-policy <Project ID>
- members:
  - serviceAccount:test-gsa@<Project ID>.iam.gserviceaccount.com
  role: roles/storage.admin

これは、IAMの画面で確認出来るものと一致します。

次に、GSAをIdentityとして確認します。コマンドとしては、「gcloud iam service-accounts get-iam-policy 」で確認できます。GSAをIdentityとして確認すると、KSAメンバーとなっており、roles/iam.workloadIdentityUserが割り当てられています。

$ gcloud iam service-accounts get-iam-policy test-gsa@<Project ID>.iam.gserviceaccount.com

bindings:
- members:
  - serviceAccount:<Project ID>.svc.id.goog[sa-test/test-ksa]
  role: roles/iam.workloadIdentityUser
etag: BwWf6yuZM_M=
version: 1

つまり、KSAは、GSAと紐付けられており、iam.workloadIdentityUserロールを使って紐付けられたGSAの権限(=Storage admin)でGCSの操作が出来るということです。

イメージ的には以下になります。

kubectlでの確認

最後にkubectlでKSAの確認をしてみます。

$ k describe serviceaccounts test-ksa  -n sa-test
Name:                test-ksa
Namespace:           sa-test
Labels:              <none>
Annotations:         iam.gke.io/gcp-service-account: test-gsa@<Project ID>.iam.gserviceaccount.com
Image pull secrets:  <none>
Mountable secrets:   test-ksa-token-gt9tb
Tokens:              test-ksa-token-gt9tb
Events:              <none>

投稿内容は私個人の意見であり、所属企業・部門見解を代表するものではありません。