Secure Web Proxy を介してアンビエント下り（外向き）トラフィックを転送する

このページでは、Google Kubernetes Engine（GKE）アンビエント ネットワーキングで実行されているワークロードから Secure Web Proxy（SWP）ゲートウェイへの下り（外向き）ルーティングを構成する方法について説明します。

アウトバウンド トラフィックを Secure Web Proxy ゲートウェイ経由でルーティングすることで、アプリケーション コードを変更することなく、URL フィルタリング、ドメイン許可リスト、TLS インスペクションなどの一元化された下り（外向き）セキュリティ ポリシーを適用できます。レイヤ 4 ノード プロキシは、アプリケーション Pod の外部の送信トラフィックを傍受し、ワークロード コンテナが侵害された場合でも、Pod 外のセキュリティ分離を提供します。

アーキテクチャとトラフィック フロー

このデプロイモデルでは、GKE クラスタ、Secure Web Proxy インスタンス、Private Service Connect（PSC）エンドポイントなど、インフラストラクチャの所有権を維持します。

下り（外向き）トラフィック フローは次のように動作します。

  1. ワークロードまたは AI エージェント Pod が、外部エンドポイントまたはインターネットの宛先へのアウトバウンド トラフィックを開始します。
  2. ローカルのレイヤ 4 アンビエント ノード プロキシが、ノード上の送信リクエストをインターセプトします。
  3. ノード プロキシは、Egress ゲートウェイへの HTTP CONNECT トンネルを確立します。
  4. Secure Web Proxy が別の VPC ネットワークに存在する場合、トラフィックは PSC サービス アタッチメントを通過します。
  5. Secure Web Proxy は、トンネルを終了し、構成された下り（外向き）セキュリティ ポリシーを適用し、承認されたリクエストを宛先に転送します。

制限事項

Secure Web Proxy の下り（外向き）ルーティングを設定する前に、プレビュー版の次の制限事項を確認してください。

  • Namespace 全体のポリシー: 下り（外向き）ルーティング ポリシーは、Namespace レベルでのみ適用されます。ラベルセレクタを使用したきめ細かい Pod の選択はサポートされていません。
  • ホスト名フィルタリングには TLS インスペクションが必要です: TLS インスペクションが有効になっていない限り、Secure Web Proxy ポリシーは下り（外向き）トラフィックを IP アドレスでしかフィルタリングできません。
  • Workload Identity: GKE アンビエント ネットワーキングは、標準の Workload Identity をサポートしています。このプレビューでは、マネージド エージェント ID プールはサポートされていません。
  • 認証: アンビエント ノード プロキシと Secure Web Proxy 間の接続では、サーバー証明書の検証がスキップされます。CONNECT リクエストには、クライアント証明書とともにバインドされていないトークンが含まれています。
  • 構成の更新時のリソースの再作成: 既存の Secure Web Proxy インスタンスまたは PSC 構成に対する変更は自動的に伝播されません。Secure Web Proxy または PSC の構成を更新する場合は、変更を適用するために GCPEgressPolicy リソースと Secure Web Proxy インスタンスを削除して再作成する必要があります。
  • TLS 検査の信頼アンカー: GKE は、Secure Web Proxy プライベート CA 証明書をワークロード コンテナに自動的に挿入しません。TLS インスペクションを使用する場合は、信頼証明書をコンテナ イメージに手動でインストールする必要があります。

前提条件

下り（外向き）ルーティングを構成する前に、次のことを確認してください。

  • アンビエント ネットワーキングが有効になっている GKE クラスタ。手順については、GKE アンビエント ネットワーキングを準備するをご覧ください。
  • Cloud de Confiance by S3NS プロジェクトまたは共有 VPC で clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT を使用して構成された serverTlsPolicy を含む、デプロイされた Secure Web Proxy インスタンス。
  • Secure Web Proxy が GKE クラスタとは異なる VPC ネットワークにある場合:
    • Secure Web Proxy 用に作成された PSC サービス アタッチメント。
    • GKE クラスタ VPC ネットワークで構成された PSC コンシューマー エンドポイント。

これらの手順を完了するには、次のロールが必要です。

  • Agent Gateway / Network Services: エージェント ゲートウェイ リソースを構成する networkservices.agentGateways.*（または roles/networkservices.admin）。
  • PSC 管理: Private Service Connect 接続を管理する compute.networkAttachments.list（または roles/compute.networkAdmin）。
  • GKE 管理: カスタム リソース（GCPBackend、GCPEgressPolicy）をデプロイする roles/container.clusterAdmin。

TLS インスペクションの信頼を構成する

Secure Web Proxy ポリシーで TLS インスペクションを使用して暗号化されたアウトバウンド トラフィックを検査する場合、プロキシはプライベート認証局（CA）によって署名された証明書を生成し、外部宛先を偽装します。

