Mengamankan Gateway

Halaman ini menjelaskan cara mengamankan Gateway menggunakan berbagai fitur keamanan:

• Kebijakan SSL untuk membantu memastikan Gateway menggunakan protokol dan algoritma aman yang diperlukan

• Sertifikat untuk mengamankan traffic Klien-ke-Gateway dan Gateway-ke-Backend dengan TLS

• Kebijakan keamanan Google Cloud Armor untuk melindungi Layanan dari serangan DDoS

• Identity-Aware Proxy (IAP) untuk menyediakan lapisan autentikasi dan otorisasi sebelum mengizinkan akses ke Layanan

Untuk mempelajari keamanan Gateway lebih lanjut, lihat keamanan Gateway.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

• Aktifkan Google Kubernetes Engine API.
Aktifkan Google Kubernetes Engine API
• Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. gcloud CLI versi sebelumnya mungkin tidak mendukung menjalankan perintah dalam dokumen ini.

Persyaratan GKE Gateway Controller

• Gateway API hanya didukung di cluster native VPC.
• Jika menggunakan GatewayClass regional atau lintas region, Anda harus mengaktifkan subnet khusus proxy.
• Cluster Anda harus mengaktifkan add-on HttpLoadBalancing.
• Jika menggunakan Istio, Anda harus mengupgrade Istio ke salah satu versi berikut:
  • 1.15.2 atau yang lebih baru
  • 1.14.5 atau yang lebih baru
  • 1.13.9 atau yang lebih baru.

• Jika Anda menggunakan VPC Bersama, di project host, Anda harus menetapkan peran Compute Network User ke Akun layanan GKE untuk project layanan.

• Pastikan Anda sudah memiliki cluster Autopilot atau Standard. Jika Anda memerlukannya, buat cluster Autopilot.

Batas dan pembatasan

Selain batasan dan pembatasan pengontrol GKE Gateway, batasan berikut berlaku khusus untuk keamanan Gateway:

• Konfigurasi TLS menggunakan Sertifikat SSL atau Certificate Manager di Gateway tidak didukung dengan GKE versi 1.28.4-gke.1083000. Gunakan secret Kubernetes sebagai solusi untuk versi GKE ini.

• Anda tidak dapat menggunakan anotasi networking.gke.io/certmap dengan tls.certificateRefs di resource Gateway yang sama. Jika Anda mereferensikan CertificateMap di Gateway, GKE akan memperlakukan ini sebagai error.

• Certificate Manager mendukung sertifikat yang dikelola sendiri dan dikelola Google. Sertifikat yang dikelola Google kompatibel dengan Gateway regional dan Gateway global.

• Saat menggunakan sertifikat SSL yang dikelola Google, Anda harus membuat sertifikat SSL di luar GKE sebelum melampirkannya ke Gateway.

• Anda tidak dapat menggunakan layanan yang sama sebagai backend ke Gateway regional dan global jika Anda mereferensikan kebijakan keamanan backend Google Cloud Armor di GCPBackendPolicy. Anda harus membuat dua layanan dan kebijakan terpisah untuk kasus penggunaan ini.

• Gateway Controller tidak mendukung resource ManagedCertificate.

• Gateway Controller tidak mendukung anotasi networking.gke.io/managed-certificates.

• Jika Anda mengonfigurasi Cloud CDN dengan Gateway GKE, Anda tidak dapat mengaktifkan IAP dan Cloud CDN dengan Gateway yang sama, termasuk rute individual dengan Cloud CDN. Jika Anda perlu mengaktifkan Cloud CDN untuk rute yang menggunakan resource GCPHTTPFilter, Anda harus menghapus GCPBackendPolicy yang ada yang mengonfigurasi IAP untuk Gateway tersebut terlebih dahulu.

• Kuota TrustConfig. Untuk mengetahui informasi tentang total ukuran semua resource TrustConfig di setiap lokasi, lihat Kuota dan batas resource.

• Penyelarasan lokasi. Resource TrustConfig yang dirujuk harus ada di lokasi yang sama (global atau region tertentu) dengan Gateway yang menggunakan Layanan.

• Batasan namespace. Resource BackendTLSPolicy dan resource targetnya harus berada di namespace yang sama.

Untuk mengetahui daftar kolom Gateway API yang didukung dan kemampuan resource GatewayClass yang tersedia di GKE, lihat Kemampuan GatewayClass.

Mengamankan Gateway menggunakan Secret Kubernetes

