はじめのGCP⑰サービスアカウントの概要と認証方法について説明します!

クラウド

今回は、Google Cloudサービスで使用するサービスアカウントの概要と認証方法について説明します。現在、私の参画しているプロジェクトでは、Google Cloudのサービスアカウントにおける認証方法を変更するタスクがあります。認証方法について色々調査しましたが、わかりやすいサイトがなかったので、自分で作成しました。今後、Google Cloudサービスを使う人向けに、サービスアカウントの概要と認証方法について説明します。

是非、最後までご覧いただけると嬉しいです。

サービスアカウントの概要

ロール付与

サービスアカウントとは、Compute Engineやプロジェクトなどのリソースが使用するアカウントです。

例えば、Compute EngineがCloud SQLのデータにアクセスする場合、Compute Engineにサービスアカウントを割り当てます。そうすることで、Cloud SQLにアクセスする際、認証を行ってセキュアにアクセスすることができます。

サービスアカウントを使用すると、認証を行った上で、他のリソースにアクセスすることができます。

サービスアカウントには、通常のユーザーアカウントと同じようにロールを割り当てます。割り当てられたリソースのアクセスしか行うことができなように制限をかけることができます。

サービスアカウントは、固有のメールアドレスで識別し、プロジェクトに作成します。組織やフォルダにサービスアカウントを作成することはできません。

以下サービスアカウントのまとめです。

  • リソース(プロジェクトやCompute Engineインスタンス等)に割り当てるアカウント
  • リソースにアクセスする際、認証が実施される
  • ロールを割り当てることができる
  • 固有のメールアドレス
  • サービスアカウントはプロジェクトに作成
  • プロジェクトに最大100個作成可能。Googleにリクエストすることで、数を増やせる

サービスアカウントの種類

サービスアカウントの種類

サービスアカウントには主に3つの種類があります。

  1. ユーザー管理のサービスアカウント
  2. デフォルトのサービスアカウント
  3. Google管理のサービスアカウント

1つずつ説明します。

1.ユーザー管理のサービスアカウント

ユーザー管理のサービスアカウントは、ユーザーが作成して管理を行うサービスアカウントになります。プロジェクトに作成し、初期設定では、最大100個まで作成することができます。Googleにリクエストすることで、数を増やすことができます。

サービスアカウントは、下記形式になります。
service-account-name@project-id.iam.gserviceaccount.com
service-account-nameは、ユーザー側で設定することができます。使用できる文字数は最大で30文字です。

サービスアカウント作成方法

実際の作成方法について説明します。

1.サービスアカウントを選択
サービスアカウントを選択

画面左上のメニューアイコンから、「IAMと管理」の中の「サービスアカウントを選択します。

2.サービスアカウントを作成
サービスアカウントを作成

画面上部の「サービスアカウントを作成」を選択します。

3.サービスアカウントの詳細
サービスアカウントの詳細

①サービスアカウント名
②サービスアカウント ID
③サービスアカウントの説明

上記を入力後、「作成して続行」を選択します。サービスアカウントIDは後で変更できないので、注意が必要です。

4.ロール付与
ロール付与

①ロール
②IAMの条件

上記を入力後、「続行」を選択します。ロールや条件は後からでも変更できます。

5.アクセス許可
アクセス許可

サービスアカウントユーザーロール:サービスアカウントのロールをユーザーアカウント等のプリンシパルに割り当てる設定です。
サービスアカウント管理者ロール:作成するサービスアカウントを管理できるプリンシパルを割り当てる設定です。

上記入力後、「完了」を選択します。

上記で使用できるプリンシパルは、下記4つです。

  • Google アカウントのメールアドレス
  • Googleグループ
  • サービスアカウント
  • Google Workspace ドメイン
対象プリンシパル
6.完了
完了

正常に完了すると一覧に表示されます。

以上で、サービスアカウントの作成方法は終わりになります。

2.デフォルトのサービスアカウント

デフォルトのサービスアカウントは、App EngineやCmpute Engine等のサービスを有効にすると自動で作成されるサービスアカウントになります。デフォルトのサービスアカウントには、編集者ロールが割り当てられており、Google Cloud内で使用する際、そのロールのアクセス権を使用してリソース等にアクセスします。下記は、Compute Engineのデフォルトサービスアカウントになります。

デフォルトのサービスアカウント

