今後の認証の変更に備える

Application Integration は、インテグレーションの承認方法を更新しています。これらの変更はまもなく反映されます。ほとんどの統合は変更なしで引き続き実行されますが、一部の統合では、実行を継続するために構成の変更が必要です。このページで説明する内容はすべて、すでに制御している構成を使用しているため、今すぐ変更できます。

承認に関する今後の変更

Application Integration では、統合実行の ID の処理方法が更新されています。すべての実行に明示的な ID が必要になり、次のいずれかとして機能します。

  • 実行をトリガーしたユーザー。呼び出されたシステムは、そのユーザーのアクセス権限を適用します。
  • 実行ユーザー サービス アカウント。このアカウントは、Google Cloud プロジェクト内の他のサービス アカウントと同様に、制御、スコープ設定、監査を行います。

このアップデートにより、以下のようになります。

  • 統合を実行するには、実行ユーザー サービス アカウントとして機能する権限が必要です。
  • どちらの ID も使用できない場合、統合の実行は失敗します。

始める前に

次のタスクを順番に完了します。他の 2 つはどちらも公開で終わっており、公開自体が権限チェックの対象となるため、最初のものを最初に行います。

  1. すでに使用しているすべての実行ユーザー サービス アカウントに対するサービス アカウント ユーザー権限を、インテグレーションを実行、承認、編集、公開するすべてのユーザー（自動化で使用するサービス アカウントを含む）に付与します。
  2. ユーザーなしで実行され、実行ユーザーが設定されていないインテグレーションに、サービス アカウントを設定します。
  3. サービス アカウントのユーザー権限を付与: サービス アカウントまたは OIDC トークン タイプのすべての認証プロファイルで指定されたサービス アカウントに対する権限。通常、これらは実行ユーザー サービス アカウントとは異なるアカウントです。

実行ユーザー サービス アカウントが必要な統合

インテグレーションに必要かどうかを判断する

実行ユーザーの認証情報が実行全体で使用できない場合にのみ、実行ユーザーのサービス アカウントが必要です。これは次の 2 つの状況でのみ発生します。

統合の実行方法 誰かの認証情報が利用可能か 実行ユーザー サービス アカウントが必要ですか？
同期 - 誰かが開始し、結果を待つ はい、全期間 いいえ
非同期 - キューに入れられ、後で完了します。 トリガーされた時点でのみ はい
無人 - スケジュールまたはイベントによって開始される いいえ、人物は写っていません はい

影響を受ける統合を特定する

まず、人がいない状態で実行されることはありますか？次のいずれかに該当する場合は、実行されます。

2 つ目は、実行ユーザー サービス アカウントが空かどうかです。リージョン内のすべての公開済みバージョンと、その実行ユーザー サービス アカウントを一覧表示するには、次のコマンドを実行します。

curl -s -G -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data-urlencode "filter=state=ACTIVE" \
  --data-urlencode "pageSize=1000" \
  "https://REGION-integrations.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/integrations/-/versions" \
