Mengamankan Gateway

Autopilot Standard

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.
  Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel properti compute/region. Jika Anda terutama menggunakan cluster zona, tetapkan compute/zone. Dengan menyetel lokasi default, Anda dapat menghindari error di gcloud CLI yang seperti ini: One of [--zone, --region] must be supplied: Please specify location. Anda mungkin perlu menentukan lokasi dalam perintah tertentu jika lokasi cluster Anda berbeda dengan default yang Anda tetapkan.

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.

Catatan: Mengonfigurasi Sertifikat SSL dan anotasi networking.gke.io/certmap di Gateway yang sama bukanlah konfigurasi yang valid dan controller akan memperlakukan ini sebagai error.

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.

Catatan: Mengonfigurasi Sertifikat SSL dan anotasi networking.gke.io/certmap di Gateway yang sama bukanlah konfigurasi yang valid dan controller akan memperlakukan ini sebagai error.

Membuat Certificate

Gateway Global

Untuk membuat Gateway global, Anda mereferensikan resource peta sertifikat yang berisi satu atau beberapa sertifikat. Anda harus membuat setidaknya satu sertifikat dan menambahkannya sebagai entri ke peta sertifikat Anda.

1. Untuk membuat sertifikat, buat terlebih dahulu file kunci pribadi dan sertifikat.

2. Buat resource Certificate dengan memuat sertifikat dan kunci yang dikelola sendiri:

   gcloud certificate-manager certificates create store-example-com-cert \
       --certificate-file="cert.pem" \
       --private-key-file="PRIVATE_KEY_FILE"
   

3. Buat CertificateMap:

   gcloud certificate-manager maps create store-example-com-map
   

4. Buat CertificateMapEntry yang menetapkan sertifikat ke CertificateMap:

   gcloud certificate-manager maps entries create store-example-com-map-entry \
       --map=store-example-com-map \
       --hostname=store.example.com \
       --certificates=store-example-com-cert
   

Gateway Regional

Untuk Gateway regional, Anda membuat Certificate yang akan ditentukan secara langsung saat membuat Gateway. Tidak seperti Gateway global, Anda tidak perlu membuat CertificateMap yang akan diberi sertifikat.

1. Buat file kunci pribadi dan sertifikat.

2. Buat resource Certificate dengan mengupload file sertifikat dan kunci Anda:

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

Ganti kode berikut:

• CERTIFICATE_NAME: nama sertifikat Anda, misalnya store-example-com-cert.
• CERTIFICATE_FILE: nama file sertifikat, misalnya, cert.pem.
• PRIVATE_KEY_FILE: nama file kunci pribadi Anda, seperti private-key.pem. Untuk informasi selengkapnya, lihat Memilih atau membuat kunci pribadi.
• REGION: nama region tempat Anda mengonfigurasi Gateway, misalnya us-central1.

Catatan: Jika Anda menggunakan Gateway lintas-region, ganti flag --location dengan flag --scope=all-regions. Jika --scope=all-regions tidak digunakan, sertifikat tidak akan ditemukan saat membuat gateway. Misalnya, 'Certificate' was not found.

Membuat Gateway dan HTTPRoute

Gateway Global

Untuk membuat Gateway global, selesaikan langkah-langkah berikut:

1. Simpan manifes berikut sebagai cert-map-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
     annotations:
       networking.gke.io/certmap: store-example-com-map
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
     # No TLS section is included here because TLS is handled by the certmap annotation.
   

   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.

   Tidak ada bagian TLS karena TLS dikonfigurasi dengan Certificate Manager menggunakan anotasi networking.gke.io/certmap.

2. Terapkan manifes ke cluster:

   kubectl apply -f cert-map-gateway.yaml
   

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

3. Untuk membuat HTTPRoute, simpan manifes berikut sebagai cert-map-http-route.yaml:

   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: foo
     namespace: default
   spec:
     parentRefs:
     - name: external-http
     hostnames:
     - foo.example.com
     rules:
     - matches:
       - path:
           value: /
       backendRefs:
       - name: foo-v1
         port: 8080
   

4. Terapkan manifes ke cluster:

   kubectl apply -f cert-map-http-route.yaml
   

Gateway Regional

Saat membuat Gateway regional, Anda dapat menentukan sertifikat yang dikelola oleh Pengelola Sertifikat dan sertifikat yang dikelola oleh Compute Engine.

