Versi 1.20

Versi yang tersedia

1.20 (terbaru)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.12

219}

Halaman ini diterjemahkan oleh Cloud Translation API.

Kasus penggunaan keamanan layanan

Dokumen ini menjelaskan kasus penggunaan keamanan Cloud Service Mesh yang umum. Gunakan informasi ini untuk membantu menentukan model keamanan yang paling sesuai dengan kebutuhan Anda. Dokumen ini juga memberikan ringkasan umum tentang hal yang perlu Anda konfigurasi untuk setiap kasus penggunaan.

Untuk ringkasan keamanan layanan, lihat Keamanan layanan Cloud Service Mesh.

Mengaktifkan TLS bersama untuk layanan di mesh

Dalam mesh layanan, Anda dapat mengaktifkan TLS bersama (mTLS) sehingga klien dan server dalam komunikasi harus membuktikan identitas mereka dan mengenkripsi komunikasi.

Autentikasi TLS (mTLS) dalam mesh layanan. — Autentikasi TLS (mTLS) secara menyeluruh dalam mesh layanan (klik untuk memperbesar)

Bagian berikut tidak membahas resource Mesh, Gateway, dan Route. Resource API ini diperlukan untuk membuat mesh dan traffic rute, tetapi Anda tidak perlu memperbaruinya untuk mengaktifkan mTLS.

Pola sebelumnya dapat dicapai dengan mengonfigurasi resource Compute Engine API berikut. Diagram ini menggunakan proxy file bantuan, tetapi mengonfigurasi aplikasi gRPC tanpa proxy dengan mTLS akan menggunakan resource yang sama.

Resource Compute Engine API untuk mTLS dalam mesh. — Resource Compute Engine API untuk mTLS dalam mesh (klik untuk memperbesar)

Untuk membuat model ini, lakukan hal berikut:

Buat kebijakan client transport layer security (TLS).
Buat kebijakan TLS server.
Perbarui kolom securitySettings di layanan backend global yang ada untuk merujuk kebijakan TLS klien yang baru.
Buat kebijakan endpoint:
1. Lihat kebijakan TLS server di kolom server_tls_policy.
2. Tentukan EndpointMatcher untuk memilih klien Mesh Layanan Cloud yang harus menerapkan autentikasi pada traffic masuk.
  
  Pemilihan klien Cloud Service Mesh didasarkan pada label yang ditentukan dalam konfigurasi bootstrap klien Cloud Service Mesh. Label ini dapat diberikan secara manual atau diisi secara otomatis berdasarkan label yang diberikan ke deployment Google Kubernetes Engine (GKE).
  
  Pada diagram sebelumnya, label "mesh-service":"true" dikonfigurasi pada kebijakan endpoint dan klien Cloud Service Mesh. Anda dapat memilih label yang sesuai dengan deployment Anda.
3. Jika ingin, tentukan TrafficPortSelector yang menerapkan kebijakan hanya saat permintaan masuk dibuat ke port yang ditentukan pada entity bidang data.

Diagram berikut menunjukkan resource Compute Engine yang Anda konfigurasikan untuk mTLS, terlepas dari apakah Anda menggunakan Envoy atau aplikasi gRPC tanpa proxy.

Diagram berikut menunjukkan alur traffic dan mencantumkan resource Compute Engine API yang Anda konfigurasi untuk mengaktifkan mTLS. Proxy file bantuan lokal yang berada bersama Pod GKE Layanan B adalah endpoint dalam komunikasi.

Resource Compute Engine API dan aliran traffic untuk mTLS dalam mesh. — Alur traffic dan resource Compute Engine API untuk mTLS dalam mesh (klik untuk memperbesar)

Kebijakan endpoint akan melakukan hal berikut:

