このページの一部またはすべての情報は、S3NS の Cloud de Confiance に適用されない場合があります。詳細については、Google Cloud との違いをご確認ください。

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

Autopilot Standard

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

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

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

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

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

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

制限事項

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

Namespace 全体のポリシー: 下り（外向き）ルーティングポリシーは Namespace レベルでのみ適用されます。ラベルセレクタを使用した Pod の詳細な選択はサポートされていません。
ホスト名フィルタリングには TLS インスペクションが必要: Secure Web Proxy ポリシーでは、TLS インスペクションが有効になっていない限り、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 コンシューマーエンドポイント。

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

Secure Web Proxy / ネットワークサービス: networkservices.gateways.*（または roles/networkservices.admin）。Secure Web Proxy ゲートウェイリソースを構成します。
PSC 管理（クロス VPC デプロイのみ）: 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 カスタムリソースを作成します。

同じ VPC

次のマニフェストを swp-backend.yaml として保存します。
```
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 がデプロイされているリージョン。
- SWP_NAME: Secure Web Proxy の名前。
GCPBackend リソースを適用します。
```
kubectl apply -f swp-backend.yaml
```

クロス VPC

次のマニフェストを swp-backend.yaml として保存します。
```
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: PSC サービスアタッチメントがデプロイされているリージョン。
- ATTACHMENT_NAME: Secure Web Proxy が別の VPC ネットワークにある場合は、PSC サービスアタッチメントの名前。
GCPBackend リソースを適用します。
```
kubectl apply -f swp-backend.yaml
```

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

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

次のマニフェストを 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 サブネットなど）。
GCPEgressPolicy リソースを適用します。
```
kubectl apply -f swp-egress-policy.yaml
```
ポリシーが適用されると、名前空間内のワークロードからのアウトバウンドトラフィックが Secure Web Proxy にリダイレクトされます。

トラブルシューティング

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

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