はじめに
アソビューAdvent Calendar 2025の14日目（裏面）です。
こんにちは。アソビューのデータ基盤チームでデータエンジニアをやっている米澤です。
今回は、BigQueryでサービスアカウントの権限を借りてジョブ実行する方法について共有させてもらいたいと思います。
背景
Google Cloudの権限管理方法
まずは、なぜこの記事を書こうと思ったか、背景をご説明します。
アソビューではDWHとしてBigQueryを活用していますが、権限管理はかなり細かく設定しています。
Google Cloudのアカウントに対して権限付与する際は主に以下の2パターンがあるかと思いますが、アソビューでは基本的に前者の「カスタムロール」を用いた権限付与を行っています。
- 各権限の実体である「パーミッション」を「カスタムロール」として付与する
- 事前定義された「ロール（パーミッション群）」を付与する
「ロール」は簡易に権限付与するには楽で良いのですが、意図しない権限を与えることになってしまうので、データ基盤チームではこの方針では権限付与を行っていません。
また、権限はGoogle Cloudの各プロジェクトに対して付与する必要がありますが、BigQueryはジョブ実行権限とデータ閲覧権限をプロジェクトごとに分けており、通常の構成より複雑な形になっています。
これらの構成については以前記事にまとめたことがありますので、詳細を知りたい方はこちらの記事を参照ください。
さらに、最近BigQuery Editionsの利用を開始し、その過程でプロジェクトを追加・整理して、権限付与も再整理した結果、データエンジニアは必要最小限の権限だけになりました。Google Cloudの権限設定は基本的にTerraformで行っているのですが、Terraform用サービスアカウントには強い権限が付与されており、Pull Requestレビューを通した上で権限変更されるので、エンジニア本人に強い権限は必要ありません。
エンジニアとしても、アカウントに余計な権限が付いていると、何かしら問題があった際に原因が特定しづらくなるので、正直余計な権限は持ちたくありません。
通常運用する上では特にこれらの権限管理で問題になることはありません。
※余談ですが、BigQuery Editionsやプロジェクト整理の話は別ブログでもまとめていますので、ご興味あればご一読ください。
権限追加の必要性
しかし、様々なタスクを行う際に、通常の権限では足りないケースが発生します。
例えば最近あった話ですと、外部ツールからAPIを使ってデータを取得しBigQueryのテーブルへ入れるようなシステム開発を行っている際に、対応するプロジェクトのテーブルを更新する権限がなくローカル環境で動作確認できない、という事象が発生しました。
こちらは一例ですが、タスク内容によって足りなくなる権限は様々で、都度必要な権限をアカウントに付与する運用はあまり現実的ではありません。
サービスアカウントの権限借用
権限借用の機能
上記問題への対処法はいくつかあると思いますが、1つの解決策として今回紹介するのが「サービスアカウントの権限借用」です。
機能としては文字通りですが、サービスアカウントに付与した権限を一時的に借りる機能です。
これはGoogle Cloudに機能として用意されています。詳細は以下ページを参照ください。
何かしらGoogle Cloudの機能をツール／システムから利用する際は、専用のサービスアカウントを作成して適切な権限を付与した上で利用しています。 よって、例えばそういったシステムに関連する変更開発を行うタスクの動作確認を行う場合、必要な権限はサービスアカウントに付与済なので、それをサクッと借りてしまおう、という話です。
なお、この方法はどんなケースでも使えるわけではなく、ローカル環境のTerminal上からGoogle Cloudの認証を行なうケースのみ使用できます。あくまで狭い利用範囲でのみ活用できる機能であることはご留意ください。
権限借用の方法
実際に権限を借りるには、まず権限借用するために必要なパーミッション「iam.serviceAccounts.getAccessToken」を含むロールをアカウント＆適切なプロジェクトに対して付与する必要があります。
パーミッションが付与された後は、ローカルのTerminal上で以下コマンドを実行すれば権限を借りることができます。
gcloud auth application-default login --impersonate-service-account [サービスアカウントのメールアドレス]
権限借用のメリット
1. 権限管理が楽
この機能を利用する最大のメリットは「個人アカウントに不要な権限を追加する必要がない」ことです。
仮にタスク対応時に一時的な権限を追加で付与してもらっても、対応が終わってしまうと権限の削除を忘れる等のリスクがどうしても発生してしまいます。10日経ったら自動的に削除される、みたいな仕組みがあれば良いですが、開発するほどの機能でもありません。
その点、この機能は権限を借りるだけなのでお手軽です。
2. セッションが自動的に切れる
前述した gcloud auth application-default login コマンドを使ってログインするとセッションが確立されますが、当然このセッションは一定時間を過ぎると自動的に切れます。サービスアカウントの借用に限らず、ローカルでGoogle Cloudの機能を個人アカウントとして使う場合もこのコマンドを使用しますが、同様の挙動です。
これは見方を変えれば自動的に借用した権限が切れることを意味します。
もちろん、また借用するためのコマンドを叩けば権限は借りられるのですが、一定期間で借用した権限が切れるということは権限管理上のメリットと言って良いと思います。
工夫したポイント
今回の対応で工夫したポイントとしては、サービスアカウントを限定するようにした点です。
前述した権限借用のためのパーミッションが付与されていれば、そのプロジェクトで作成したサービスアカウントはすべて借用できます。中にはTerraform実行用などの強い権限のサービスアカウントも含まれているため、明確なセキュリティリスクになります。それを特定サービスアカウントしか使わない（使えない）ようにして、不要な権限は借用する場合でも与えない、という原則を守るような仕組みにしました。
この「誰がどのサービスアカウントを使えるか」という定義もTerraformでコード化しているため、権限の可視化と適切なレビュープロセスを維持できています。
まとめ
今回はサービスアカウントの権限借用についてご紹介しました。
権限管理を厳格にすると開発生産性が落ちると思われがちですが、この機能を活用することで「必要な時だけ強い権限を持つ」という柔軟な運用が可能になります。
また、強い権限を持っているとオペレーションミスが怖いですが、普段は最小権限、必要な時だけ借用するというスタイルは、エンジニアとしての心理的安全性にも繋がっていると思います。
少しでも多くの方に有用だと感じてもらえれば幸いです。
最後に
アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています。 ご興味がありましたらお気軽にご応募いただければと思います。
