既存のGoogle Kubernetes Engine（GKE）クラスターにWorkload Identityを導入する機会がありましたので、Workload Identityについて軽く紹介しようと思います。
Workload Identityとは
ドキュメントにありますように：
Workload Identity allows a Kubernetes service account in your GKE cluster to act as an IAM service account.
Workload Identityを使えばGKEクラスター内のservice accountをGCPのIAM service accountに紐づけることができます。要するに、GKEで動いているアプリケーションがGoogle Cloud APIsに認証するための仕組みだということが分かります。
Workload Identityが有効になっていない場合は
AutopilotモードではWorkload Identityがデフォルトになっていますが、Standardモードの場合、現時点ではまだデフォルトではありませんので、その場合Goocle Cloud APIsをアクセスするには以下のいずれかの仕組みを利用する必要があります：
- IAM service accountのkeyを発行して、secretとしてクラスターで持っておく
- Nodeに紐づけられているIAM service accountを利用する。こちらの場合、設定を変更しない限りCompute Engine default service accountが使われる
Workload Identityでどう変わるのか
Workload Identityを使う場合、事前にKubernetes service accountとIAM service accountの紐づけをしておく必要があります。そして、PodにそのKubernetes service accountを指定した場合、Google Cloud APIsをアクセスする際に該当のIAM service accountが使われるようになります。
この仕組みを使うことでもっと細かい権限の設定ができ、他の仕組みの以下の問題を解決することができます。
- IAM service accountのkeyを使った場合の漏洩のリスク、そしてkeyのローテーションの必要性がなくなります
- NodeのIAM service accountを利用する場合は、そのnodeで実行されている全てのアプリケーションが同じservice accountを共有することになりますので、権限を多く与えすぎてしまうという懸念があります。ですが、Workload Identityの場合、各アプリケーションに必要最低限の権限が付与できるようになります
導入の流れ
手順はドキュメントでご確認いただけますが、大まかな流れとしては以下になります。
- クラスターでWorkload Identityの有効化
- Workload Identityが有効なnode poolの作成
- Kubernetes service account、IAM service accountの作成、そして紐付け
- アプリケーションのDeploymentなどのPod specでKubernetes service accountの指定：
spec:
serviceAccountName: KSA_NAME
nodeSelector:
iam.gke.io/gke-metadata-server-enabled: "true"
こちらの変更を適応することで、PodはWorkload Identityが有効なnodeに立ち上げられることになります。
まとめ
GKEクラスターからのGoogle Cloud APIsへのアクセスにあたって、Workload Identityは以前存在していた問題を色々解決してくれますので、GCPに推奨され将来的にStandardモードでもデフォルトで有効になるとされています。
現在、利用したい機能によってはクラスターでWorkload Identityが有効であることが必要条件になっている場合があります。例：Backup for GKE。
