アクセス制御は、Google Cloud プロジェクトのサービスとリソースにアクセスする権限を持つユーザーを決定します。App Engine には、アクセス制御の設定に関していくつかの個別のユースケースがあります。
Google Cloud プロジェクトへのアクセス権をチームメンバーに付与し、サービスをセットアップしてアプリをデプロイできるようにする。
Cloud Storage などの Google Cloud サービスへのアクセス権をアプリに付与する。すべての Cloud サービスでは、App Engine アプリからの呼び出しを含むすべての API 呼び出しに対して認証と認可が必要です。
Google Cloud プロジェクトのリソースへのアクセス権をユーザーに付与する。このユースケースは一般的ではないですが、アプリがユーザーの代わりに Cloud リソースへのアクセスをリクエストする必要がある場合もあります。たとえば、アプリはユーザーに属するデータにアクセスする必要がある場合があります。
このページには、各ユースケースでのアクセス制御の設定の概要が記載されています。
Google Cloud Platform がアクセス制御を処理する方法に関する背景情報については、Identity and Access Management(IAM)の概要をご覧ください。
チームメンバーにアクセスを付与する
デベロッパーが Google Cloud プロジェクトにアクセスできるようにするには、次のいずれかまたは両方を作成します。
Google アカウントに関連付けられており、プロジェクトの特定の個人を表すユーザー アカウント。
ユーザー アカウントは、次のツールの認証に使用できます。
- Google Cloud コンソール
- Google Cloud CLI
- gcloud CLI を使用して App Engine アプリをテストしてデプロイする IDE とビルドツール
個人ではなくアプリケーションまたはプロセスを表すサービス アカウント。特に複数のデベロッパーがこれらのプロセスを実行できる場合は、自動化されたビルド、テスト、デプロイ プロセスでサービス アカウントを使用します。
サービス アカウントは、次のツールの認証に使用できます。
- gcloud CLI
- gcloud CLI のツールを使用して App Engine アプリをテストしデプロイする IDE とビルドツール
ユーザー アカウントを作成する
Google Cloud コンソールで [IAM] ページを開きます。
[プロジェクトを選択] をクリックし、プロジェクトを選択して [開く] をクリックします。
[追加] をクリックします。
メールアドレスを入力します。
App Engine 機能へのアクセス権を付与する役割を選択します。
ユーザーが他のクラウド サービスにもアクセスする必要がある場合は、他のクラウド サービスへのアクセス権を付与する役割を選択します。
[保存] をクリックします。
これでユーザーが、Google Cloud コンソールにログインし、gcloud CLI を承認できるようになりました。
gcloud、REST API、またはクライアント ライブラリからユーザー アカウントを作成することもできます。
サービス アカウントを作成する
Google Cloud コンソールで [サービス アカウント] ページを開きます。
プロジェクトを選択し、[開く] をクリックします。
[サービス アカウントを作成] をクリックします。
サービス アカウント名を入力します。表示用のわかりやすい名前にしてください。
[作成] をクリックします。
App Engine 機能へのアクセス権を付与する役割を選択します。
サービス アカウントが他の Cloud サービスにもアクセスする必要がある場合は、他の Cloud サービスへのアクセス権を付与する役割を選択します。
[続行] をクリックします。
必要に応じて、サービス アカウントを管理できるユーザー アカウントを指定します。サービス アカウントを使用して、サービス アカウントからアクセス可能なすべてのリソースに間接的にアクセスできるユーザー アカウントを指定することもできます。
[保存] をクリックします。
既存のサービス アカウントのリストが表示されます。
Google Cloud の外部でサービス アカウントを使用する必要がある場合は、サービス アカウント キーの作成の手順を行います。
次のステップ
- 自動化されたビルドとデプロイ プロセスでサービス アカウントを使用している場合、gcloud CLI をサービス アカウントで承認します。
- IDE でサービス アカウントを使用している場合は、IDE の指示に従ってください。
- 他の Google Cloud サービスにアクセスするとき、またはタスクを実行するときに、App Engine アプリのバージョンに一意の ID を使用する必要がある場合は、App Engine でユーザー管理のサービス アカウントを指定できます。
アプリにクラウド サービスへのアクセスを許可
App Engine アプリから Cloud Storage などの他の Cloud サービスへの呼び出しを含め、Cloud サービスへのすべての呼び出しを認証および承認する必要があります。
デフォルトでは、App Engine アプリから同じプロジェクト内のサービスへの呼び出しが許可されます。デフォルト フローの仕組みは次のとおりです。
Cloud サービスへの呼び出しを開始するには、アプリでクライアント オブジェクトを作成します。クライアント オブジェクトには、アプリがサービスと対話するために必要な認証情報やデータが含まれます。クライアントのコンストラクタで認証情報を指定しない場合、クライアントはアプリの環境で認証情報を探します。
Cloud Storage のクライアントの作成例を次に示します。
Go
Java
Node.js
PHP
Python
Ruby
- デフォルトでは、アプリの環境にはデフォルト App Engine サービス アカウントの認証情報が含まれています。
このサービス アカウントは、App Engine アプリを作成するときに Google が作成し、Google Cloud プロジェクト内のすべての Cloud サービスを管理および使用する権限をすべて付与します。
このデフォルトのフローは、次のいずれかの方法でオーバーライドできます。
GOOGLE_APPLICATION_CREDENTIALS
環境変数を設定します。この変数が設定されている場合、Cloud サービスはデフォルトのサービス アカウントの代わりに変数で指定された認証情報を使用します。Cloud サービスの
Client
オブジェクトをインスタンスにするときに認証情報を指定します。たとえば、アプリが別のプロジェクトで Cloud サービスを呼び出す場合は、手動で認証情報を渡す必要があります。
コード内に GOOGLE_APPLICATION_CREDENTIALS
環境変数を設定するか認証情報を渡す場合は、次のいずれかの方法で認証情報を保存することをおすすめします。
- Datastore モードの Firestore(Datastore)などの安全な場所に認証情報を保存して実行時に取得する。
- コード内に認証情報を保存して Cloud KMS などのキーストアで暗号化する。
各アプローチの利点については、シークレット管理ソリューションの選択をご覧ください。
ユーザーに Cloud リソースへのアクセス権を付与する
アプリで別の Google サービスからユーザーデータを読み取るには、OAuth 2.0 for Web Server Applications を設定する必要があります。たとえば、Google ドライブからユーザーのデータを取得し、アプリで使用する場合、OAuth 2.0 for Web Server Applications を使用して特定のデータを共有しながら、ユーザー名やパスワードなどの他のデータは非公開のままにします。
Google Workspace ドメイン全体の権限の委任
Google Workspace(旧 G Suite)ドメインがある場合、ドメイン管理者は、Google Workspace ドメインのユーザーに代わってユーザーデータにアクセスするアプリケーションを認可できます。たとえば、Google Calendar API を使用して Google Workspace ドメイン内のすべてのユーザーのカレンダーに予定を追加するアプリケーションの場合、ユーザーの代わりにサービス アカウントを使用して Google Calendar API にアクセスします。
ドメイン内でユーザーに代わってデータにアクセスすることをサービス アカウントに承認することは、サービス アカウントへの「ドメイン全体の権限の委任」と呼ばれることもあります。これも OAuth 2.0 を使用し、Google Workspace ドメインの管理者がサービス アカウントにドメイン全体の権限を認可することを必要とします。
サービス アカウントを指定する
App Engine では、2 種類のサービス アカウントを使用できます。
App Engine のデフォルトのサービス アカウントは、ユーザー管理のサービス アカウントが指定されていない場合、App Engine アプリのすべてのバージョンのデフォルト ID になります。
組織のポリシーの構成によっては、デフォルトのサービス アカウントにプロジェクトに対する編集者のロールが自動的に付与される場合があります。
iam.automaticIamGrantsForDefaultServiceAccounts
組織ポリシー制約を適用して、自動的なロール付与を無効にすることを強くおすすめします。2024 年 5 月 3 日以降に組織を作成した場合、この制約はデフォルトで適用されます。自動ロール付与を無効にする場合、デフォルトのサービス アカウントに付与するロールを決定し、これらのロールを付与する必要があります。
デフォルトのサービス アカウントにすでに編集者ロールが設定されている場合は、編集者ロールを権限の低いロールに置き換えることをおすすめします。サービス アカウントのロールを安全に変更するには、Policy Simulator を使用して変更の影響を確認してから、適切なロールを付与または取り消す操作を行います。
ユーザー管理のサービス アカウントは、Identity and Access Management(IAM)で作成するサービス アカウントです。1 つのバージョンにはユーザー管理のサービス アカウントを 1 つ指定できます。これは、他の App Engine サービスにアクセスする際や、そのバージョンのタスクを実行する際に使用されます。