1. Untuk membuat Gateway eksternal regional, simpan manifes berikut sebagai external-gateway.yaml:

      kind: Gateway
      apiVersion: gateway.networking.k8s.io/v1
      metadata:
        name: gateway
        namespace: corp
      spec:
        gatewayClassName: gke-l7-regional-external-managed
        listeners:
        - name: gateway-pre-shared-certmap
          protocol: HTTPS
          port: 443
          tls:
            mode: Terminate # TLS is terminated at the Gateway.
            options: # Specifies a comma-separated list of Certificate Manager certificates to use for TLS termination.
              networking.gke.io/cert-manager-certs: store-example-com-cert1, store-example-com-cert2 # These certificates are directly managed by Certificate Manager.
          allowedRoutes:
            kinds:
            - kind: HTTPRoute
            namespaces:
              from: All
   

   Manifes ini menjelaskan Gateway dengan properti berikut:

   • gatewayClassName: gke-l7-regional-external-managed: men-deploy Load Balancer Aplikasi eksternal regional.
   • protocol: HTTPS dan port: 443: diperlukan untuk mengaktifkan TLS.
   • options:
     • networking.gke.io/cert-manager-certs : sertifikat yang dikelola oleh Certificate Manager.

   Untuk membuat Gateway internal regional, dalam contoh sebelumnya, ubah nilai gatewayClassName menjadi gke-l7-rilb. Tindakan ini akan men-deploy Load Balancer Aplikasi internal.

2. Terapkan manifes ke cluster:

   kubectl apply -f external-gateway.yaml
   

3. Untuk membuat HTTPRoute, simpan manifes berikut sebagai store-external-route.yaml:

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

   Manifes ini menjelaskan HTTPRoute yang cocok dengan traffic untuk store.example.com dan meneruskan traffic ke Layanan store-v1.

4. Terapkan manifes ke cluster:

   kubectl apply -f store-external-route.yaml
   

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 mTLS frontend untuk Gateway

Anda dapat mengonfigurasi validasi sertifikat klien, yang juga dikenal sebagai mTLS frontend, untuk Gateway GKE Anda. mTLS frontend didukung untuk GatewayClass gke-l7-global-external-managed, gke-l7-regional-external-managed, dan gke-l7-rilb serta memungkinkan Gateway mengautentikasi sertifikat yang diberikan oleh klien. Konfigurasi mTLS frontend valid untuk listener HTTPS yang menggunakan mode Terminate.

Catatan: Gateway HTTPS memerlukan sertifikat server. Untuk mengetahui informasi tentang cara mengonfigurasi sertifikat server, lihat bagian sebelumnya dalam dokumen ini.

Anda dapat mengonfigurasi mTLS frontend dengan salah satu cara berikut:

• Gunakan konfigurasi Gateway API (direkomendasikan).
• Menggunakan anotasi TrustConfig yang dikelola sendiri di Gateway (lanjutan).

Mengonfigurasi mTLS frontend menggunakan konfigurasi Gateway API (direkomendasikan)

Catatan: Mengonfigurasi mTLS frontend menggunakan kolom tls.frontendValidation memerlukan Gateway API versi 1.5 atau yang lebih baru.

Menggunakan Gateway API adalah cara yang direkomendasikan untuk mengonfigurasi validasi sertifikat klien. Metode ini melibatkan penyimpanan sumber tepercaya di ConfigMap Kubernetes dan mereferensikan ConfigMap ini dalam spesifikasi Gateway.

1. Buat sumber tepercaya.

   Sumber tepercaya menetapkan dan memvalidasi root of trust untuk sertifikat klien yang ditampilkan ke load balancer. GKE Gateway mendukung sumber tepercaya berdasarkan root certificate.

   Untuk membuat sertifikat, lihat Membuat sertifikat root dan perantara.

2. Buat ConfigMap.

   Simpan sumber tepercaya Anda di ConfigMap Kubernetes. Setiap kunci di ConfigMap harus berisi tepat satu sertifikat CA berenkode PEM dalam format x509 yang valid. Anda harus membuat ConfigMap ini di namespace yang sama dengan resource Gateway, kecuali jika Anda menggunakan ReferenceGrant. Untuk mereferensikan ConfigMap di namespace yang berbeda, lihat ReferenceGrant.

   Tempatkan data sertifikat di bawah kunci ca.crt:

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

   Catatan: Anda dapat mereferensikan hingga delapan resource ConfigMap per konfigurasi (baik dalam konfigurasi default maupun per port). Hanya sertifikat root yang didukung saat menggunakan ConfigMap. Untuk menggunakan sertifikat perantara atau yang diizinkan, Anda harus menggunakan resource TrustConfig yang dikelola sendiri.

   Untuk membuat ConfigMap dengan sertifikat Anda, jalankan perintah berikut:

   kubectl create configmap my-config \
       --from-file=ca.crt=ROOT_CERT_PATH
   

   Ganti ROOT_CERT_PATH dengan jalur ke file sertifikat Anda. ConfigMap hanya dapat berisi satu sertifikat.

