サービスアカウントの権限借用を使って、docker push/pull 可否を検証する方法
クラウドエースの亀梨です。皆様、Google Cloud Container Registry の EOL 対応はお済みでしょうか?
2025 年 3 月 18 日以降、Container Registry は提供終了となります。
https://cloud.google.com/container-registry/docs/support/deprecation-notices?hl=ja
まさにこの、Container Registry の EOL 対応のために検証していたところ、意外な盲点に気付いたので筆を執りました。
docker コマンドと gcloud コマンドの連携は完璧ではない
gcloud auth configure-docker
というコマンドがあります。
このコマンドを実行すれば、現在 Google Cloud SDK で認証されている Google アカウントの認証情報を docker コマンドに認識させることができます。
Google Cloud の docker コンテナ関連プロダクトへの認証を一元管理することができ、大変便利です。
しかし、あるケースにおいては、この認証連携が正常に動作しません。
ユースケース
たとえば、Cloud Build で動いているパイプラインの Container Registry から Artifact Registry への移行をテストしたい場合、「私自身の Google アカウント」ではなく、「Cloud Build のサービスアカウント」の権限において、push/pull 可否を検証しなければなりません。
そんなケースも Google Cloud SDK は想定してくれています。 --impersonate-service-account
オプションです。
このオプションを用いることで、手元の gcloud コマンドの認証情報を、サービスアカウントそのものの認証情報に化けさせることができるのです。
ただし、このオプションは gcloud auth configure-docker
に非対応です。
--impersonate-service-account
オプションを付けて実行すると、エラーなくコマンドが終了しますが、単純に無視されてしまいます。( サービスアカウントではないアカウントとして実行されます )
解決策
docker login
というコマンドがあります。
docker コマンドの認証情報を上書きするコマンドです。上書きをやめるには、 docker logout https://REPO_URL
を実行します。
gcloud auth print-access-token --impersonate-service-account ACCOUNT
と docker login
を組み合わせることで、権限借用したサービスアカウントのトークンをもとに、 docker の認証情報を書き換えます。
公式ドキュメントからの引用そのままですが、コマンド全体を紹介します。 Artifact Registry を認証する場合の例です。
gcloud auth print-access-token \
--impersonate-service-account ACCOUNT | docker login \
-u oauth2accesstoken \
--password-stdin https://LOCATION-docker.pkg.dev
まとめ
docker コマンド認証の意外な落とし穴のお話でした。この現象に遭遇するまで、正直言って docker コマンドがどのようにレジストリと認証情報を交換しているのか、意識したことがありませんでした。
いい機会になったと思います。
Discussion