Memilih kumpulan endpoint menggunakan pencocok endpoint dan, secara opsional, port di endpoint tersebut.
1. Dengan pencocok endpoint, Anda dapat menentukan aturan yang menentukan apakah klien Cloud Service Mesh menerima konfigurasi atau tidak. Aturan ini didasarkan pada metadata xDS yang diberikan oleh entity bidang data ke bidang kontrol—dalam hal ini, Cloud Service Mesh.
  
  Anda dapat menambahkan label ke klien Cloud Service Mesh sebagai berikut:
  - Anda dapat menentukan metadata ini secara manual dalam file bootstrap klien Cloud Service Mesh.
  - Atau, metadata dapat diisi secara otomatis saat Anda menggunakan GKE dengan menambahkan key-value pair ke bagian env dalam file demo_server.yaml atau demo_client.yaml. Nilai ini disediakan dalam panduan penyiapan Envoy dan panduan penyiapan gRPC tanpa proxy.
    
    Misalnya, hanya dengan Envoy, Anda dapat memberikan awalan pada kunci dengan awalan ISTIO_META_. Nama variabel lingkungan proxy yang diawali dengan ISTIO_META_ akan disertakan dalam bootstrap yang dihasilkan dan dikirim ke server xDS.
```
- name: ISTIO_META_app
  value: 'review'
- name: ISTIO_META_version
  value: 'canary'
```
2. Jika Anda menentukan port, kebijakan yang dirujuk dalam kebijakan endpoint hanya diterapkan pada permintaan masuk yang menentukan port yang sama. Jika Anda tidak menentukan port, kebijakan akan diterapkan pada permintaan masuk yang menentukan port yang juga ada dalam kolom TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, yang disediakan untuk klien Mesh Layanan Cloud dalam informasi bootstrap-nya.
Mereferensikan TLS klien, TLS server, dan kebijakan otorisasi yang mengonfigurasi endpoint yang diselesaikan oleh permintaan.

Mengonfigurasi mode TLS yang tidak kompatibel dapat mengakibatkan gangguan komunikasi. Misalnya, menetapkan OPEN di layanan backend global atau membiarkan kolom kebijakan TLS klien kosong, dan menetapkan MTLS sebagai nilai kebijakan TLS server di kebijakan endpoint, akan menyebabkan kegagalan upaya komunikasi. Hal ini karena endpoint yang dikonfigurasi untuk hanya menerima upaya penolakan mTLS untuk membuat saluran komunikasi yang tidak diautentikasi.

Perhatikan perbedaan antara kebijakan TLS klien dan kebijakan TLS server yang dilampirkan pada layanan backend global dan kebijakan endpoint:

Kebijakan TLS klien diterapkan ke layanan backend global. Atribut ini memberi tahu proxy Envoy atau klien tanpa proxy tentang metode TLS, identitas, dan pendekatan validasi peer yang akan digunakan saat menangani layanan.
Kebijakan TLS server dilampirkan pada kebijakan endpoint. Atribut ini memberi tahu server mode TLS, identitas, dan pendekatan validasi peer mana yang akan digunakan untuk koneksi masuk.

Mengaktifkan TLS untuk gateway masuk

Setelah menyiapkan mTLS untuk komunikasi in-mesh, sebaiknya amankan traffic yang memasuki mesh Anda, yang dikenal sebagai traffic masuk. Cloud Service Mesh dapat mengonfigurasi bidang data Anda untuk mewajibkan traffic masuk agar dapat menggunakan saluran komunikasi yang dienkripsi TLS.

Untuk mencapai tujuan ini, pilih salah satu opsi arsitektur berikut:

Layanan di mesh menghentikan TLS untuk traffic dari load balancer. Dalam model ini, setiap layanan di mesh dikonfigurasi sebagai backend dalam konfigurasi load balancer—khususnya, dalam peta URL load balancer.
Gateway masuk menghentikan TLS untuk traffic dari load balancer sebelum meneruskan traffic ke layanan di mesh. Dalam model ini, layanan khusus di mesh, gateway masuk, dikonfigurasi sebagai backend dalam konfigurasi load balancer, khususnya di peta URL load balancer.

Kedua opsi dijelaskan di bagian ini.

Layanan di mesh menghentikan TLS untuk traffic dari load balancer