3. Konfigurasi Gateway.

   Lampirkan ConfigMap ke Gateway Anda dengan menambahkan bagian tls yang berisi kolom frontendValidation ke spesifikasi Gateway Anda. Konfigurasi default diperlukan dan berlaku untuk semua pemroses HTTPS yang menggunakan mode Terminate, kecuali jika Anda menentukan konfigurasi per port. Contoh berikut menunjukkan konfigurasi Gateway end-to-end yang mencakup sertifikat server (dengan menggunakan anotasi certmap) dan validasi sertifikat klien (dengan menggunakan kolom tls.frontendValidation):

   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: mtls-example
     annotations:
       networking.gke.io/certmap: store-example-com-map
   spec:
     gatewayClassName: gke-l7-global-external-managed
     tls:
       frontendValidation:
         default:
           caCertificateRefs:
           - kind: ConfigMap
             group: ""
             name: my-config
     listeners:
     - name: foo-https
       protocol: HTTPS
       port: 443
       hostname: foo.example.com
       tls:
         mode: Terminate
         # No certificateRefs needed when using the certmap annotation
   

4. Mengganti konfigurasi per port.

   Anda juga dapat menentukan sumber tepercaya unik untuk setiap port. Konfigurasi per-port menggantikan konfigurasi default untuk semua pendengar yang dikonfigurasi untuk port tersebut.

   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: mtls-port-override
     annotations:
       networking.gke.io/certmap: store-example-com-map
   spec:
     gatewayClassName: gke-l7-global-external-managed
     tls:
       frontendValidation:
         default:
           caCertificateRefs:
           - kind: ConfigMap
             group: ""
             name: global-ca-config
         perPort:
         - port: 8443
           tls:
             validation:
               caCertificateRefs:
               - kind: ConfigMap
                 group: ""
                 name: port-specific-ca-config
     listeners:
     - name: https-default
       protocol: HTTPS
       port: 443
       tls:
         mode: Terminate
     - name: https-override
       protocol: HTTPS
       port: 8443
       tls:
         mode: Terminate
   

5. Opsional: Konfigurasi mode validasi klien.

   Secara default, Gateway GKE menerapkan validasi sertifikat klien yang ketat (AllowValidOnly). Untuk mengizinkan sertifikat klien yang tidak valid atau tidak ada, dalam konfigurasi frontendValidation.default, tetapkan nilai kunci mode ke AllowInsecureFallback:

   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: mtls-example
     annotations:
       networking.gke.io/certmap: store-example-com-map # Add this annotation
   spec:
     gatewayClassName: gke-l7-global-external-managed
     tls:
       frontendValidation:
         default:
           caCertificateRefs:
           - kind: ConfigMap
             group: ""
             name: my-config
           mode: AllowInsecureFallback
     listeners:
     - name: foo-https
       protocol: HTTPS
       port: 443
       hostname: foo.example.com
       tls:
         mode: Terminate
         # No certificateRefs needed when using the certmap annotation
   

Menggunakan TrustConfig yang dikelola sendiri (lanjutan)

Atau, konfigurasi validasi sertifikat klien dengan memberikan anotasi pada Gateway Anda dengan resource TrustConfig. Gunakan metode yang dikelola sendiri ini jika Anda memerlukan fleksibilitas tambahan atau jika konfigurasi Anda melampaui batasan Gateway API standar. Metode ini eksklusif dengan metode konfigurasi Gateway API dan berlaku untuk semua pemroses HTTPS di Gateway (penggantian per port tidak didukung).

1. Buat resource TrustConfig. Untuk mengetahui petunjuknya, lihat Membuat resource konfigurasi kepercayaan.

   Saat membuat resource TrustConfig, tentukan global untuk Gateway global (gke-l7-global-external-managed) atau region yang sesuai (misalnya, us-central1) untuk Gateway regional (gke-l7-regional-external-managed dan gke-l7-rilb).

