はじめに
業務の中でGoogle Cloudを触っていて、権限周りで学びがあったので、
備忘録も兼ねて残したいと思います。
発生した問題
Google Cloud Storageへのファイルアップロード機能を開発中、署名付きURL生成機能をローカル環境で動作確認しようと思い
Google CloudのADC（Application Default Credentials）を使用して認証情報を作成し、処理を実行すると、以下のエラーが表示されました：
Error: Cannot sign data without `client_email`.
at GoogleAuth.sign (/node_modules/google-auth-library/build/src/auth/googleauth.js:790:19)
at async sign (/node_modules/@google-cloud/storage/build/cjs/src/signer.js:229:35) {
name: 'SigningError'
}
原因の調査
ADCで認証情報を作成した場合には
Linux / macOS: $HOME/.config/gcloud/application_default_credentials.json
に格納されるので、中身を確認すると
確かにclient_emailフィールドが存在しませんでした。
調査の結果、client_emailはサービスアカウントの認証情報にのみ含まれる情報であることが判明しました。
解決策：権限借用（Service Account Impersonation）
Google Cloudの公式ドキュメントを参考に、権限借用という機能を使用することで問題を解決できました。
権限借用とは、サービスアカウントの認証情報を自分のアカウントの認証情報として使用できる機能です。
手順
1. Service Account Credentials APIの有効化
まず、プロジェクトでService Account Credentials APIを有効にします。
2. サービスアカウントへの権限付与
利用したいリソース（今回の場合はGoogle Cloud Storageだったので「Storage Object Creator 」）に対する適切な権限をサービスアカウントに付与します。
3. IAMロールの付与
自分のメールアドレスに対して、対象のサービスアカウントに対する「サービスアカウント トークン作成者」（roles/iam.serviceAccountTokenCreator）のIAMロールを付与します。
ここまでの設定はGoogle Cloud コンソールから実行できます。
4. gcloudコマンドでの設定
前提条件：gcloudコマンドが使用可能であること
プロジェクトの設定
gcloud config set project {プロジェクトID}
権限借用の設定
gcloud config set auth/impersonate_service_account {サービスアカウントのEメール}
ADCの更新
gcloud auth application-default login --impersonate-service-account {サービスアカウントのEメール}
5. 設定確認
以下のコマンドで設定が正しく適用されているか確認します：
gcloud config list
期待される出力：
[auth]
impersonate_service_account = {サービスアカウントのEメール}
[core]
account = {自分のメールアドレス}
disable_usage_reporting = False
project = {プロジェクトID}
この状態になれば設定完了です。
結果
これにより、サービスアカウントが持っている認証情報をローカル環境でも使用できるようになり、署名付きURL生成機能が正常に動作するようになりました。
権限借用を使用することで、Google Cloud環境で実際に使用するサービスアカウントの認証情報を使って動作確認ができるため、動作確認の信頼性が大幅に向上します。個人アカウントとサービスアカウントで権限や設定が異なる場合でも、本番環境と同等の条件でテストが可能になります。
設定の解除
権限借用を無効にして、自分のアカウントの認証情報のみを使用する状態に戻すには、以下のコマンドを実行します：
gcloud config unset auth/impersonate_service_account --quiet
権限借用使用時の注意点
権限借用を使用する際は、以下の点に注意が必要です：
セキュリティに関する注意
- 強力な権限の扱い：サービスアカウントが持つ権限をそのまま使用するため、不要に強い権限を持つサービスアカウントの借用は避ける
- アクセス範囲の確認：借用するサービスアカウントがどのリソースにアクセス可能かを事前に確認する
- ログの監視：権限借用の使用は監査ログに記録されるため、組織のセキュリティポリシーに従って適切に管理する
運用に関する注意
- 設定の忘れ：権限借用の設定をしたまま忘れがちなので、作業完了後は必ず設定を解除する
- 複数プロジェクト：複数のプロジェクトで作業する場合、どのサービスアカウントを借用しているか定期的に確認する
- チーム共有：チームメンバーと設定を共有する際は、適切な権限レベルのサービスアカウントを使用する
トラブルシューティング
- 権限エラー：借用したサービスアカウントに必要な権限が不足している場合は、サービスアカウント自体の権限を見直す
- API有効化：Service Account Credentials APIが無効になっていると権限借用が機能しないため、APIの状態を確認する
Docker環境での補足
Docker内からGoogle Cloudに対してリクエストを送る際は、ローカルの認証情報をDocker内にマウントする必要があります。認証情報ファイルが適切にマウントされていない場合、権限借用の設定をしていても認証エラーが発生するので注意が必要です。
詳細な設定方法については、こちらの記事が参考になります。
まとめ
Google Cloudの権限借用機能を使用することで、ローカル開発環境でもサービスアカウントの権限を活用できるようになります。この方法は、ステージングや本番環境と同等の権限設定でローカルテストを行いたい場合に特に有効になります。
設定は比較的簡単で、一度設定すれば継続的に使用できるため、類似の問題に直面した際の解決策として覚えておくと便利です。