特定の Google Cloud リソースを作成した場合に、サービス アカウントを関連付けることができます。関連付けられたサービス アカウントは、リソースで実行されているジョブの ID として機能するため、Google Cloud APIs に対するジョブの認証を行うことができます。
ほとんどの Google Cloud サービスでは、サービス アカウントをリソースに関連付けるには、サービス アカウントになり代わる権限がユーザーに必要です。つまり、ユーザーにはサービス アカウントに対する iam.serviceAccounts.actAs
権限が必要です。
ただし、これまで特定のサービスでは、ユーザーがサービス アカウントになり代わる権限を付与されていない場合でも、ユーザーがサービス アカウントをリソースに関連付けることを許可していました。この構成によって、これらのサービスのユーザーが、昇格した不明瞭な権限を取得できるようになっていた可能性があります。
次の表に、この構成を持っていたサービスと、各サービスの従来の動作を示します。
サービス | 従来の動作 |
---|---|
App Engine | ユーザーは、App Engine のデフォルト サービス アカウントの権限借用を許可されていない場合でも、App Engine のデフォルト サービス アカウントの ID を使用する App Engine アプリケーションをデプロイできました。 |
Cloud Composer | プロジェクトのサービス アカウントになり代わる権限が一切付与されていない場合でも、ユーザーはプロジェクト内の任意のサービス アカウントを Cloud Composer 環境に関連付けることができました。 |
|
ユーザーは、デフォルト サービス アカウントの権限借用を許可されていなくても、Compute Engine のデフォルトのサービス アカウントをリソースに接続できました。 |
これらのサービスでは、リソースにサービス アカウントを関連付ける際に、サービス アカウントになり代わる権限がユーザーに付与されているかどうかの確認を必須としました。ただし、次に示す種類の組織では現時点でも従来の動作が残っています。
- App Engine アプリケーションをデプロイする権限を持ち、App Engine のデフォルト サービス アカウントの権限借用が許可されていないユーザーが存在する組織。
- Cloud Composer 環境をデプロイする権限が付与されているものの、任意のサービス アカウントになり代わる権限は付与されていないユーザーが属する組織。
- Cloud Data Fusion、Dataflow、Dataproc のいずれかのリソースをデプロイする権限が付与されているものの、Compute Engine のデフォルト サービス アカウントになり代わる権限は付与されていないユーザーが属する組織。
お客様の組織に引き続き従来の動作による影響が生じている場合は、手動で無効にする方法についての通知が届きます。詳細な手順については、以降のセクションもご覧ください。
App Engine の保護
App Engine の以前の動作を手動で無効にするには、App Engine サービス アカウントの権限借用が許可されているユーザーが存在することを確認してください。次に、組織のポリシーの制約を有効にして、App Engine のデフォルト サービス アカウントの ID を使用するアプリケーションをデプロイするときに、サービス アカウントの権限チェックを適用します。
省略可: ロールの推奨事項を使用して、App Engine のデフォルト サービス アカウントの権限の範囲を安全に限定します。
App Engine のデフォルト サービス アカウントには、高度な権限を持つ編集者ロール(
roles/editor
)が自動的に付与されます。ただし、本番環境では、このような高度な権限を持つロールの使用はおすすめしません。アプリケーションをデプロイするすべてのユーザーが、App Engine のデフォルト サービス アカウントの権限借用を許可されている確認します。
この機能を提供するには、サービス アカウント ユーザーロール(
roles/iam.serviceAccountUser
)など、iam.serviceAccounts.actAs
権限を含むロールをユーザーに付与します。このロールは、プロジェクトまたは App Engine のデフォルト サービス アカウントに付与できます。手順については、サービス アカウントの権限借用の管理をご覧ください。組織のポリシーの制約
constraints/appengine.enforceServiceAccountActAsCheck
を有効にして、アプリケーションをデプロイするときにサービス アカウントの権限チェックを適用します。省略可: boolean organization policy enforcer を使用して、すべてのプロジェクトに組織のポリシーの制約が適用されていることを確認します。
Cloud Composer の保護
Cloud Composer の従来の動作を手動で無効にするには、新しい環境に関連付けるサービス アカウントの権限借用がユーザーに許可されていることを確認します。次に、組織のポリシーの制約を有効にして、サービス アカウントを環境に接続するときに、サービス アカウントの権限チェックを適用します。
Cloud Composer 環境にバインドされているすべてのサービス アカウントを特定します。
Google Cloud コンソールで、Composer の [環境] ページに移動します。
環境の名前をクリックします。
[環境の構成] タブで、[サービス アカウント] フィールドを見つけて、サービス アカウントの名前を記録します。
プロジェクト内のすべての Cloud Composer 環境について、上記の手順を繰り返します。
これらのサービス アカウントが最小権限の原則に従っていることを確認します。
Google Cloud コンソールで [IAM] ページに移動し、サービス アカウントを見つけてロールを確認します。
必要に応じて、サービス アカウントに権限をより限定したロールを付与します。IAM の事前定義されたロールのリストからロールを選択するか、ロールの推奨事項によって提案されたロールを使用します。カスタムロールを作成することもできます。
Cloud Composer 環境をデプロイまたは管理するすべてのユーザーに、環境で使用されるサービス アカウントになり代わる権限が付与されていることを確認してください。
この権限を付与するには、サービス アカウント ユーザーのロール(
roles/iam.serviceAccountUser
)など、iam.serviceAccounts.actAs
権限を含むロールをユーザーに付与します。このロールは、プロジェクトまたは個別のサービス アカウントに付与できます。手順については、サービス アカウントの権限借用の管理をご覧ください。組織ポリシーの制約
constraints/composer.enforceServiceAccountActAsCheck
を有効にして、環境をサービス アカウントに接続するときにサービス アカウントの権限チェックを適用します。省略可: boolean organization policy enforcer を使用して、すべてのプロジェクトに組織のポリシーの制約が適用されていることを確認します。
Dataproc、Dataflow、Cloud Data Fusion の保護
Dataproc、Dataflow、Cloud Data Fusion の従来の動作を手動で無効にするには、新しいリソースに関連付けるサービス アカウントの権限借用がユーザーに許可されていることを確認します。次に、組織のポリシーの制約を有効にして、サービス アカウントをリソースに接続するときに、サービス アカウントの権限チェックを適用します。
新しいリソースに関連付けるサービス アカウントの種類に応じた手順に沿って進めてください。
新しいリソースに対する Compute Engine のデフォルト サービス アカウントの関連付けを停止する手順は、次のとおりです。
新しいサービス アカウントを作成し、リソースに対してジョブを実行するために必要なロールをサービス アカウントに付与します。最小権限の原則に従うようにしてください。
Dataproc、Dataflow、Cloud Data Fusion のリソースに対してジョブを実行するためにサービス アカウントに必要なロールについては、以下をご覧ください。
- Dataproc サービス アカウントの要件
- Dataflow サービス アカウントの要件
- Cloud Data Fusion サービス アカウントには、Dataproc サービス アカウントと同じ要件が存在します。
これらのリソースをデプロイするすべてのユーザーに、新しいサービス アカウントになり代わることを許可してください。
この権限を付与するには、サービス アカウント ユーザーのロール(
roles/iam.serviceAccountUser
)など、iam.serviceAccounts.actAs
権限を含むロールをユーザーに付与します。このロールは、プロジェクトまたはサービス アカウントに付与できます。手順については、サービス アカウントの権限借用の管理をご覧ください。サービス アカウントをリソースに接続するときにサービス アカウントの権限チェックを適用するには、次の組織ポリシー制約を有効にします。
constraints/dataflow.enforceComputeDefaultServiceAccountCheck
constraints/dataproc.enforceComputeDefaultServiceAccountCheck
組織のポリシーの制約
constraints/dataproc.enforceComputeDefaultServiceAccountCheck
は、Cloud Data Fusion の権限確認も適用します。省略可: boolean organization policy enforcer を使用して、すべてのプロジェクトに組織のポリシーの制約が適用されていることを確認します。
新しいリソースをデプロイする場合は、Compute Engine のデフォルト サービス アカウントではなく、新しいサービス アカウントを使用します。
引き続き Compute Engine のデフォルト サービス アカウントを新しいリソースに関連付ける場合は、次の手順を行います。
省略可: ロールの推奨事項を使用して、Compute Engine のデフォルト サービス アカウントの権限の範囲を安全に限定します。
Compute Engine のデフォルト サービス アカウントには、高度な権限を持つ編集者ロール(
roles/editor
)が自動的に付与されます。ただし、本番環境では、このような高度な権限を持つロールの使用はおすすめしません。これらのリソースをデプロイするすべてのユーザーに、Compute Engine のデフォルト サービス アカウントの権限借用が許可されていることを確認します。
この権限を付与するには、サービス アカウント ユーザーのロール(
roles/iam.serviceAccountUser
)など、iam.serviceAccounts.actAs
権限を含むロールをユーザーに付与します。このロールは、プロジェクトまたは Compute Engine のデフォルト サービス アカウントに付与できます。手順については、サービス アカウントの権限借用の管理をご覧ください。サービス アカウントをリソースに接続するときにサービス アカウントの権限チェックを適用するには、次の組織ポリシー制約を有効にします。
constraints/dataflow.enforceComputeDefaultServiceAccountCheck
constraints/dataproc.enforceComputeDefaultServiceAccountCheck
省略可: boolean organization policy enforcer を使用して、すべてのプロジェクトに組織のポリシーの制約が適用されていることを確認します。