Jika ingin membuat layanan Anda tersedia untuk klien di luar Google Cloud, Anda dapat menggunakan Load Balancer Aplikasi eksternal. Klien mengirim traffic ke alamat IP virtual Anycast (VIP) global load balancer, yang kemudian meneruskan traffic tersebut ke layanan di mesh Anda. Artinya, ada dua koneksi saat klien eksternal perlu menjangkau layanan di mesh.

TLS ke layanan di mesh. — TLS ke layanan di mesh (klik untuk memperbesar)

Pola yang sama berlaku saat Anda menggunakan Load Balancer Aplikasi internal. Traffic dari klien internal terlebih dahulu akan mencapai load balancer, yang kemudian akan membuat koneksi ke backend.

Untuk mengamankan kedua koneksi, lakukan hal berikut:

Amankan koneksi antara klien dan load balancer dengan menggunakan Load Balancer Aplikasi eksternal.
Konfigurasikan load balancer untuk menggunakan protokol HTTPS atau HTTP/2 saat mencoba membuat koneksi dengan layanan di mesh.
Konfigurasikan Cloud Service Mesh sehingga klien Cloud Service Mesh menghentikan HTTPS dan memberikan sertifikat ke klien, yang dalam hal ini merupakan load balancer.

Untuk mengetahui informasi selengkapnya tentang langkah 1 dan 2, lihat Menyiapkan load balancer HTTPS eksternal multi-region berbasis konten.

Saat menyiapkan keamanan Cloud Service Mesh, Anda akan mengonfigurasi berbagai resource Compute Engine API. Resource ini terpisah dari resource yang Anda konfigurasi untuk load balancer. Anda membuat kumpulan resource Compute Engine API (aturan penerusan global, proxy target, peta URL, dan layanan backend global) untuk load balancer serta mengonfigurasi Cloud Service Mesh dengan API perutean layanan. Selain itu, di resource layanan backend, load balancer memiliki skema load balancing INTERNAL_MANAGED dan Cloud Service Mesh memiliki skema load balancing INTERNAL_SELF_MANAGED.

Pada langkah 3, Anda akan mengonfigurasi Cloud Service Mesh sehingga klien Mesh Layanan Cloud Anda menghentikan HTTPS dan memberikan sertifikat ke klien.

Resource Compute Engine API untuk TLS untuk layanan di mesh. — Resource Compute Engine API untuk TLS untuk layanan di mesh (klik untuk memperbesar)

Pada model ini, Anda melakukan hal berikut:

Buat serverTlsPolicy: konfigurasikan serverCertificate pada resource serverTlsPolicy.
Buat kebijakan endpoint:
1. Lihat kebijakan TLS server di kolom authentication.
2. Tentukan EndpointMatcher untuk memilih entity bidang data xDS yang harus menerapkan autentikasi pada traffic masuk.
3. Secara opsional, tentukan TrafficPortSelector yang menerapkan kebijakan hanya saat permintaan masuk dibuat ke port tertentu pada klien Mesh Layanan Cloud.

Karena Load Balancer Aplikasi eksternal sudah dikonfigurasi untuk memulai koneksi TLS ke layanan di mesh Anda, Cloud Service Mesh hanya perlu mengonfigurasi klien Cloud Service Mesh untuk menghentikan koneksi TLS.

Gateway masuk menghentikan TLS untuk traffic dari load balancer sebelum meneruskan traffic ke layanan di mesh

Jika hanya ingin mengekspos gateway masuk ke load balancer, Anda dapat menggunakan pola deployment gateway masuk. Dalam pola ini, load balancer tidak secara langsung menangani layanan di mesh Anda. Sebagai gantinya, proxy tengah berada di tepi mesh dan mengarahkan traffic ke layanan di dalam mesh, berdasarkan konfigurasi yang diterima dari Cloud Service Mesh. Proxy tengah dapat berupa proxy Envoy yang Anda deploy pada instance virtual machine (VM) dalam grup instance yang dikelola Compute Engine.

TLS ke gateway masuk dengan mTLS di dalam mesh. — TLS ke gateway masuk dengan mTLS dalam mesh (klik untuk memperbesar)

