このドキュメントでは、Agent Runtime で PSC インターフェースを使用する場合の概要と設定の詳細について説明します。
概要
エージェントは、Virtual Private Cloud（VPC）ネットワークにアクセスできない Google が管理する安全なネットワークにデプロイされます。PSC インターフェースは、ネットワークへのプライベートで安全なブリッジを作成します。これにより、VPC、オンプレミス、マルチクラウド環境で非公開でホストされているサービスとやり取りするための推奨ソリューションになります。
PSC インターフェースを構成すると、Agent Runtime は、エージェントが実行される Google 所有のテナント プロジェクトにインターフェースをプロビジョニングします。このインターフェースは、プロジェクト内のネットワークアタッチメントに直接接続します。エージェントと VPC 間のすべてのトラフィックは、公共のインターネットを経由することなく、Google のネットワーク内で安全に転送されます。
プライベート アクセスを提供することに加えて、VPC Service Controls を使用する場合は、インターネット アクセスを有効にするために PSC インターフェースが必要です。
エージェントが公共のインターネットにアクセスできるかどうかは、プロジェクトのセキュリティ構成（特に VPC Service Controls を使用しているかどうか）によって異なります。
VPC Service Controls を使用しない場合: PSC インターフェースのみを使用してエージェントを構成すると、エージェントからのトラフィックは VPC にルーティングされます。デフォルトでは、VPC はこのトラフィックの公共のインターネットへのアウトバウンド パスを提供しません。エージェントのインターネット アクセスを有効にするには、VPC 内で下り（外向き）パスを明示的に構成する必要があります。たとえば、VPC に専用のプロキシ VM を設定できます。詳細については、Agent Runtime PSC インターフェース Codelab をご覧ください。
VPC Service Controls を使用している場合: プロジェクトが VPC Service Controls 境界の一部である場合、エージェントのデフォルトの インターネット アクセスは境界によってブロックされ、データの引き出しが防止されます。このシナリオでエージェントがパブリック インターネットにアクセスできるようにするには、VPC を介してトラフィックをルーティングする安全な下り（外向き）パスを明示的に構成する必要があります。 これを行うには、VPC 境界内にプロキシ サーバーを設定し、プロキシ VM がインターネットにアクセスできるように Cloud NAT ゲートウェイを作成することをおすすめします。
Private Service Connect インターフェースの設定の詳細
Private Service Connect インターフェースを使用してデプロイされたエージェントのプライベート接続を有効にするには、ユーザー プロジェクトに VPC ネットワーク、サブネットワーク、ネットワーク アタッチメントを設定する必要があります。
サブネットワークの IP 範囲の要件
Agent Runtime では、Agent Engine ユーザー プロジェクトごとに最小 /28 のサブネットワークが必要です。
ネットワーク アタッチメントのサブネットは、サブネット 100.64.0.0/20 と 240.0.0.0/4 を除く RFC 1918 アドレスと RFC 1918 以外のアドレスをサポートしています。
Agent Runtime は、指定されたネットワークからルーティング可能な RFC 1918 IP アドレス範囲にのみ接続できます。Agent Runtime は、プライベートで使用されるパブリック IP アドレスまたは次の RFC 1918 以外の範囲に到達できません。
100.64.0.0/20192.0.0.0/24192.0.2.0/24198.18.0.0/15198.51.100.0/24203.0.113.0/24240.0.0.0/4
詳細については、 Private Service Connect インターフェースを設定する をご覧ください。
共有 VPC で Private Service Connect インターフェースを使用する
サービス プロジェクトでホスト プロジェクトのネットワークを使用するには、サービス プロジェクトの Agent Platform サービス エージェントに、ホスト プロジェクトの Compute ネットワーク ユーザー（roles/compute.networkUser）ロールが必要です。
次の手順を行います。
サブネットを作成します ホスト プロジェクトに。
ネットワーク アタッチメントを作成するには、サービス プロジェクトまたはホスト プロジェクトを使用します。ネットワーク アタッチメントは、共有 VPC に接続されている任意のプロジェクトで作成できますが、権限を簡素化するために、ネットワーク アタッチメントをサービス プロジェクトに配置することをおすすめします。
サービス プロジェクトのネットワーク アタッチメント（推奨）: サービス プロジェクトの Agent Platform サービス エージェントに Compute ネットワーク管理者（
roles/compute.networkAdmin）ロールを付与します。このロールは、サービス エージェントがネットワーク アタッチメントを更新して Google の内部プロジェクトからのトラフィックを受け入れるために必要です。Compute ネットワーク管理者のロールを使用しない場合は、代わりに次の権限でカスタムロールを作成し、そのロールをサービス プロジェクトの Agent Platform サービス エージェントに付与できます:compute.networkAttachments.getcompute.networkAttachments.updatecompute.regionOperations.get
ホスト プロジェクトのネットワーク アタッチメント: 次の手順を行います。
ホスト プロジェクトで Agent Platform API を有効にします。詳細については、Private Service Connect インターフェースを設定するをご覧ください。
Agent Platform サービス エージェントがホスト プロジェクトに存在しない場合は、次のコマンドを使用して作成します。
gcloud beta services identity create --service=aiplatform.googleapis.com --project=PROJECT_IDここで、PROJECT_ID はプロジェクト ID です。
Compute ネットワーク管理者（
roles/compute.networkAdmin）ロールをホスト プロジェクトの Agent Platform サービス エージェントに付与します。詳細については、Private Service Connect インターフェースを設定するをご覧ください。Compute ネットワーク管理者のロールを使用しない場合は、代わりに次の権限でカスタムロールを作成し、そのロールをホスト プロジェクトの Agent Platform サービス エージェントに付与できます:compute.networkAttachments.getcompute.networkAttachments.updatecompute.regionOperations.get
DNS ピアリング
Private Service Connect インターフェースは安全なネットワーク パスを提供しますが、DNS ピアリングはサービス ディスカバリ メカニズムを提供します。PSC インターフェースを使用する場合は、VPC ネットワーク内のサービスの特定の IP アドレスを知っておく必要があります。サービスにはその内部 IP アドレスを使用して接続できますが、IP が変更される可能性がある本番環境システムではおすすめしません。DNS ピアリングを使用すると、デプロイされたエージェントは、IP アドレスではなく、安定した人間が読める形式の DNS 名を使用して VPC ネットワーク内のサービスに接続できます。DNS ピアリングにより、デプロイされたエージェントは、VPC の Cloud DNS 限定公開ゾーンのレコードを使用して DNS 名を解決できます。詳細については、 プライベート DNS ピアリングを設定するをご覧ください。
制限事項
Agent Runtime を使用した Private Service Connect インターフェースには、次の制限があります。
- リソースを再作成しないと、Runtime エージェントの既存の Private Service Connect インターフェースを変更できません。