| jq -r '.integrationVersions[]
         | [ .name, (.runAsServiceAccount // "NONE") ]
         | @tsv'

次のように置き換えます。

  • REGION: 統合のリージョン。サポートされているリージョンのリストについては、ロケーションをご覧ください。
  • PROJECT_ID: Google Cloud プロジェクトの ID
  • NONE を示す行は、前半も適用される場合にのみ対応が必要です。
  • 代わりに単一の統合を確認するには、 Google Cloud コンソールで統合を開き、統合ツールバーの [統合の概要] ペインを確認します。

統合を更新する

サービス アカウント ユーザーを付与する

ロールを付与するには、次のコマンドを実行します。

gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT \
    --project=SERVICE_ACCOUNT_PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='roles/iam.serviceAccountUser'

次のように置き換えます。

  • SERVICE_ACCOUNT: 実行ユーザー サービス アカウントのメールアドレス、または認証プロファイルで指定されたアカウントのメールアドレス
  • SERVICE_ACCOUNT_PROJECT_ID: サービス アカウントを所有するプロジェクトの ID
  • PRINCIPAL: ユーザーのメールアドレス

他のプリンシパル タイプの場合は、対応する --member 接頭辞を使用します。

  • グループ: group: を使用します。チームメンバーの変更に伴うアクセス管理を簡素化するため、個々のユーザー アカウントではなく Google グループを使用することをおすすめします。
  • サービス アカウント: 自動化プロセスとアプリケーションには serviceAccount: を使用します。

Google Cloud コンソールで同じ操作を行うには:

  1. [IAM と管理] > [サービス アカウント] に移動します。
  2. サービス アカウントを選択します。
  3. [権限] > [アクセス権を付与] をクリックします。

詳細については、サービス アカウントに対するアクセス権の管理をご覧ください。

実行ユーザー サービス アカウントを設定する

  1. サービス アカウントを選択または作成し、統合のタスクがアクセスするリソースに対して必要なロールを付与します。付与するロールを特定するには、プロジェクトの Application Integration サービス エージェント service-PROJECT_NUMBER@gcp-sa-integrations. が現在保持しているロールを確認し、この統合で使用される部分のみを新しいアカウントに付与します。
  2. 統合を実行、承認、編集、公開するすべてのユーザー（自動化を含む）に、このサービス アカウントに対するサービス アカウント ユーザー権限を付与します。
  3. 統合を開き、統合ツールバーの [統合の概要] ペインでサービス アカウントを設定します。
  4. 統合を公開します。詳細については、統合をテストして公開するをご覧ください。

Google Cloud では、すべてのインテグレーションで共有される広範な権限を持つアカウントを 1 つ使用するのではなく、インテグレーションごとに専用の最小スコープのサービス アカウントを使用することをおすすめします。これは、次の理由によるものです。

  • 1 つの統合の効果が含まれます。
  • 監査ログに名前で表示されます。

詳細については、サービス アカウントの操作のベスト プラクティスをご覧ください。

権限がない場合のトラブルシューティング

拒否されたアクションには 2 つの原因があり、それらを区別する価値があります。

  • 実行ユーザー サービス アカウント - ユーザーがこのアカウントとして機能できないか、タスクに必要なものにアクセスできません。
  • 自分の IAM ロール - アクションを実行することはできません。

両方のチェックが適用されるため、一方を修正しても他方は修正されません。

実行ユーザー サービス アカウントのエラー

状況 表示される内容 手順
インテグレーションをトリガーしたユーザーが、その実行ユーザー サービス アカウントとして機能できない トリガーは PERMISSION_DENIED で拒否されます。チェックは実行がキューに登録される前に実行されるため、実行ログには何も表示されません。タスクが失敗したのではなく、何も起こらなかったように見えます。 トリガーしたユーザーにサービス アカウント ユーザーを付与
ユーザー認証情報のない実行には、実行ユーザーのサービス アカウントがありません コネクタ、Call REST Endpoint、Cloud Run functions タスクは、アクセスしようとしている対象に対して失敗します。公開時: The integration is missing run-as service account since governance is enabled for your project. 実行ユーザー サービス アカウントを設定する
タスクが、呼び出し元がサービス アカウントとして動作できない認証プロファイルを使用している そのタスクは拒否されますが、残りの実行は継続されます。 You do not have permission to use Auth Config ID because you cannot act as its service account: SERVICE_ACCOUNT. プロファイルで指定されたアカウントに対するサービス アカウント ユーザーの付与
承認者は実行ユーザーのサービス アカウントとして機能できない 承認プロセスは、目に見えるエラーを生成せずに失敗します。実行は有効期限が切れるまで一時停止されたままになるため、承認が機能しなくなったように見えます。 承認する可能性のあるすべてのユーザーにサービス アカウント ユーザーを付与する
誰かが権限なしでインテグレーションを編集または公開する Publisher does not have required permission to publish integration with service account: SERVICE_ACCOUNT. すでに公開されているものは引き続き実行されます。自動化によって公開される場合は、コンソールではなくデプロイ パイプラインに表示されます。 編集者、パブリッシャー、自動化にサービス アカウント ユーザーを付与する
タスクはトリガーしたユーザーとして実行され、そのユーザーはリソースにアクセスできない 実行は正常に開始されますが、統合に変更がないにもかかわらず、リソースの名前を指定するタスクが 1 つ失敗します。 リソースへのアクセス権を付与するか、すでにアクセス権を持っている実行ユーザー サービス アカウントにインテグレーションを移動します。通常は後者がより良い方法です。インテグレーションの実行者によってアクセス権が異なるのを防ぐことができるためです。

Application Integration のエラーコードの一覧については、エラーコードをご覧ください。

IAM ロールエラー

Application Integration は、実行サービス アカウントに加えて、各アクションに対するユーザーの IAM 権限も検証します。統合の操作時に PERMISSION_DENIED エラーが発生した場合や、実行ログの読み込みに失敗した場合は、必要な権限を付与するロールがあることを確認してください。

操作 次のいずれかのロールが必要です
統合を表示して開く roles/integrations.integrationViewer
実行ログと詳細を表示する roles/integrations.integrationViewer または roles/integrations.integrationInvoker
統合を実行する roles/integrations.integrationInvoker または roles/integrations.integrationEditor
統合を作成、編集する roles/integrations.integrationEditor
統合を公開する roles/integrations.integrationDeployer または roles/integrations.integrationEditor
一時停止された実行を承認または再開する roles/integrations.suspensionResolver または roles/integrations.integrationAdmin
すべての統合に対する完全アクセス権 roles/integrations.integrationAdmin

ロールを付与するには、次のコマンドを実行します。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:PRINCIPAL' \
    --role='ROLE'

詳しくは以下をご覧ください。

よくある質問

ロールを付与しても失敗します。どうしてですか？

  • 権限付与が間違ったプロジェクトに対して行われた。これは、インテグレーションを所有するプロジェクトではなく、サービス アカウントを所有するプロジェクトで行う必要があります。
  • まだ有効になっていません。数分ほどお待ちください。認可の判断は、通常の IAM 伝播遅延に加えて、短時間キャッシュに保存されます。
  • 2 つ目のサービス アカウントが関与している。実行ユーザー サービス アカウントと各認証プロファイルのサービス アカウントは別個のものであり、両方に権限付与が必要です。
  • ブロックはサービス アカウントではなく、独自のロールです。サービス アカウント ユーザーは、実行ユーザー サービス アカウントとして機能できるかどうかに関するものです。アクションの実行が許可されているかどうかは、別の IAM ロールによって管理されます。IAM ロールのエラーをご覧ください。

Integration Invoker ロールだけでは不十分になったのはなぜですか？

統合は引き続き実行できます。統合が実行されるサービス アカウントとして機能することはできません。実行で取得できるアクセス権の量は、このサービス アカウントによって決まります。次のロールには iam.serviceAccounts.actAs が付与されないため、常に個別の付与となります。

  • roles/integrations.integrationAdmin
  • roles/integrations.integrationEditor
  • roles/integrations.integrationInvoker

統合が同期的にしか実行されません。実行ユーザー サービス アカウントが必要ですか？

いいえ。同期実行には、トリガーしたユーザーという ID がすでに存在します。統合に 1 つ必要かどうかを判断するをご覧ください。

コンソールにフラグは表示されません。これで大丈夫ですか？

必ずしもそうとは限りません。警告は観測された実行に部分的に依存するため、実行頻度の低いスケジュールで実行されるインテグレーションや、最近トリガーされていないインテグレーションでは、警告が表示されなくても対応が必要になることがあります。静かなコンソールをオールクリアと見なすのではなく、実行ユーザー サービス アカウントが必要な統合を確認します。

次のステップ