Dalam contoh ini, Anda akan mengonfigurasi Gateway menggunakan Secret Kubernetes.

Menyimpan sertifikat di Secret Kubernetes

Anda dapat menggunakan sertifikat yang diterbitkan dan divalidasi oleh certificate authority (CA) atau membuat sertifikat yang ditandatangani sendiri. Langkah-langkah berikut menggunakan sertifikat yang ditandatangani sendiri.

1. Buat kunci pribadi:

   openssl genrsa -out PRIVATE_KEY_FILE 2048
   

   Ganti PRIVATE_KEY_FILE dengan nama file kunci pribadi Anda, misalnya private-key.pem. Untuk informasi selengkapnya, lihat Memilih atau membuat kunci pribadi.

2. Buat file konfigurasi Open SSL:

   cat <<EOF >CONFIG_FILE
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   
   [dn_requirements]
   0.organizationName        = example
   commonName                = store.example.com
   
   [sans_list]
   DNS.1                     = store.example.com
   EOF
   

   Ganti CONFIG_FILE dengan nama untuk file konfigurasi baru, misalnya config-file.cnf.

3. Buat file permintaan penandatanganan sertifikat (CSR):

   openssl req -new -key PRIVATE_KEY_FILE \
       -out CSR_FILE \
       -config CONFIG_FILE
   

   Ganti CSR_FILE dengan nama file CSR baru, misalnya cert.pem. Untuk informasi selengkapnya, lihat Membuat CSR.

4. Tanda tangani CSR:

   openssl x509 -req \
       -signkey PRIVATE_KEY_FILE \
       -in CSR_FILE \
       -out CERTIFICATE_FILE \
       -extfile CONFIG_FILE \
       -extensions extension_requirements \
       -days 30
   

   Ganti CERTIFICATE_FILE dengan jalur dan nama file yang dihasilkan perintah ini, misalnya cert-file.pem. Untuk informasi selengkapnya, lihat Menandatangani CSR.

5. Buat Secret TLS Kubernetes menggunakan kunci dan file sertifikat yang sudah Anda buat:

   kubectl create secret tls store-example-com \
       --cert=CERTIFICATE_FILE \
       --key=PRIVATE_KEY_FILE
   

   GKE menyimpan sertifikat dan kunci ini sebagai resource Kubernetes yang dapat dilampirkan ke Gateway.

Membuat Gateway dan HTTPRoute

1. Simpan manifes berikut sebagai external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate
         certificateRefs: # Directly reference the Kubernetes Secret containing the TLS certificate and private key.
         - name: store-example-com # The name of the TLS secret.
   

   Manifes ini menjelaskan Gateway dengan properti berikut:

   • gatewayClassName: gke-l7-global-external-managed: men-deploy Load Balancer Aplikasi eksternal global.
   • protocol: HTTPS dan port: 443: diperlukan untuk mengaktifkan TLS.
   • tls: mereferensikan Secret Kubernetes yang dibuat pada langkah sebelumnya.

2. Terapkan manifes ke cluster:

   kubectl apply -f external-gateway.yaml
   

3. Simpan manifes berikut sebagai store-external-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http # Link this route to the 'external-http' Gateway.
     hostnames:
     - "store.example.com" # Match traffic for this hostname.
     rules:
     - backendRefs: # Define where to forward the traffic.
       - name: store-v1
         port: 8080
   

   Manifes ini menjelaskan HTTPRoute yang cocok dengan traffic ke store.example.com dan mengirimkannya ke Service store-v1.

4. Terapkan manifes ke cluster:

   kubectl apply -f store-external-route.yaml
   

Memverifikasi Gateway

Pastikan Gateway berfungsi dengan mengirim permintaan melalui internet.

1. Dapatkan alamat IP Gateway:

   kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
   

   Output-nya akan mirip dengan berikut ini:

   203.0.113.12
   

   Output ini adalah alamat IP publik, yang berarti semua klien dengan akses internet dapat terhubung ke sana.