Dari sudut pandang keamanan, Anda mengonfigurasi gateway masuk untuk menghentikan TLS, lalu mengonfigurasi koneksi dalam mesh secara opsional agar dilindungi oleh mTLS. Hal ini mencakup koneksi antara gateway ingress dan layanan in-mesh Anda, serta koneksi antara layanan in-mesh Anda.

Dari perspektif konfigurasi, Anda dapat melakukan hal berikut:

Konfigurasi mesh layanan Anda dan aktifkan mTLS untuk komunikasi dalam mesh (seperti yang dijelaskan sebelumnya).
Konfigurasikan load balancer Anda untuk merutekan traffic ke gateway masuk dan memulai koneksi menggunakan protokol HTTPS (seperti yang dijelaskan sebelumnya).
Buat kumpulan resource Compute Engine API yang merepresentasikan gateway masuk dan kebijakan TLS servernya.

Untuk langkah ketiga, konfigurasikan Cloud Service Mesh untuk menghentikan HTTPS dan menyajikan sertifikat sebagai berikut:

Buat resource Mesh untuk mewakili mesh.
Buat resource Route yang mengarah ke layanan backend global yang benar dan lampirkan resource Route ke resource Mesh.
Buat kebijakan TLS server: konfigurasikan serverCertificate.
Buat resource Gateway untuk mewakili gateway ingress yang dikelola Cloud Service Mesh.
Lampirkan resource kebijakan TLS server ke resource Gateway.

Pola gateway masuk sangat berguna dalam organisasi besar yang menggunakan VPC Bersama. Dalam setelan seperti itu, tim mungkin hanya mengizinkan akses ke layanannya melalui gateway masuk. Dalam diagram sebelumnya, saat Anda mengonfigurasi aturan penerusan global untuk load balancer, Anda memberikan alamat IP yang berbeda (dalam contoh ini, 10.0.0.2) daripada yang disediakan saat Anda mengonfigurasi mesh (dalam contoh ini, alamat mesh adalah 10.0.0.1). Klien yang berkomunikasi melalui entity pesawat data xDS yang dikonfigurasi Cloud Service Mesh dapat menggunakan alamat ini untuk mengakses gateway ingress.

Sebagai contoh, asumsikan beberapa hal berikut:

Dua project layanan (1 dan 2), keduanya dipasang ke jaringan VPC Bersama yang sama.
Project layanan 1 berisi mesh layanan yang dikonfigurasi oleh Cloud Service Mesh.

Project layanan 1 telah mengonfigurasi mesh dan gateway masuk. Gateway masuk ini dapat dijangkau di alamat/VIP 10.0.0.2.
Project layanan 2 berisi mesh layanan yang dikonfigurasi oleh Cloud Service Mesh.

Project layanan 2 mungkin memiliki atau tidak memiliki gateway masuknya sendiri.
Cloud Service Mesh mengonfigurasi klien Cloud Service Mesh di setiap project layanan. Klien di-bootstrap untuk menggunakan jaringan yang sama.

Dengan konfigurasi ini, klien dalam mesh project layanan 2 dapat berkomunikasi dengan gateway masuk dalam project layanan 1 menggunakan VIP 10.0.0.2. Hal ini memungkinkan pemilik project layanan 1 mengonfigurasi perutean, keamanan, dan kebijakan lain yang khusus untuk traffic yang memasuki mesh. Akibatnya, pemilik project layanan 1 dapat memberi tahu orang lain bahwa klien di mesh Anda dapat menjangkau layanan saya di 10.0.0.2.

Batasan

Keamanan layanan Cloud Service Mesh hanya didukung dengan GKE. Anda tidak dapat men-deploy keamanan layanan dengan Compute Engine.

Langkah selanjutnya

Untuk mengonfigurasi keamanan layanan Cloud Service Mesh dengan proxy Envoy, lihat artikel Menyiapkan keamanan layanan Cloud Service Mesh dengan Envoy.
Untuk mengonfigurasi keamanan layanan Cloud Service Mesh dengan aplikasi gRPC tanpa proxy, lihat Menyiapkan keamanan layanan Cloud Service Mesh dengan gRPC tanpa proxy.