GKEでArtifact RegistryからイメージをPullする際はノードのサービスアカウントが利用される
概要
GKE内で動作するPodがクライアントライブラリ経由でGoogle Cloudのリソース（例: GCSの非構造化データを参照）する場合、
Workload Identity Federation for GKEの利用が推奨されています。
Workload Identity Federation for GKEを利用するためには、新しいKubernetes Service Account（KSA）を作成し、Google Service Account（GSA）と紐付ける or KSAに直接権限を付与する必要があります。
作成したKSAをPodの紐付けることで、クライアントライブラリ経由でGoogle Cloudのリソースの利用が可能になります。
何が起きた？
ある日、新たなNamespaceを作成し、Artifact Registryに格納されているコンテナイメージを利用するPodを作成しました。
Workload Identity Federation for GKEの設定を行う前に、マニフェストをApplyしたところ、問題なくPodが起動しました。
ここで自分は、Workload Identity Federation for GKEの設定をしていないにも関わらず、どういった権限でコンテナイメージのPullが行われるのかという疑問を抱きました。
公式ドキュメントを見ると
公式ドキュメントを確認すると、kubeletによるArticaft RegistryからのコンテナイメージPullは
Workload Identity Federation for GKEではなく、ノード（GCE）に紐付いたSAが利用される旨が記載されていました。
実際に監査ログを見ても、ノードに紐付いたSAがArtifact RegistryからコンテナイメージをPullしていることが確認できました。
注: kubelet による Artifact Registry からのイメージ pull は、Workload Identity Federation for GKE を使用しません。代わりに、これらのイメージの pull では、VM に関連付けられているサービス アカウントが使用されます。
まとめ
- GKEの場合、Artifact RegistryからのコンテナイメージのPullはノードのSAが利用されることがわかりました。
- ノードのSAは、デフォルトではGCEのサービスアカウント（編集者権限）が付与されているので、実運用する場合は適切に権限設定をしたいと思います。
Discussion