2. Akses domain Gateway menggunakan curl:

   curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert CERTIFICATE_FILE -v
   

   Ganti kode berikut:

   • GATEWAY_IP_ADDRESS: alamat IP load balancer Gateway.
   • CERTIFICATE_FILE: file sertifikat yang Anda buat. Anda harus menyimpan file ini di komputer yang digunakan untuk terhubung ke Gateway. Sertifikat ini diperlukan untuk mengautentikasi Gateway karena Gateway menggunakan sertifikat yang ditandatangani sendiri.

   Opsi --resolve me-resolve nama domain ke alamat IP Gateway, yang diperlukan karena DNS tidak dikonfigurasi untuk domain ini.

   Outputnya mirip dengan hal berikut ini:

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   # This block shows the certificate details presented by the Gateway.
   # The value of the 'common name' field matches the requested hostname.
   * Server certificate:
   *  subject: O=example; CN=store.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: store.example.com (matched)
   *  issuer: O=example; CN=store.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gw",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "store-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08"
     # Several lines of output omitted here.
   }
   

   Output ini mencakup TLS handshake yang berhasil, diikuti dengan respons dari aplikasi. Koneksi TLS dihentikan di Gateway dan aplikasi merespons klien dengan aman.

Mengamankan Gateway menggunakan sertifikat SSL

Dalam contoh ini, Anda mengonfigurasi Gateway dengan sertifikat SSL yang dikelola Google.

Membuat sertifikat SSL

1. Buat resource SslCertificate global yang dikelola Google:

   gcloud compute ssl-certificates create store-example-com \
       --domains=store.example.com \
       --global
   

Membuat Gateway dan HTTPRoute

1. Simpan manifes berikut sebagai external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate # Terminate TLS using your SSL certificate.
         options:
           networking.gke.io/pre-shared-certs: store-example-com # Specify the Google Cloud SSL certificate resource name.
   

   Manifes ini menjelaskan Gateway dengan properti berikut:

   • gatewayClassName: gke-l7-global-external-managed: men-deploy Load Balancer Aplikasi eksternal global.
   • protocol:HTTPS dan port:443: diperlukan untuk mengaktifkan TLS.
   • tls.mode:Terminate: menghentikan TLS menggunakan sertifikat SSL Anda.

2. Terapkan manifes ke cluster Anda:

   kubectl apply -f external-gateway.yaml
   

3. Simpan manifes HTTPRoute berikut sebagai store-external-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
   

4. Deploy HTTPRoute di cluster Anda:

   kubectl apply -f store-external-route.yaml
   

   Mungkin perlu waktu beberapa menit hingga GKE men-deploy Gateway.

Memverifikasi Gateway

1. Dapatkan alamat IP Gateway:

   kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
   

   Output-nya akan mirip dengan berikut ini:

   203.0.113.12
   

   Output ini adalah alamat IP publik, yang berarti semua klien dengan akses internet dapat terhubung ke sana.

2. Perbarui data A atau AAAA untuk mengarahkan domain Anda ke alamat IP Gateway.

   Langkah ini hanya diperlukan jika Anda mengonfigurasi sertifikat SSL yang dikelola Google. Jika mengonfigurasi sertifikat yang dikelola sendiri, Anda dapat melewati langkah ini.

   Setelah data DNS diperbarui, diperlukan waktu hingga 10 menit agar load balancer mulai menggunakan sertifikat yang dikelola Google.

3. Pastikan Gateway berfungsi dengan mengirim permintaan melalui internet menggunakan curl:

   curl https://store.example.com -v
   

   Output-nya akan mirip dengan berikut ini:

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: O=example; CN=store.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: store.example.com (matched)
   *  issuer: O=example; CN=store.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gw",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "store-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08",
     "zone": "us-west1-a"
   }
   

   Output ini mencakup TLS handshake yang berhasil dan respons dari aplikasi. TLS dihentikan di Gateway dengan benar dan aplikasi merespons klien dengan aman.

Mengamankan Gateway menggunakan Certificate Manager

Dalam contoh ini, Anda akan mengonfigurasi Gateway menggunakan Certificate Manager.

Membuat Certificate

gcloud certificate-manager certificates create "CERTIFICATE_NAME" \
    --certificate-file="CERTIFICATE_FILE" \
    --private-key-file="PRIVATE_KEY_FILE" \
    --location="REGION"

Membuat Gateway dan HTTPRoute

Memverifikasi Gateway

1. Dapatkan alamat IP Gateway:

   kubectl get gateway external-http -o=jsonpath="{.status.addresses[0].value}"
   

   Output-nya akan mirip dengan berikut ini:

   203.0.113.12
   

   Output ini adalah alamat IP publik, yang berarti semua klien dengan akses internet dapat terhubung ke sana.