2. Lampirkan TrustConfig ke Gateway Anda menggunakan anotasi networking.gke.io/frontend-trust-config.

   Contoh berikut menunjukkan konfigurasi Gateway end-to-end yang mencakup sertifikat server (menggunakan anotasi certmap) dan validasi sertifikat klien (menggunakan anotasi TrustConfig):

   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: mtls-example
     annotations:
       networking.gke.io/frontend-trust-config: my-trust-config
       networking.gke.io/certmap: store-example-com-map # Add this annotation
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: foo-https
       protocol: HTTPS
       port: 443
       hostname: foo.example.com
       tls:
         mode: Terminate
         # Remove certificateRefs and replace with the comment
         # No certificateRefs needed when using the certmap annotation
   

3. Opsional: Konfigurasi mode validasi klien.

   Secara default, Gateway GKE menerapkan validasi sertifikat klien yang ketat (REJECT_INVALID). Untuk mengizinkan sertifikat klien yang tidak valid atau tidak ada, tetapkan anotasi networking.gke.io/allow-invalid-or-missing-client-cert ke true.

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.

Catatan: Pastikan Pod aplikasi Anda menjalankan server HTTPS di port yang ditargetkan oleh Service atau InferencePool Anda.

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
• gke-l7-regional-external-managed
• gke-l7-rilb

Menggunakan ConfigMap Kubernetes (Standar)

Catatan: Sebaiknya gunakan metode ini untuk mengonfigurasi TLS backend karena menggunakan objek bawaan Kubernetes standar dan sepenuhnya sesuai dengan Gateway API.

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.

   Catatan: Satu BackendTLSPolicy mendukung referensi hingga delapan resource ConfigMap di kolom caCertificateRefs.

   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)

Catatan: Gunakan metode ini jika konfigurasi Anda memerlukan fitur lanjutan seperti daftar yang diizinkan sertifikat, atau jika melampaui batasan Gateway API standar, seperti jumlah maksimum sertifikat perantara atau anchor tepercaya yang didukung.

Metode ini memungkinkan Anda mereferensikan resource TrustConfig yang Anda kelola secara independen di Certificate Manager. Google Cloud

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"
   

   Catatan: Anda tidak dapat menggunakan setelan wellKnownCACertificates: "System" dan caCertificateRefs pada objek yang sama; jika melakukannya, kebijakan akan dibatalkan.

Referensi kolom BackendTLSPolicy

Tabel berikut menjelaskan kolom utama dalam resource BackendTLSPolicy:

Kolom	Deskripsi
targetRefs	Resource backend tempat kebijakan ini diterapkan. Mendukung Service (group: ""), InferencePool (group: "inference.networking.k8s.io"), ServiceImport (group: "net.gke.io"), atau GCPInferencePoolImport (group: "networking.gke.io"). Catatan: Untuk GatewayClass gke-l7-global-external-managed dan gke-l7-global-external-managed-mc, hanya backend Service dan ServiceImport yang didukung.
validation.hostname	Nama host (SNI) yang digunakan oleh Gateway selama TLS handshake dengan pod backend.
validation.subjectAltNames	Opsional. Menentukan satu atau beberapa Nama Alternatif Subjek (SAN) untuk memvalidasi sertifikat backend. Mendukung Hostname dan URI (seperti ID SPIFFE).
validation.caCertificateRefs	Metode standar. Mereferensikan daftar resource ConfigMap (hingga delapan) dalam namespace yang sama. Setiap ConfigMap harus berisi satu sertifikat CA berenkode PEM di bawah kunci ca.crt. Referensi lintas namespace tidak didukung.
validation.wellKnownCACertificates	Metode lanjutan. Tetapkan nilai ke System saat menggunakan TrustConfig yang dikelola sendiri.
options	Peta untuk opsi khusus GKE. Gunakan setelan networking.gke.io/backend-trust-config untuk mereferensikan resource TrustConfig eksternal.

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.

Catatan: networking.gke.io/app-protocol yang sebelumnya didukung kini tidak digunakan lagi. Anotasi ini tidak didukung oleh GKE Gateway Controller.

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.

Catatan: IAP tidak kompatibel dengan Cloud CDN. Jika aplikasi Anda memerlukan caching edge dengan menggunakan resource GCPHTTPFilter, pastikan IAP tidak diaktifkan untuk Gateway yang sama atau rutenya. Untuk informasi selengkapnya tentang cara mengonfigurasi penyimpanan dalam cache, lihat Mengonfigurasi Cloud CDN untuk Gateway.

Langkah berikutnya

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