3 つのユース ケースで学ぶ GCP のサービス アカウント

※この投稿は米国時間 2019 年 4 月 10 日に Google Cloud blog に投稿されたものの抄訳です。

Google Cloud Platform（GCP）上でアプリケーションを構築している方であれば、サービス アカウントのことはよくご存じでしょう。これはアプリケーションか仮想マシン（VM）に属する特殊な Google アカウントで、ID として、もしくはリソースとして扱うことができます。サービス アカウントでは、管理方法やリソースへのアクセス権限の付与方法がユース ケースによって異なります。この投稿ではサービス アカウントの一般的なユース ケースをいくつか取り上げますので、サービス アカウント管理の適切な運用モデルを決定するうえで参考にしていただきたいと思います。

ユース ケース 1 : GCP リソースにアクセスするウェブ アプリケーション

ユーザーが Cloud Identity-Aware Proxy（IAP）から認証を受けてウェブ アプリケーションにアクセスしているとします。GCP リソースを利用するウェブ アプリケーションにアクセスできるユーザーの場合は、GCP リソースに対する直接的なアクセス権限を持つ必要はありません。こうしたウェブ アプリケーションは、Cloud Datastore といった GCP サービスへのアクセス権限を、サービス アカウントを使って獲得します。この場合、サービス アカウントはウェブ アプリケーションと一対一で対応します。つまり、サービス アカウントはウェブ アプリケーションの ID なのです。最初に、ウェブ アプリケーションをホスティングする GCP プロジェクトでサービス アカウントを作成します。次に、GCP リソースへのアクセスに必要な権限を、そのサービス アカウントに付与します。そして最後に、サービス アカウントの認証情報を使用するようにウェブ アプリケーションを設定します。

ユース ケース 2 : 複数のコスト センターに対する BigQuery 使用料の請求

このシナリオでは、部門のユーザーはカスタムビルドのアプリケーションを使用して、BigQuery の共有データセットにクエリを送ります。このとき、クエリによって発生する料金は、ユーザーが所属するコスト センターに請求する必要があるため、VM 上で実行されるアプリケーションに対しては、BigQuery データセットへのクエリ発行権限を有するサービス アカウントが与えられます。

プロジェクトで使用されるリソースが請求書に反映されるようにするため、各部門の一連のプロジェクトにはラベルを付与します。また各部門は、部門に割り当てられたプロジェクトからアプリケーションを実行する必要があります。これにより、BigQuery に対するクエリ料金が、その部門に適切に請求されるようになります。

クエリを発行する各部門のプロジェクトにこのシナリオを適用するには、BigQuery データセットへのクエリ発行に必要な IAM 権限を、アプリケーションのサービス アカウントに割り当てます。

このシナリオによる権限設定の詳細はこちらをご覧ください。

ユース ケース 3 : 運用、管理作業で使われるサービス アカウントの管理

この場合、さまざまなタスクを実行できるようにするため、適切な権限を持つサービス アカウントを複数作る必要があります。これらのサービス アカウントは、上位の特権を持ち、階層内の適切なレベルで権限を付与されているはずです。そして、他のサービス アカウントと同様に、権限のないユーザーに情報が漏れることのないよう、ベスト プラクティスに従う必要があります。たとえば、こういった運用のためにサービス アカウントを作成したプロジェクトでは、サービス アカウントが誤って削除されないようにするため、プロジェクト リーエンを追加すべきです。

サービス アカウントの奥の深さ

• サービス アカウントを使用した Cloud Platform への認証
• サービス アカウントの認証情報を使用したアプリケーションの認証
• AppEngine におけるサービス アカウント