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

Application Integration では、統合が処理を実行するための権限を取得する方法が変更されます。 この変更はまもなく有効になります。ほとんどの統合はこれまでどおり実行されますが、一部の統合では事前に構成を変更する必要があります。構成を変更しないと、これらの統合は実行されなくなります。このページのすべての項目は、すでに管理している構成を使用しているため、今すぐ対応できます。

今後の認可の変更

Application Integration では、統合の実行で ID が処理される方法が更新されます。すべての実行の背後にある ID が明示的になります。実行は、トリガーしたユーザーとして動作するため、呼び出すシステムはそのユーザー自身のアクセス権を適用します。または、選択した実行ユーザー サービス アカウントとして動作します。これは、プロジェクト内の他のサービス アカウントと同様に、制御、スコープ設定、監査を行うことができます。

次の 2 つのことが起こります。統合を実行するには、実行ユーザー サービス アカウントとして動作する権限も必要になります。ID が利用できない実行は、続行せずに停止します。

始める前に

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

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

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

統合に実行ユーザー サービス アカウントが必要かどうかを判断する

実行全体でユーザーの認証情報が利用できない場合にのみ、実行ユーザー サービス アカウントが必要です。これは、次の 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: ユーザーのメールアドレス

グループの場合（通常は、ユーザーの参加や離脱に対応できるため、より良い方法です） user: を group: に置き換えます。自動化の場合は、 serviceAccount: を使用します。

コンソール Google Cloud で同じ操作を行うには、[IAM と管理] > [サービス アカウント] に移動し、サービス アカウントを選択して、[権限] > [アクセス権を付与] をクリックします。詳細については、 サービス アカウントに対するアクセス権の管理 をご覧ください。

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

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

Google Cloud では、すべての統合で共有される広範な権限を持つアカウントではなく、統合ごとに専用の最小限のスコープのサービス アカウントを使用することをおすすめします。これにより、1 つの統合の影響を抑え、監査ログに名前が表示されます。 詳しくは、 サービス アカウントの操作のベスト プラクティスをご覧ください。

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

状況 表示される内容 手順
ユーザーが統合をトリガーしたが、実行ユーザー サービス アカウントとして動作できない トリガーが 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 伝播遅延に加えて、短時間キャッシュに保存されます。
  • 2 つ目のサービス アカウントが関与している。実行ユーザー サービス アカウントと 各認証プロファイルのサービス アカウントは別々であり、どちらにも権限付与が必要です。

統合呼び出し元のロールだけでは不十分なのはなぜですか？

統合は引き続き実行できます。統合が実行されるサービス アカウントとして動作することはできません。実行が取得するアクセス権の量は、これによって決まります。 roles/integrations.integrationAdmin、 roles/integrations.integrationEditor、または roles/integrations.integrationInvoker のいずれも iam.serviceAccounts.actAs を付与しないため、別の権限付与となります。

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

いいえ。同期実行にはすでに ID があります。トリガーしたユーザーです。統合に実行ユーザー サービス アカウントが必要かどうかを判断する をご覧ください。

コンソールに何もフラグが設定されていません。問題ありませんか？

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

次のステップ