🪪

Cloud Run のサービス アカウントの基本

2023/12/06に公開

2023年は「Cloud Run を触って覚える」をテーマとした一人アドベントカレンダーを一人で開催しており、Cloud Run のさまざまな機能や、Cloud Run でよく使う構成などを実際の使い方と一緒にご紹介しています。

https://qiita.com/advent-calendar/2023/cloud-run

6日目は Cloud Run のサービス アカウントについて、サービスアカウントとは何か?というところから Cloud Run サービスで扱うコツについてご紹介します。

Cloud Run の概要は技術評論社さまのブログ「gihyo.jp」に寄稿した記事で解説していますのでこちらもぜひご覧ください。

https://gihyo.jp/article/2023/10/modern-app-development-on-google-cloud-03

サービス アカウントとは?

サービス アカウントは、ざっくり一言でいうと「ユーザー以外 (サービスやシステム) のためのアカウント」です。

Google Cloud の各サービスは基本的に API で提供しており、これらの API を実行するには、対象の API の呼び出しが許可されたアカウントが必要です。

ユーザーの場合、ユーザーが持っている Google アカウントの認証情報を使って API を呼び出す形になります。例えばユーザーが Cloud Storage バケットにファイルをアップロードする場合、そのユーザーの Google アカウントを使ってアップロード用の API を呼び出す形になります。

ユーザー アカウントの認証

サービスやシステム自体が Google Cloud のサービスの API を呼び出す場合、ユーザー用の Google アカウントではなく サービス アカウント という特別なアカウントを使います。

例えば Compute Engine インスタンス内のアプリケーションから Cloud Storage バケットにファイルをアップロードしたい場合、API を呼び出す元はユーザーではなく Compute Engine インスタンス自体になります。Compute Engine インスタンスにはサービス アカウントを設定することができ、そのサービス アカウントを使ってアップロード用の API を呼び出す形になります。

サービス アカウントの認証

「アプリケーションから API を呼び出す場合は、呼び出し元がユーザーではなくシステムである」という感覚が掴めると、サービス アカウントがなぜ必要なのかしっくり来ると思います。

Cloud Run におけるサービス アカウント

Cloud Run における、他の Google Cloud サービスの呼び出しについて考えてみましょう。

Cloud Run の場合も Compute Engine インスタンスの場合と同様、ユーザーではないシステムのためサービス アカウントを使って API を呼び出します。

なお、サービス アカウントは Cloud Run サービス全体ではなく、リビジョンに設定する形になっています。Cloud Run サービスのコンテナ インスタンスはリビジョンの設定を元に起動し、他の Google Cloud サービスの API の呼び出しが必要な場合はリビジョンに設定されているサービス アカウントが使われます。

Cloud Run サービスへのサービス アカウントの設定・確認方法

Cloud Run サービスにはどのようにサービス アカウントを設定するのか説明します。

Cloud Run サービスの新規作成時に付与する

まず Cloud Run サービスを新規作成する場合は [セキュリティ] タブから設定できます。デフォルトでは [Default compute service account] が設定されています。

Cloud Run 作成時のサービス アカウントの設定

ドロップダウンメニューを開くと、Google Cloud プロジェクト内ですでに作られているサービス アカウントが一覧できます。ここから [新しいサービス アカウントの作成] をクリックすると、Cloud Run サービスの作成画面からサービス アカウントを作成することができます。

サービス アカウントの作成

Cloud Run サービスの名前を入力していると、サービス アカウントの名前に反映されるので手間なく作成することができます。

サービス アカウントの設定

サービス アカウントの作成ウィザード内で、IAM Role を付与することもできます。すでに付与したい IAM Role が決まっている場合は作成時に付与できるので手間がかかりません。

IAM Role の付与

既存の Cloud Run サービスに付与する

すでに Cloud Run サービスを作成している場合、新しいリビジョンに対して設定を行うことができます。

まず既存のリビジョンに設定されているサービス アカウントを確認するには、Cloud Run サービスの詳細画面の [リビジョン] タブから確認できます。

サービス アカウントの確認

サービス アカウントを変更したい場合は [新しいリビジョンの編集とデプロイ] をクリックします。

新しいリビジョンの編集とデプロイ

新規作成時と同様に [セキュリティ] タブから変更できます。

サービス アカウントの変更

新しく作成されたリビジョンに対してサービス アカウントが設定され、このリビジョンから作られたコンテナ インスタンスは変更後のサービス アカウントを使って認証を行うようになります。

気をつけた方が良いこと

デフォルトは Compute Engine のデフォルト サービス アカウントになっているので注意

上述の通り、Cloud Run サービスのサービス アカウントの設定を何も行わない場合、デフォルトで Compute Engine サービスアカウントが設定されます。

このサービス アカウントは Google が管理するサービス アカウントで、Google Cloud プロジェクト内の編集者ロールが付与されています。編集者ロールは比較的強い権限を持っているので、Cloud Run サービスには必要のない権限まで付与されてしまいます。

https://cloud.google.com/compute/docs/access/service-accounts?hl=ja#default_service_account

最小限の権限を与える原則から、Compute Engine のデフォルト サービス アカウントを使うことは避け、Cloud Run サービスごとにサービス アカウントを用意することが推奨されています。

https://cloud.google.com/run/docs/configuring/service-accounts?hl=ja

デフォルトでは、Cloud Run サービスまたはジョブは、デフォルトの Compute Engine サービス アカウントとして実行されます。ただし、最小の権限セットでユーザー管理のサービス アカウントを使用することをおすすめします。

リリース後に権限を減らすことは難しい

特に Compute Engine のデフォルト サービス アカウントを設定した状態に関する話題です。

アプリケーションが多くのサービスの API を呼び出している場合、気づかないうちに「Compute Engine のデフォルト サービス アカウントだから認証が通っている API を使っている」なんて場合もあります。

この状態では本来必要な権限を特定する必要がありますが、権限を減らしていく形になるため場合によっては必要な権限を誤って減らしてしまう可能性があります。リリース後にこのオペレーションを行うのはリスクが高いため、始めから必要な権限を把握し設定した状態で開発を進めていくことが理想です。

まとめ

サービス アカウントは Cloud Run のみならずほぼ全ての Google Cloud サービスを使う上での基本になっています。この記事でサービス アカウントがどういう役割を担っているのか、理解いただけたら幸いです。

Google Cloud Japan

Discussion