2. Perbarui data A atau AAAA untuk mengarahkan domain Anda ke alamat IP Gateway.

   Langkah ini hanya diperlukan jika Anda mengonfigurasi sertifikat SSL yang dikelola Google. Jika mengonfigurasi sertifikat yang dikelola sendiri, Anda dapat melewati langkah ini.

   Setelah data DNS diperbarui, diperlukan waktu hingga 10 menit agar load balancer mulai menggunakan sertifikat yang dikelola Google.

3. Akses domain Gateway menggunakan curl:

   curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert CERTIFICATE_FILE -v
   

   Ganti kode berikut:

   • GATEWAY_IP_ADDRESS: alamat IP load balancer Gateway.
   • CERTIFICATE_FILE: file sertifikat yang Anda buat. Anda harus menyimpan file ini di komputer yang digunakan untuk terhubung ke Gateway. Sertifikat ini diperlukan untuk mengautentikasi Gateway karena Gateway menggunakan sertifikat yang ditandatangani sendiri.

   Outputnya mirip dengan hal berikut ini:

   ...
   * TLSv1.2 (OUT), TLS handshake, Client hello (1):
   * TLSv1.2 (IN), TLS handshake, Server hello (2):
   * TLSv1.2 (IN), TLS handshake, Certificate (11):
   * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
   * TLSv1.2 (IN), TLS handshake, Server finished (14):
   * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
   * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (OUT), TLS handshake, Finished (20):
   * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
   * TLSv1.2 (IN), TLS handshake, Finished (20):
   * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: O=example; CN=store.example.com
   *  start date: Apr 19 15:54:50 2021 GMT
   *  expire date: Apr 19 15:54:50 2022 GMT
   *  common name: store.example.com (matched)
   *  issuer: O=example; CN=store.example.com
   *  SSL certificate verify ok.
   ...
   {
     "cluster_name": "gw",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
     "pod_name": "store-v1-84b47c7f58-tj5mn",
     "pod_name_emoji": "😍",
     "project_id": "agmsb-k8s",
     "timestamp": "2021-04-19T16:30:08",
     "zone": "us-west1-a"
   }
   

   Output ini mencakup TLS handshake yang berhasil dan respons dari aplikasi. TLS dihentikan di Gateway dengan benar dan aplikasi merespons klien dengan aman.

Mengonfigurasi TLS backend untuk Gateway

TLS backend memungkinkan load balancer GKE Gateway memverifikasi identitas backend yang terhubung dengannya. TLS backend menambahkan langkah verifikasi eksplisit selama TLS handshake antara Gateway dan Pod backend. Gateway bertindak sebagai klien TLS, memvalidasi sertifikat server backend berdasarkan serangkaian Certificate Authority (CA) tepercaya yang Anda konfigurasi. Verifikasi ini terjadi saat koneksi baru dibuat, sehingga memastikan Gateway hanya berkomunikasi dengan backend tepercaya dan meningkatkan keamanan secara keseluruhan.

Anda dapat mengonfigurasi TLS yang diautentikasi backend menggunakan resource BackendTLSPolicy yang dilampirkan ke Service, InferencePool, ServiceImport, atau GCPInferencePoolImport. BackendTLSPolicy harus berada di namespace yang sama dengan resource target.

TLS backend didukung untuk GatewayClass berikut:

• gke-l7-global-external-managed dan gke-l7-global-external-managed-mc (hanya mendukung backend Service dan ServiceImport)
• gke-l7-regional-external-managed dan gke-l7-regional-external-managed-mc
• gke-l7-rilb dan gke-l7-rilb-mc
• gke-l7-cross-regional-internal-managed-mc

Menggunakan ConfigMap Kubernetes (Standar)

Dalam metode ini, Anda memberikan sertifikat CA secara langsung di ConfigMap Kubernetes.

1. Buat resource ConfigMap yang berisi sertifikat CA berenkode PEM Anda. Untuk mengetahui informasi selengkapnya, lihat persyaratan sertifikat. Setiap ConfigMap hanya boleh berisi satu sertifikat CA. Anda harus membuat ConfigMap ini di namespace yang sama dengan resource BackendTLSPolicy. BackendTLSPolicy tidak mendukung referensi lintas namespace ke resource ConfigMap.

   Data sertifikat harus ditempatkan di bawah kunci ca.crt:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: my-backend-ca
   data:
     ca.crt: |
       -----BEGIN CERTIFICATE-----
       PEM_DATA
       -----END CERTIFICATE-----
   

   Ganti PEM_DATA dengan konten sertifikat CA Anda yang berformat PEM dan dienkode Base64.

