Google Cloud（旧称GCP）は、多くの企業や開発者が利用しているクラウドサービスです。その中でも、「サービスアカウント」はGCP上のリソースに対するアクセスを管理するための重要な役割を持っています。
この記事では、初心者でもわかりやすいようGCPのサービスアカウントについて解説していきます。サービスアカウントの基本を理解し、GCPを扱うインフラエンジニアとしての一歩を踏み出しましょう。
サービスアカウントとは？
サービスアカウントは、GCP上でアプリケーションや仮想マシン（VM）が、GCPのリソースにアクセスする際に使用するアカウントのことです。
「Aさん」という個人のユーザーアカウントはそのAさんに紐付けられていますが、サービスアカウントはユーザーではなく、プログラムやサービスに対して認証・認可を行うためのアカウントです。
例えば、アプリケーションが GCPのストレージサービスである「Cloud Storage」にファイルを保存したり、「Compute Engine」から他のGCPサービスにアクセスしたりする場合にサービスアカウントを利用します。
サービスアカウントは次のようなメールアドレスによって識別されます。
service-account-name@project-id.iam.gserviceaccount.comCompute EngineやGoogle Cloudのアカウント作成については、以下の記事で解説しています。
Google Cloudの始め方 まずは仮想マシン（Compute Engine）を使ってみよう
また、サーバーレスサービスであるGoogle CloudRunに関しては以下の記事で解説していますので、ご参照ください。
簡単ステップで学ぶ！Google CloudRunの基礎とデプロイ方法
サービスアカウントが必要な理由
クラウド環境では、アプリケーションやサービスがデータベースやストレージなどのリソースにアクセスする必要があります。
この時に認証、認可の仕組みが必要になり、それを実現してくれるのがサービスアカウントです。
どのような時にサービスアカウントを使用するのか
具体的な例として、ユーザーがアップロードした画像をCloud Storageへ保存する場合や、ユーザー情報をデータベースに保存する時など、ユーザー以外のリソースがGCPのリソースへアクセスする際にサービスアカウントを使用します。
また、Compute Engine（仮想マシン）上で動作するプログラムが、Cloud StorageやCloud Pub/Subにアクセスする場合などにもサービスアカウントが使用されます。
このように、人間ではなくプログラムがGCPリソースにアクセスする際に、サービスアカウントを使って認証、認可が行われます。
サービスアカウントの種類
GCPのサービスアカウントには、デフォルトサービスアカウント、ユーザー管理サービスアカウント、そしてサービスエージェントの3種類があります。
デフォルトサービスアカウント
デフォルトサービスアカウントは、特定GCPサービスの初回利用時に、GCPプロジェクト内に自動的に作成されるサービスアカウントです。
GCPではCompute Engine（AWSでいうEC2）やApp Engineなどを利用する場合、初回利用時にプロジェクトごとのAPIを有効化する必要があります。デフォルトサービスアカウントは、この「初回利用時のAPI有効化」を行う際に自動的に作成されます。
このアカウントは、以下のようなアドレスで表現されます。
# App Engine、App Engineを使用するGoogle Cloudサービス
project-id@appspot.gserviceaccount.com
# Compute Engine、Compute Engineを使用するGoogle Cloud サービス
project-number-compute@developer.gserviceaccount.com自動で作成される点は便利ですが、権限管理はユーザー側で管理する必要がある点に注意が必要です。
ユーザー管理サービスアカウント
ユーザー管理サービスアカウントは、プロジェクト内で必要に応じて作成するサービスアカウントのことです。自動的に作成されるデフォルトサービスアカウントとは異なり、ユーザー自身が作成、カスタマイズできます。
このアカウントでは、命名、権限の変更、有効化や無効化、不要になった時の削除といった操作が可能です。
デフォルトでは、1つのプロジェクトに「最大100個」までという制限があるのも特徴の一つで、上限緩和を行えば制限の引き上げをすることもできます。
このサービスアカウントの用途としては、Cloud Storageバケットの「一部のフォルダだけにアクセスを許可する」など、限定的な場合に使用されます。
このアカウントは次のように表現されます。
service-account-name@project-id.iam.gserviceaccount.comサービスエージェント
サービスエージェントは、Googleが自動的に作成、管理するサービスアカウントになり、ユーザー自身が作成、管理する必要はありません。
他のサービスアカウントで必要だった権限管理もGoogle側で自動で行なってくれます。
AWSで例えると、LambdaからS3へアクセスする際には、S3へのアクセス権限をIAM Policyとして記述しIAM Roleにアタッチする必要がありました。
マネージドサービスアカウントでは、このような権限設定をGoogle側で行なってくれるイメージになります。
以下、簡単な表にそれぞれの特徴をまとめました。
| 種類 | デフォルトサービスアカウント | ユーザー管理サービスアカウント | サービスエージェント |
|---|---|---|---|
| 作成方法 | プロジェクト作成時に自動作成 | ユーザーが手動で作成 | Googleが自動作成（特定のサービス利用時） |
| 権限管理 | 自身で管理 | 自身で管理 | 管理不要 |
| 使い分け | プロジェクトの初期段階や、細かい権限設定が不要な場合 | 機密情報へのアクセス制限や、特定のサービスへのアクセスを制御したい場合 | Googleが提供するサービスとの連携をスムーズに行いたい場合 |
サービスアカウントの権限管理
サービスアカウントに付与する権限を適切に管理することは非常に重要で、最小権限の原則に従って必要最小限の権限のみを割り当てることが必要です。
具体的に説明すると、GCPの「ロール」と言う仕組みを使ってGoogle Cloudのリソースに対するアクセス権を制御します。
例えば、Cloud Storageに対して読み取りのみを許可する場合は、「ストレージオブジェクト閲覧者」ロールをサービスアカウントに付与します。
この場合、サービスアカウントはCloud Storageのオブジェクトの閲覧のみを実行することができ、オブジェクトの作成、削除など他の動作は行うことができません。
このように、サービスアカウントに対して何の動作を許可したいのか、目的に応じた権限の設定が必要です。
サービスアカウントのベストプラクティス
サービスアカウントのベストプラクティスは公式ドキュメントに複数の項目が記載されています。その中から基本的なところをご紹介します。
最小権限の原則を守る
サービスアカウントには、「必要最低限の権限」のみを付与しましょう。
必要以上な過剰な権限はセキュリティのリスクを高めてしまうことはもちろん、誤操作による意図していないデータの削除、変更を行なってしまう可能性があります。
運用中のサーバーを間違って削除してしまった、バケット内のデータを削除してしまったなど、望まない結果を引き起こさないためにも、権限の付与は必要最低限を意識することが重要です。
サービスアカウントキーの管理
通常運用するユーザーとは異なり、サービスアカウントはRSAキーペアを使用した認証を行います。この時に利用するのが、「サービスアカウントキー」です。
ユーザーが認証する場合にはパスワードを使用するため、万が一パスワードが漏洩しても、2段階認証などを設定することで悪意ある攻撃者にログインされる可能性を減らすことができます。
対してサービスアカウントキーでは2段階認証などを設定することはできません。
そのため、万が一漏洩した場合には不正にログインされ、認証情報の漏洩、意図していないリソースの作成などを行われてしまう危険性があります。
このようなことから、できる限りサービスアカウントキーを使用しないことが推奨されています。
すべてのシナリオで、Google Cloud サービスにアクセスするためのサービス アカウントが必要になるわけではありません。多くのシナリオでは、サービス アカウント キーを使用するよりも安全な方法で認証を行うことができます。サービス アカウント キーは、可能な限り使用しないことをおすすめします。
不要なサービスアカウントの無効化
不要になったサービスアカウントは無効化しましょう。GCPのドキュメントでは、削除する前に無効化が推奨されています。
理由としては、サービスアカウント削除後に万が一同じ名前での作成が必要になった場合に、再度権限の設定が必要になるためです。
サービスアカウントを削除すると、再度同じ名前のサービスアカウントを作成したとしても以前の設定は引き継がれず、再び権限の設定が必要になります。
無効化しておけば、再度サービスアカウントの利用が必要になった際も有効化するだけで済み、サービスアカウントを復旧するための負担を減らすことが可能です。
未使用のサービス アカウントを削除する前にサービスを無効にする
まとめ
サービスアカウントは、GCP 上でアプリケーションやサービスが安全にリソースにアクセスするために欠かせない重要な仕組みです。
この記事では、サービスアカウントの基本的な概念、種類、権限管理の方法について学びました。サービスアカウントを適切に利用することで、GCP のリソース管理をより安全かつ効率的に行うことができます。
次のステップとして、実際にサービスアカウントを使ったプロジェクトを作成し、ハンズオンで理解を深めていきましょう。
参考記事
サービス アカウント キーを管理するためのベスト プラクティス
【番外編】USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話
プログラミング塾に半年通えば、一人前になれると思っているあなた。それ、勘違いですよ。「なぜ間違いなの？」「正しい勉強法とは何なの？」ITを学び始める全ての人に知って欲しい。そう思って書きました。是非読んでみてください。
「フリーランスエンジニア」
近年やっと世間に浸透した言葉だ。ひと昔まえ、終身雇用は当たり前で、大企業に就職することは一種のステータスだった。しかし、そんな時代も終わり「優秀な人材は転職する」ことが当たり前の時代となる。フリーランスエンジニアに高価値が付く現在、ネットを見ると「未経験でも年収400万以上」などと書いてある。これに釣られて、多くの人がフリーランスになろうとITの世界に入ってきている。私もその中の1人だ。数年前、USBも知らない状態からITの世界に没入し、そこから約2年間、毎日勉学を行なった。他人の何十倍も努力した。そして、企業研修やIT塾で数多くの受講生の指導経験も得た。そこで私は、伸びるエンジニアとそうでないエンジニアをたくさん見てきた。そして、稼げるエンジニア、稼げないエンジニアを見てきた。
「成功する人とそうでない人の違いは何か？」
私が出した答えは、「量産型エンジニアか否か」である。今のエンジニア市場には、量産型エンジニアが溢れている！！ここでの量産型エンジニアの定義は以下の通りである。
比較的簡単に学習可能なWebフレームワーク（WordPress, Rails）やPython等の知識はあるが、ITの基本概念を理解していないため、単調な作業しかこなすことができないエンジニアのこと。
多くの人がフリーランスエンジニアを目指す時代に中途半端な知識や技術力でこの世界に飛び込むと返って過酷な労働条件で働くことになる。そこで、エンジニアを目指すあなたがどう学習していくべきかを私の経験を交えて書こうと思った。続きはこちらから、、、、
エンベーダー編集部
エンベーダーは、ITスクールRareTECHのインフラ学習教材として誕生しました。 「遊びながらインフラエンジニアへ」をコンセプトに、インフラへの学習ハードルを下げるツールとして運営されています。
関連記事
2020.02.25
完全未経験からエンジニアを目指す爆速勉強法
USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話
- キャリア・学習法
- エンジニア
2024.06.23
簡単ステップで学ぶ！Google CloudRunの基礎とデプロイ方法
この記事では、CloudRunの基本的な概念と機能を理解し、簡単な「Hello World」アプリをデプロイする方法を紹介します。対象読者は、CloudRunやサーバーレスコンピューティングに初めて触れる方です。
- GCP
2024.06.17
Google Cloudの始め方 まずは仮想マシン（Compute Engine）を使ってみよう
今回はGoogle Cloudを使って、初心者でも簡単にクラウド環境に触れられるよう、Compute Engineを利用して「Hello World」を表示する方法を紹介します。
- GCP
2024.06.25
初心者向け！CloudFunctionで簡単アプリをデプロイしよう
CloudFunctionは、一言で言えば「サーバーレスコンピューティングサービス」です。AWSのLambdaに相当するサービスで、インフラの管理を気にせずにコードを実行することができます。
- GCP