デフォルトサービスアカウントの管理は、ユーザー側にありますので、ロールを変更することができます。

3.Google管理のサービスアカウント

Google管理のサービスアカウントは、Googleが作成し管理しているサービスアカウントになります。例えば、Cloud Runが他のサービスを使用する際は、Google管理のサービスアカウントを使用してアクセスします。

Google管理のサービスアカウントは、プロジェクト内のサービスアカウントでは表示されません。Google管理のサービスアカウントは、プロジェクトの許可ポリシーや監査ログに表示されることがあります。

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

3種類の認証方法

サービスアカウントの認証には、主に3つの方法があります。

  1. アプリケーションのデフォルト認証(ADC)
  2. Workload Identity 連携を使用した認証
  3. サービスアカウントキーを使用した認証

1つずつ説明します。

1.アプリケーションのデフォルト認証(ADC)

デフォルト認証

アプリケーションのデフォルト認証は、Google Cloud内のアプリケーションが、他のリソースにアクセスする際に行う認証です。アプリケーションが動いているCompute Engineのインスタンス等リソースに対し、サービスアカウントを割り当て、そのサービスアカウントの認証情報を使用し、他のリソースにアクセスします。

ポイント!
別組織で作成したサービスアカウントから、自ドメインのサービスアカウントに割り当てられているリソースにアクセスする際も、デフォルトの認証が使用されます。下記がイメージ図です。

別組織からの認証

このように、Google Cloud Platform内の認証は、基本的にアプリケーションのデフォルト認証が使用されます。

2.Workload Identity 連携を使用した認証

Workload Identity 連携

Workload Identity 連携は、AWS等の外部のサービスやオンプレミスのサーバー等に、Google Cloudリソースのアクセス権を付与する仕組みです。

Workload Identityを使用した認証は、下記の流れで実施されます。今回は、AWSの仮想マシンであるEC2から、Google CloudのCloud SQLにアクセスすると想定して説明します。

  1. EC2がAWS内のIdentiti ProviderからAWSのサービスアカウントを使用し認証を行いアカウント資格情報を受取ります
  2. EC2はそのアカウント認証情報を使用して、Google Cloud内にあるSecurity Token Serviceで認証を行います。
  3. Security Token ServiceからWorkload Identityに認証を行います。
  4. 認可が実施されると、Security Token Serviceに戻り、アクセストークンがEC2に発行されます。アクセストークンとは、鍵のようなものです。
  5. EC2はそのアクセストークンを使用してGCPのサービスアカウントに成り代わります。
  6. そのGCPのサービスアカウントから、Cloud SQLにアクセスします。

上記のような流れになります。

理解しづらい流れなので、身近なもので考えてみました。外国人が日本に入国するのにVISAを発給するのと同じ様な流れです。実際のVISAの発給とは違うかもしれませんが、ご了承ください。あくまで、Workload Identityを理解してもらうための例えになります。

Workload Identityの例

このように、Workload Identityを使用すると、外部サービスからアクセスする際、Google Cloudのサービスアカウンを使用してアクセスすることができます。

3.サービスアカウントキーを使用した認証

サービスアカウントキーを使用した認証

サービスアカウントキーとは、サービスアカウントの認証情報を持った、JSON形式などのキーです。外部のサービスでGoogle Cloudのサービスアカウントを認証するために使用します。

サービスアカウントキーを使用することで、サービスアカウントに付与されているアクセス権を使用することができます。

基本的に、サービスアカウントキーを使用することは、推奨されておりません。理由としては、強力な認証情報を持ったキーなので、外部に流出してしまうと、構築したアプリケーションから情報を盗まれる可能性があります。基本的に、今まで説明した、アプリケーションのデフォルト認証(ADC)やWorkload Identityを使用することが推奨されています。

上記2つが使用できない場合に、サービスアカウントキーを使用しますが、権限は最小限に留めます。

まとめ

今回は、下記3点について説明を行いました。

  1. サービスアカウントの概要
  2. サービスアカウントの種類
  3. サービスアカウントの認証

サービスアカウントは、クラウド初心者の人にはなかなか理解しづらいものになっています。しかし、サービスアカウントを使用することで、よりセキュアにアプリケーション構築を行うことができます。また、認証方法についても、理解が難しい仕組みの一つですが、図を作成することで理解しやすくなります。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです!

それでは、次回のブログで!

タイトルとURLをコピーしました