2. Targetkan Service, InferencePool, ServiceImport, atau GCPInferencePoolImport dengan BackendTLSPolicy yang mereferensikan ConfigMap:

   Layanan

   Manifes berikut menunjukkan BackendTLSPolicy yang menargetkan Layanan:

   apiVersion: gateway.networking.k8s.io/v1
   kind: BackendTLSPolicy
   metadata:
     name: secure-backend-policy
   spec:
     targetRefs:
     - group: "" # empty group means Core API.
       kind: Service
       name: my-service-name
     validation:
       hostname: "backend.example.com"
       caCertificateRefs:
       - group: "" # empty group means Core API.
         kind: ConfigMap
         name: my-backend-ca
   

   InferencePool

   Manifes berikut menunjukkan BackendTLSPolicy yang menargetkan InferencePool:

   apiVersion: gateway.networking.k8s.io/v1
   kind: BackendTLSPolicy
   metadata:
     name: secure-backend-policy-inferencepool
   spec:
     targetRefs:
     - group: "inference.networking.k8s.io" # For InferencePool
       kind: InferencePool
       name: my-inference-pool
     validation:
       hostname: "backend.example.com"
       caCertificateRefs:
       - group: "" # empty group means Core API.
         kind: ConfigMap
         name: my-backend-ca
   

   ServiceImport

   Manifes berikut menunjukkan BackendTLSPolicy yang menargetkan ServiceImport:

   apiVersion: gateway.networking.k8s.io/v1
   kind: BackendTLSPolicy
   metadata:
     name: secure-backend-policy-serviceimport
   spec:
     targetRefs:
     - group: "net.gke.io" # For ServiceImport
       kind: ServiceImport
       name: my-service-import
     validation:
       hostname: "backend.example.com"
       caCertificateRefs:
       - group: "" # empty group means Core API.
         kind: ConfigMap
         name: my-backend-ca
   

   GCPInferencePoolImport

   Manifes berikut menunjukkan BackendTLSPolicy yang menargetkan GCPInferencePoolImport:

   apiVersion: gateway.networking.k8s.io/v1
   kind: BackendTLSPolicy
   metadata:
     name: secure-backend-policy-gcpinferencepoolimport
   spec:
     targetRefs:
     - group: "networking.gke.io" # For GCPInferencePoolImport
       kind: GCPInferencePoolImport
       name: my-gcp-inference-pool-import
     validation:
       hostname: "backend.example.com"
       caCertificateRefs:
       - group: "" # empty group means Core API.
         kind: ConfigMap
         name: my-backend-ca
   

Menggunakan TrustConfig yang dikelola sendiri (Lanjutan)

Metode ini memungkinkan Anda mereferensikan resource TrustConfig yang Anda kelola secara independen di Certificate Manager. Cloud de Confiance by S3NS

1. Buat resource TrustConfig di Certificate Manager. TrustConfig harus dibuat di project dan lokasi yang sama dengan Gateway.

   • Untuk Gateway global atau multi-cluster (termasuk multi-cluster regional) dan Gateway lintas regional, gunakan lokasi global.
   • Untuk Gateway cluster tunggal regional, gunakan region yang sama dengan Gateway.
   • Jika Layanan Anda digunakan oleh beberapa Gateway di lokasi yang berbeda, Anda harus membuat resource TrustConfig dengan nama yang sama di setiap lokasi tersebut.

2. Targetkan Layanan dengan BackendTLSPolicy yang mereferensikan resource TrustConfig eksternal melalui kolom options:

   apiVersion: gateway.networking.k8s.io/v1
   kind: BackendTLSPolicy
   metadata:
     name: secure-backend-policy
   spec:
     targetRefs:
     - group: "" # empty group means Core API.
       kind: Service
       name: my-service-name
     validation:
       wellKnownCACertificates: "System"
       hostname: "backend.example.com"
       options:
         networking.gke.io/backend-trust-config: "my-trust-config-name"
   

Referensi kolom BackendTLSPolicy

Tabel berikut menjelaskan kolom utama dalam resource BackendTLSPolicy:

Memverifikasi konfigurasi TLS Backend

Setelah menerapkan BackendTLSPolicy, verifikasi bahwa pengontrol Gateway telah menerima konfigurasi dengan memeriksa status kebijakan:

kubectl describe backendtlspolicy POLICY_NAME

Ganti POLICY_NAME dengan nama kebijakan Anda.

Kebijakan berhasil diterapkan jika berisi kondisi Accepted dan ResolvedRefs dengan Status: "True" di bagian Status.Ancestors:

Status:
  Ancestors:
  - Ancestor Ref:
      Group: gateway.networking.k8s.io
      Kind: Gateway
      Name: my-gateway-name
      Namespace: default
    Conditions:
    - Last Transition Time: "2026-02-17T15:19:26Z"
      Message: ""
      Reason: Accepted
      Status: "True"
      Type: Accepted
    - Last Transition Time: "2026-02-17T15:19:26Z"
      Message: ""
      Reason: ResolvedRefs
      Status: "True"
      Type: ResolvedRefs
    Controller Name: networking.gke.io/gateway

Jika Status adalah False untuk salah satu kondisi ini, hal itu menunjukkan bahwa kebijakan belum diterapkan. Periksa kolom Reason dan Message untuk mengetahui detail selengkapnya. Error umum mencakup mereferensikan ConfigMap di caCertificateRefs yang tidak ada atau tidak memiliki kunci ca.crt.

Status ini mengonfirmasi bahwa Gateway telah berhasil memvalidasi kebijakan dan menerapkan setelan TLS ke backend Target Service atau InferencePool. Resource BackendTLSPolicy harus berada di namespace yang sama dengan resource target.

Mengamankan traffic load balancer ke aplikasi menggunakan TLS

Anda dapat mengenkripsi traffic dari load balancer ke Pod backend menggunakan kolom ports[].appProtocol. Kolom yang didukung untuk appProtocol adalah: HTTP, HTTPS, HTTP2, dan kubernetes.io/h2c.

Manifes berikut menjelaskan Service yang menentukan load balancer harus menggunakan traffic HTTPS untuk berkomunikasi dengan Pod backend:

apiVersion: v1
kind: Service
metadata:
  name: store-v2
spec:
  selector:
    app: store
    version: v2
  ports:
  - port: 8080
    targetPort: 8080
    appProtocol: HTTPS

Load balancer tidak memverifikasi sertifikat yang digunakan oleh Pod backend. Anda bertanggung jawab untuk memastikan sertifikat yang digunakan di Pod backend valid.

Mengamankan traffic klien ke load balancer menggunakan kebijakan SSL

Jika aplikasi Anda diekspos melalui gateway eksternal yang menggunakan HTTPS, penting untuk menggunakan protokol terbaru atau menentukan versi SSL atau TLS minimum. Anda dapat mengamankan traffic klien ke load balancer menggunakan kebijakan SSL.

Untuk mengetahui lebih lanjut kebijakan SSL yang dapat dilampirkan ke Gateway dan cara membuatnya, lihat Mengonfigurasi Kebijakan SSL untuk mengamankan traffic klien ke load balancer.

Melindungi backend menggunakan Google Cloud Armor

Kebijakan keamanan Google Cloud Armor membantu melindungi aplikasi yang mengaktifkan load balancing dari serangan berbasis web. Setelah mengonfigurasi kebijakan keamanan Google Cloud Armor, Anda dapat mereferensikannya dalam GCPBackendPolicy yang diterapkan ke Service Kubernetes.

Untuk mengonfigurasi kebijakan Google Cloud Armor dengan Gateway, lihat Mengonfigurasi kebijakan keamanan Google Cloud Armor untuk mengamankan Layanan backend.

Mengautentikasi permintaan ke backend menggunakan Identity-Aware Proxy

Identity-Aware Proxy membantu Anda melindungi backend dari traffic yang tidak diinginkan dengan mengautentikasi klien yang mengirim permintaan ke aplikasi Anda dan memberlakukan otorisasi traffic berbasis peran. Setelah mengaktifkan Identity-Aware Proxy untuk GKE, Anda dapat mereferensikan kredensial OAuth di GCPBackendPolicy yang diterapkan ke Service Kubernetes Anda.

Untuk mengonfigurasi Identity-Aware Proxy dengan Gateway, lihat Mengonfigurasi Identity-Aware Proxy.

Langkah berikutnya

• Pelajari lebih lanjut keamanan Gateway.
• Pelajari cara mengonfigurasi resource Gateway menggunakan Kebijakan.
• Pelajari cara men-deploy Gateway.
• Pelajari lebih lanjut Gateway API