認証の基本

Google Cloud APIs とサービスを操作するには、 自分が誰であるかを証明する必要があります。この本人確認のプロセスを「認証」と呼びます。

を認証するには、ID の証拠として認証情報を提供する必要があります。 Google Cloudたとえば、サービスを使用するには、パスワードやワンタイム コードなどの認証情報を使用して認証します。

Google Cloud では、認証されたユーザーを「プリンシパル」と呼びます。 プロジェクトやストレージバケットなどのリソースにアクセスしようとすると、プリンシパルがリクエストされたリソースに対して持つアクセスレベルが確認されます。 Google Cloud Google Cloudこの プロセスは「認可」と呼ばれ、Identity and Access Management（IAM）というシステムによって処理されます。

これらの同じコンセプトは、ユーザーに代わって自動タスクを実行するコード（「ワークロード」）にも適用されます。 ワークロードは、ID を証明してプリンシパルとして認証するための認証情報を提供する必要があります。これにより、 Google Cloud は、 リクエストされたリソースに対するワークロードのアクセスレベルを判断できます。

プリンシパルのタイプ

認証できるプリンシパルにはさまざまなタイプがあります。タスクのステージや開発環境によって、異なるプリンシパル タイプを使用することもできます。

主なプリンシパル タイプと、認証に必要な認証情報は次のとおりです。

  • ユーザー アカウント: これは、 Google アカウントであり、偶発的な管理タスク、 サービスの非プログラムによる構成 Google Cloud 、テスト、 実験、オブザーバビリティなど、人間がインタラクティブな作業を行うためのものです。

    パスワードやワンタイム コードなどのユーザー認証情報を使用して、ユーザー アカウントとして認証します。

  • サービス アカウント: これは、 Google Cloud ワークロードがサービスやリソースにアクセスするために使用できる内部アカウントです。通常、サービス アカウントとして直接認証することはありません。代わりに、サービス アカウントを Compute Engine VM などのリソースにアタッチするか、 サービス アカウントの権限借用を使用します。

    ほとんどのシナリオでは、 有効期間の短いサービス アカウント認証情報 を使用してサービス アカウントを認証することをおすすめします。

  • フェデレーション ID: これは、外部 ID プロバイダのユーザー アカウントまたはサービス アカウントを参照する ID です。 には、次の 2 種類のフェデレーション ID がサポートされています。名前は似ています。 Google Cloud

    • Workforce Identity 連携: 外部 ID プロバイダで管理されている ID を使用して、人間のユーザーが にログインできるようにします。 Google Cloud 組織ですでにシングル サインオン（SSO）が設定されている場合は、このタイプの ID を使用して を認証できます 。 Google Cloud

      Workforce Identity 連携を使用するには、ID プロバイダが OpenID Connect（OIDC）または SAML 2.0 をサポートしている必要があります。

    • Workload Identity 連携: の外部で実行されているワークロードが Google Cloud リソースを操作できるようにします。 Google Cloud

      Workload Identity 連携は、 X.509 クライアント証明書を使用して認証するワークロード、 アマゾン ウェブ サービス（AWS）または Azure で実行されるワークロード、 オンプレミスの Active Directory、 GitHub や GitLab などのデプロイ サービス、 OpenID Connect（OIDC）または Security Assertion Markup Language（SAML）V2.0 をサポートする任意の ID プロバイダで使用できます。

でサポートされているプリンシパル タイプの詳細については、 Google Cloud プリンシパルのタイプをご覧ください。

認証用に Google Cloud 組織を構成する

組織の認証を設定する場合は、既存のシステムとワークフローを に統合する必要がある場合があります。 Google Cloud Google Cloud

  • 使用する既存の ID プロバイダがある場合は、 設定 Workforce Identity 連携する必要があります。

  • リソースにアクセスする必要があるワークロードが Google Cloud の外部で実行されている場合は、 Google Cloud リソースにアクセスする必要があるワークロードが Workload Identity 連携を設定する必要があります。

環境を保護するために、次の操作も行うことをおすすめします。 Google Cloud

  • ユーザーに対して 多要素認証が有効になっている ことを確認します。

  • 再認証の設定を変更する必要があるかどうかを確認します 。

  • API キーを管理するためのポリシーを作成します 。

  • サービス アカウント キーを管理するためのポリシーを作成します。

人間とワークロードを認証する

を認証する方法は、使用している API とサービス、およびそれらの API とサービスを操作する方法によって異なります。 Google Cloud

人間を認証する

偶発的な管理タスク、リソースの設定、構成の変更、実験、ログの閲覧など、手動のインタラクティブな作業を行う場合は、ユーザー アカウントの認証情報を使用して認証します。

コンソール

コンソールでインタラクティブな作業を行う場合は、ユーザー認証情報を使用してウェブ インターフェースにログインして認証します。 Google Cloud

コンソールに移動 Google Cloud

コンソール セッションと同じ認証情報が Cloud Shellで使用されます。Cloud Shell では、 gcloud CLI にアクセスできます。 Google Cloud

gcloud

ローカル デバイスに gcloud CLI をインストールしたら、ターミナルで次のコマンドを実行して、ユーザー認証情報を使用して を認証できます。 Google Cloud 

gcloud auth login

認証後、以降の gcloud コマンドでは、ログインしたプリンシパルを使用してリクエストを行います。

Workforce Identity 連携認証情報、 Workload Identity 連携認証情報、サービス アカウント キーを使用して認証する方法については、 gcloud CLI を使用して認証するをご覧ください。

ワークロードを認証する

ローカル デバイス、 Google Cloudオンプレミス、別のクラウドのいずれでコードを開発して実行する場合でも、ワークロードを認証する最も柔軟で移植性の高い 方法は、アプリケーションのデフォルト認証情報（ADC）と呼ばれるメカニズムを使用して認証情報を提供することです。

ADC を実装するライブラリ（ Google Cloud クライアント ライブラリなど）は、 実行されている環境内の既知の場所で認証情報を確認します。つまり、コードの実行場所を変更しても、コード自体を変更する必要はありません。その環境で使用される認証情報のみを変更します。

たとえば、ローカルで開発する場合は、ADC が認証にユーザー認証情報を使用するように環境を設定できます。コードが本番環境に対応したら、変更せずに Compute Engine VM インスタンスにデプロイし、代わりに有効期間の短いサービス アカウント認証情報を使用して認証するように環境を設定できます。

次のシナリオでは、ADC を使用して認証することはできません。

  • gcloud CLI を認証する場合。

  • API キーを使用する場合。API キーは特定の API でのみ使用できます。

特定の環境に ADC を設定する方法については、 アプリケーションのデフォルト認証情報を設定するをご覧ください。

次のステップ