Google Cloud でサービス アカウントを使用して認証する最適な方法の選択
Google Cloud Japan Team
※この投稿は米国時間 2021 年 4 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。
セキュリティの大前提となるのが、リソースやサービスへのアクセスが許可されているかどうかを判断する前に行うユーザー ID の確認です。このプロセスを「認証」と呼びます。しかし、認証が必要なのは人間のユーザーだけではありません。あるアプリケーションが別のアプリケーションと通信する必要がある場合、アプリケーションの ID も認証する必要があります。クラウドではほとんどの場合、サービス アカウントを通じて ID の認証が行われます。
サービス アカウントは人間以外のユーザーを表し、Google Cloud では Cloud Identity and Access Management（IAM）によって管理されます。サービス アカウントを使用するのは、アプリケーションが独自の ID でリソースにアクセスしたり、アクションを実行したりする必要がある場合です。たとえば、VM インスタンスで実行されるアプリケーションが、データを格納するよう構成された Cloud Storage バケットにアクセスしなくてはならない場合などです。
サービス アカウントは通常のユーザーとは異なり、パスワードやシングル サインオン（SSO）を使用した認証はできません。しかし、代わりに使用できる認証方法にはさまざまなものがあるため、ニーズに応じて適切な方法を使用することが重要といえます。サービス アカウントの認証に最適な方法を選択できるよう、以下のガイドラインをお役立てください。
必要な場合にのみサービス アカウントを使用する
サービス アカウントは必要なものであると結論付ける前に、アプリケーションがそれ自体のために動作しているのか、それともエンドユーザーのために動作しているのかを自問してみましょう。
継続的に指標を収集して Cloud Storage バケットに保存するアプリケーションは、アプリケーション自体のために動作しています。エンドユーザーは関与せず、そのまま動作するバックグラウンド ジョブです。
ユーザーが自身のドキュメントにアクセスできるようにするアプリケーションは、エンドユーザーのために動作しています。アプリケーションのためではありません。
アプリケーションがエンドユーザーのために動作する場合、サービス アカウントの使用が適さないことがあります。代わりに、OAuth 同意フローを使用してエンドユーザーの同意を求め、アプリケーションをそのエンドユーザーの ID で動作させることをおすすめします。OAuth を使用すると、次のことができます。
エンドユーザーは、アプリケーションにアクセス権を付与しようとしているリソースを確認し、自身の同意または拒否を明示的に表明できます。
ユーザーは随時、[アカウント情報] ページで同意を取り消すことができます。
サービス アカウントに、ユーザーデータへの無制限のアクセス権が付与されることは一切ありません。
日常業務で、gcloud、gsutil、terraform などのツールを使用する場合があります。これらのツールを実行するのはユーザーであるため、ツールもユーザーの認証情報を使うべきです。これらのツールの実行にサービス アカウント キーを使用する代わりに、gcloud auth login（gcloud と gsutil の場合）、または gcloud auth application-default login（terraform とその他のサードパーティ ツールの場合）を実行して、ツールがユーザーの認証情報を使用することを許可します。
サービス アカウントやサービス アカウント キーをどうしても必要な場合にのみ使用するよう制限することで、ユーザーデータの安全性の確保や不正行為の可能性の低減、さらには監査ログを使用して特定の操作を行ったユーザーを容易に特定できるようになります。
可能な場合には接続されたサービス アカウントを使用する
Google Cloud にデプロイされたアプリケーションでサービス アカウントを使用する必要がある場合は、基盤となるコンピューティング リソースにサービス アカウントを接続します。サービス アカウントを接続すると、アプリケーションはサービス アカウントのトークンを取得し、それらのトークンを使用して Google Cloud APIs とリソースにアクセスできます。
アプリケーションでアクセス トークンを取得するには、可能であれば Google Cloud クライアント ライブラリを使用します。クライアント ライブラリは、サービス アカウントが接続されているコンピューティング リソースでアプリケーションが実行されているかどうかを自動的に検出します。
クライアント ライブラリの使用が現実的でない場合は、メタデータ サーバーからトークンをプログラムで取得するようにアプリケーションを調整します。メタデータ サーバーへのアクセスをサポートするコンピューティング リソースには次のようなものがあります。
サービス アカウントを接続できるコンピューティング リソースの一覧については、サービス アカウントの権限借用の管理をご覧ください。
Workload Identity を使用してサービス アカウントを Kubernetes Pod に接続する
Google Kubernetes Engine（GKE）を使用する場合は、1 つの GKE クラスタで異なるアプリケーションを組み合わせて実行できます。アクセスする必要があるリソースと API は、アプリケーションごとに異なる可能性があります。
サービス アカウントを GKE クラスタまたはそのいずれかのノードプールに接続する場合、デフォルトでは、クラスタまたはノードプールで実行されているすべての Pod がサービス アカウントの権限を借用できます。異なるアプリケーション間で単一のサービス アカウントを共有すると、サービス アカウントに適切な一連の権限を割り当てるのが難しくなります。
すべてのアプリケーションが必要とするリソースへのアクセス権のみを付与すると、一部のアプリケーションが特定のリソースにアクセスできず、動作しないことがあります。
特定のアプリケーションが必要とするすべてのリソースへのアクセス権を付与すると、過剰なアクセス権を付与してしまう可能性があります。
GKE 環境内のリソースへのアクセスを管理する場合は Workload Identity を使用するのが適切です。これにより、サービス アカウントを個々の Pod に関連付けることができます。
GKE クラスタやノードプールにサービス アカウントを接続しないでください。
Cloud IAM では、Google API またはリソースにアクセスする必要がある Kubernetes Pod ごとに専用のサービス アカウントを作成します。
GKE では、Google API またはリソースにアクセスする必要がある Kubernetes Pod ごとに Kubernetes サービス アカウントを作成し、Pod に接続します。
Workload Identity を使用して、サービス アカウントと対応する Kubernetes サービス アカウント間のマッピングを作成します。
Workload Identity 連携を使用して、Google Cloud で実行されていないアプリケーションのサービス アカウントを使用する
オンプレミスまたは別のクラウド プロバイダでアプリケーションを実行する場合は、基盤となるコンピューティング リソースにサービス アカウントを接続することはできません。ただし、アプリケーションは次のような環境固有の認証情報にアクセスできる場合があります。
アプリケーションがこれらの認証情報のいずれかへのアクセス権を付与されており、Google Cloud APIs またはリソースへのアクセス権を必要とする場合は、Workload Identity 連携を使用します。
Workload Identity 連携を使用すると、Google Cloud プロジェクトと外部 ID プロバイダ間の一方向の信頼関係を作成できます。信頼を確立すると、アプリケーションは、信頼できる ID プロバイダによって発行された認証情報を使用して、次の 3 つのステップで構成されるプロセスに沿ってサービス アカウントの権限を借用できます。
信頼できる ID プロバイダから認証情報（OpenID Connect ID トークンなど）を取得します。
STS API を使用して、有効期間の短い Google STS トークンと認証情報を交換します。
STS トークンを使用して、IAM Credentials API に対する認証を行い、サービス アカウントには有効期間の短い Google アクセス トークンを取得します。
Workload Identity 連携を使用することで、外部環境に用意されたネイティブの認証メカニズムをアプリケーションが使用することを許可できます。これにより、サービス アカウント キーを保存して管理する必要がなくなります。
他に有効な方法がない場合にのみサービス アカウント キーを使用する
サービス アカウントの接続が不可能で、Workload Identity と Workload Identity 連携のいずれも使用できない状況が発生することもあります。たとえば、オンプレミス アプリケーションの一つが Google Cloud リソースへのアクセスを必要としていても、オンプレミスの ID プロバイダが OpenID Connect（または、まもなくサポートが追加される予定の SAML 2.0）と互換性がなく、Workload Identity 連携に使用できない場合があります。
他の認証方法を使用できない場合（かつ、そのような状況下でのみ）、アプリケーションのサービス アカウント キーを作成します。サービス アカウント キーを使用すると、ユーザーがユーザー名とパスワードを使用して認証する方法と同様に、サービス アカウントでアプリケーションの認証を行うことができます。サービス アカウント キーは秘密にして不正なアクセスから保護する必要がありますので、Key Vault などの安全な場所に保存し、頻繁にローテーションするようにします。
組織管理者は、組織内のどのユーザーがサービス アカウント キーを使用できるかを管理したい場合があります。これを行うには、サービス アカウント キーの組織のポリシーを使用します。
認証方法の決定について
サービス アカウントを使用した認証は強力ですが、決して唯一の方法というわけではありません。また、他の認証方法が適していない場合にのみ使用する必要があります。アプリケーションに最適な認証方法の判断が難しい場合は、次のフローチャートをご参照ください。
サービス アカウントの使用と保護に関して詳しくは、プロダクト ドキュメントのサービス アカウントの使用と管理のベスト プラクティスやサービス アカウントを保護するためのベスト プラクティスをご参照ください。
-ソリューション アーキテクト Johannes Passing
-Google Cloud プロダクト マネージャー Vignesh Rajamani
