Sebagian atau seluruh informasi di halaman ini mungkin tidak berlaku untuk Cloud de Confiance dari S3NS. Lihat Perbedaan dengan Google Cloud untuk mengetahui detail selengkapnya.

Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Merutekan traffic keluar sekitar melalui Secure Web Proxy

Autopilot Standard

Halaman ini menunjukkan cara mengonfigurasi perutean keluar untuk workload yang berjalan di jaringan ambient Google Kubernetes Engine (GKE) ke gateway Secure Web Proxy (SWP).

Dengan merutekan traffic keluar melalui gateway Secure Web Proxy, Anda dapat menerapkan kebijakan keamanan keluar yang terpusat—seperti pemfilteran URL, daftar domain yang diizinkan, dan pemeriksaan TLS—tanpa mengubah kode aplikasi. Proxy node Layer 4 mencegat traffic keluar di luar Pod aplikasi, sehingga memberikan isolasi keamanan di luar Pod meskipun container workload terganggu.

Arsitektur dan alur traffic

Dalam model deployment ini, Anda mempertahankan kepemilikan infrastruktur, termasuk cluster GKE, instance Secure Web Proxy, dan endpoint Private Service Connect (PSC).

Alur traffic keluar beroperasi sebagai berikut:

Pod agen AI atau workload memulai traffic keluar ke endpoint eksternal atau tujuan internet.
Proxy node sekitar Layer 4 lokal mencegat permintaan keluar di node.
Proxy node membuat terowongan HTTP CONNECT ke gateway keluar.
Jika Secure Web Proxy berada di jaringan VPC yang berbeda, traffic akan melewati Lampiran Layanan PSC.
Secure Web Proxy menghentikan tunnel, menerapkan kebijakan keamanan keluar yang dikonfigurasi, dan meneruskan permintaan yang sah ke tujuan.

Batasan

Sebelum menyiapkan perutean keluar Secure Web Proxy, tinjau batasan berikut dalam pratinjau:

Kebijakan di seluruh namespace: Kebijakan perutean keluar hanya berlaku di tingkat namespace. Pemilihan Pod terperinci menggunakan pemilih label tidak didukung.
Pemfilteran nama host memerlukan pemeriksaan TLS: Kebijakan Secure Web Proxy hanya dapat memfilter traffic keluar berdasarkan alamat IP, kecuali jika pemeriksaan TLS diaktifkan.
Workload Identity: Jaringan ambient GKE mendukung Workload Identity standar. Kumpulan Managed Agent Identity tidak didukung untuk pratinjau ini.
Autentikasi: Koneksi antara proxy node sekitar dan Secure Web Proxy melewati verifikasi sertifikat server. Permintaan CONNECT mencakup token yang tidak terikat bersama dengan sertifikat klien.
Pembuatan ulang resource saat update konfigurasi: Perubahan yang dilakukan pada instance Secure Web Proxy atau konfigurasi PSC yang ada tidak akan otomatis diterapkan. Jika Anda memperbarui konfigurasi Secure Web Proxy atau PSC, Anda harus menghapus dan membuat ulang resource GCPEgressPolicy dan instance Secure Web Proxy untuk menerapkan perubahan.
Anchor tepercaya untuk pemeriksaan TLS: GKE tidak otomatis menyuntikkan sertifikat CA pribadi Secure Web Proxy ke dalam container workload. Jika menggunakan pemeriksaan TLS, Anda harus menginstal sertifikat tepercaya secara manual ke dalam image container.

Prasyarat

Sebelum mengonfigurasi perutean keluar, pastikan Anda memiliki hal berikut:

Cluster GKE dengan jaringan sekitar diaktifkan. Untuk mendapatkan petunjuk, lihat Menyiapkan jaringan ambient GKE.
Instance Secure Web Proxy yang di-deploy dengan serverTlsPolicy yang dikonfigurasi dengan clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT di projectCloud de Confiance by S3NS atau VPC Bersama Anda.
Jika Secure Web Proxy berada di jaringan VPC yang berbeda dengan cluster GKE Anda:
- Lampiran Layanan PSC yang dibuat untuk Secure Web Proxy.
- Endpoint Konsumen PSC yang dikonfigurasi di jaringan VPC cluster GKE Anda.

Untuk menyelesaikan langkah-langkah ini, Anda harus memiliki peran berikut:

Agent Gateway / Network Services: networkservices.agentGateways.* (atau roles/networkservices.admin) untuk mengonfigurasi resource Agent Gateway.
Pengelolaan PSC: compute.networkAttachments.list (atau roles/compute.networkAdmin) untuk mengelola koneksi Private Service Connect.
Pengelolaan GKE: roles/container.clusterAdmin untuk men-deploy resource kustom (GCPBackend, GCPEgressPolicy).

Mengonfigurasi kepercayaan untuk pemeriksaan TLS

Jika kebijakan Secure Web Proxy Anda menggunakan pemeriksaan TLS untuk memeriksa traffic keluar terenkripsi, proxy akan membuat sertifikat yang ditandatangani oleh Certificate Authority (CA) pribadinya untuk meniru tujuan eksternal.

Aplikasi workload Anda harus memercayai sertifikat CA pribadi yang ditampilkan oleh Secure Web Proxy. Karena GKE tidak menyuntikkan sertifikat ini secara otomatis, Anda harus menginstal sertifikat CA SWP (anchor tepercaya) ke penyimpanan tepercaya penampung Anda.

Untuk menambahkan sertifikat CA ke image container Anda, sertakan baris berikut di Dockerfile Anda:

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

Menentukan endpoint gateway

Langkah pertama dalam mengonfigurasi perutean keluar ambien adalah membuat endpoint gateway, yang menentukan endpoint Secure Web Proxy dalam cluster GKE Anda dan memberi tahu jaringan ambien tentang lokasi proxy.

Untuk menentukan URI Lampiran Layanan Secure Web Proxy atau Private Service Connect (PSC), buat resource kustom GCPBackend di cluster GKE Anda:

Simpan manifes berikut sebagai swp-backend.yaml:

VPC yang sama
```
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
```
Ganti kode berikut:
- ambient-test: namespace yang terdaftar dalam jaringan sekitar.
- PROJECT_ID: Cloud de Confiance by S3NS Project ID Anda.
- REGION: region tempat Secure Web Proxy atau Lampiran Layanan PSC Anda di-deploy.
- SWP_NAME: nama Secure Web Proxy Anda.
Lintas 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
```
Ganti kode berikut:
- ambient-test: namespace yang terdaftar dalam jaringan sekitar.
- PROJECT_ID: Cloud de Confiance by S3NS Project ID Anda.
- REGION: region tempat Secure Web Proxy atau Lampiran Layanan PSC Anda di-deploy.
- ATTACHMENT_NAME: nama Lampiran Layanan PSC Anda, jika Secure Web Proxy Anda berada di jaringan VPC yang berbeda.
Terapkan resource GCPBackend:
```
kubectl apply -f swp-backend.yaml
```

Mengonfigurasi pengalihan traffic keluar

Buat resource kustom GCPEgressPolicy untuk merutekan traffic keluar dari namespace ke gateway Secure Web Proxy. Hal ini menyediakan sinyal yang diperlukan agar proxy node sekitar dapat membuat tunnel HTTP CONNECT ke Secure Web Proxy, yang diperlukan untuk perutean keluar.

Simpan manifes berikut sebagai 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

Ganti kode berikut:

ambient-test: Namespace yang terdaftar dalam jaringan sekitar.
CLUSTER_CONTROL_PLANE_CIDR: Rentang CIDR untuk komunikasi internal yang harus melewati Secure Web Proxy (seperti rentang alamat IP bidang kontrol GKE atau subnet VPC internal).

Terapkan resource GCPEgressPolicy:
```
kubectl apply -f swp-egress-policy.yaml
```
Setelah kebijakan diterapkan, traffic keluar dari workload di namespace akan dialihkan ke Secure Web Proxy.

Pemecahan masalah

Gunakan panduan berikut untuk mendiagnosis dan menyelesaikan masalah terkait perutean keluar lingkungan:

Traffic tidak mencapai Secure Web Proxy:
- Pastikan resource GCPBackend mengarah ke URI Lampiran Layanan PSC yang benar.
- Pastikan endpoint PSC dibuat dan diterima di VPC produsen.
- Pastikan excludeCIDRRanges di GCPEgressPolicy tidak cocok dengan traffic tujuan Anda secara tidak sengaja.
Kegagalan koneksi mTLS:
- Pastikan bahwa Secure Web Proxy dikonfigurasi untuk menerima koneksi dari proxy node.
Error sertifikat pemeriksaan TLS:
- Jika permintaan klien gagal karena error validasi sertifikat (seperti x509: certificate signed by unknown authority), pastikan sertifikat CA Secure Web Proxy diinstal dengan benar di penyimpanan sertifikat sistem penampung beban kerja.