ワークロード アプリケーションは、Secure Web Proxy によって提示されたプライベート CA 証明書を信頼する必要があります。GKE はこの証明書を自動的に挿入しないため、SWP CA 証明書（信頼アンカー）をコンテナのトラストストアにインストールする必要があります。

CA 証明書をコンテナ イメージに追加するには、Dockerfile に次の行を追加します。

COPY swp-ca-cert.pem /usr/local/share/ca-certificates/swp-ca-cert.crt
RUN update-ca-certificates

ゲートウェイ エンドポイントを定義する

アンビエント下り（外向き）ルーティングを構成する最初の手順は、ゲートウェイ エンドポイントを作成することです。これにより、GKE クラスタ内の Secure Web Proxy エンドポイントが定義され、プロキシのロケーションがアンビエント ネットワーキングに通知されます。

Secure Web Proxy または Private Service Connect（PSC）サービス アタッチメントの URI を指定するには、GKE クラスタに GCPBackend カスタム リソースを作成します。

  1. 次のマニフェストを swp-backend.yaml として保存します。

    同じ VPC

    apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: swp-backend
  namespace: ambient-test
spec:
  serviceUris:
  - //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/SWP_NAME

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

    • ambient-test: アンビエント ネットワーキングに登録されている Namespace。
    • PROJECT_ID: 実際の Cloud de Confiance by S3NS プロジェクト ID。
    • REGION: Secure Web Proxy または PSC サービス アタッチメントがデプロイされているリージョン。

    • SWP_NAME: Secure Web Proxy の名前。

    Cross-VPC

    apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: swp-backend
  namespace: ambient-test
spec:
  serviceUris:
  - //compute.googleapis.com/projects/PROJECT_ID/regions/REGION/serviceAttachments/ATTACHMENT_NAME

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

    • ambient-test: アンビエント ネットワーキングに登録されている Namespace。
    • PROJECT_ID: 実際の Cloud de Confiance by S3NS プロジェクト ID。
    • REGION: Secure Web Proxy または PSC サービス アタッチメントがデプロイされているリージョン。
    • ATTACHMENT_NAME: Secure Web Proxy が別の VPC ネットワークにある場合は、PSC サービス アタッチメントの名前。

  2. GCPBackend リソースを適用します。

    kubectl apply -f swp-backend.yaml

下り（外向き）トラフィックのリダイレクトを構成する

GCPEgressPolicy カスタム リソースを作成して、名前空間から Secure Web Proxy ゲートウェイにアウトバウンド トラフィックをルーティングします。これにより、アンビエント ノード プロキシが Secure Web Proxy への HTTP CONNECT トンネルを確立するために必要なシグナリングが提供されます。これは、下り（外向き）ルーティングに必要です。

  1. 次のマニフェストを swp-egress-policy.yaml として保存します。

    apiVersion: networking.gke.io/v1
kind: GCPEgressPolicy
metadata:
  name: swp-egress-policy
  namespace: ambient-test
spec:
  to:
    excludeCIDRRanges:
    - "CLUSTER_CONTROL_PLANE_CIDR"
  proxyRef:
    group: networking.gke.io
    kind: GCPBackend
    name: swp-backend

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

    • ambient-test: アンビエント ネットワーキングに登録されている Namespace。
    • CLUSTER_CONTROL_PLANE_CIDR: Secure Web Proxy をバイパスする内部通信の CIDR の範囲（GKE コントロール プレーンのアドレス範囲や内部 VPC サブネットなど）。

  2. GCPEgressPolicy リソースを適用します。

    kubectl apply -f swp-egress-policy.yaml

    ポリシーが適用されると、Namespace 内のワークロードからのアウトバウンド トラフィックが Secure Web Proxy にリダイレクトされます。

トラブルシューティング

次のガイダンスを使用して、アンビエント下り（外向き）ルーティングの問題を診断して解決します。

  • トラフィックが Secure Web Proxy に到達しない:
    • GCPBackend リソースが正しい PSC サービス アタッチメント URI を指していることを確認します。
    • PSC エンドポイントがプロデューサー VPC で確立され、受け入れられていることを確認します。
    • GCPEgressPolicy の excludeCIDRRanges が、宛先トラフィックと誤って一致していないことを確認します。
  • mTLS 接続の失敗:
    • Secure Web Proxy がノード プロキシからの接続を受け入れるように構成されていることを確認します。
  • TLS インスペクション証明書のエラー:
    • クライアント リクエストが証明書の検証エラー（x509: certificate signed by unknown authority など）で失敗した場合は、Secure Web Proxy CA 証明書がワークロード コンテナのシステム証明書ストアに正しくインストールされていることを確認します。