Anda sedang melihat dokumentasi Service Mesh v1.22.

Versi yang tersedia

Cloud Service Mesh
arsip 1.22
arsip 1.21
arsip 1.20
arsip 1.19
arsip 1.18

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 Anda menentukan model keamanan yang paling sesuai dengan kebutuhan Anda. Dokumen ini juga memberikan ringkasan umum tentang hal yang perlu Anda konfigurasikan untuk setiap kasus penggunaan.

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

Mengaktifkan TLS bersama untuk layanan di mesh

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

Autentikasi TLS bersama (mTLS) di mesh layanan. — Autentikasi TLS bersama (mTLS) di mesh layanan (klik untuk memperbesar)

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

Pola sebelumnya dapat dicapai dengan mengonfigurasi resource Compute Engine API berikut. Diagram ini menggunakan proxy sidecar, tetapi mengonfigurasi aplikasi gRPC tanpa proxy dengan mTLS 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 transport layer security (TLS) klien.
Buat kebijakan TLS server.
Perbarui kolom securitySettings di layanan backend global yang ada untuk mereferensikan kebijakan TLS klien baru.
Buat kebijakan endpoint:
1. Referensikan kebijakan TLS server di kolom server_tls_policy.
2. Tentukan EndpointMatcher untuk memilih klien Cloud Service Mesh yang harus menerapkan autentikasi pada traffic masuk.
  
  Memilih 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) Anda.
  
  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. Secara opsional, tentukan TrafficPortSelector yang menerapkan kebijakan hanya saat permintaan masuk dilakukan ke port yang ditentukan pada entitas data plane.

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 sidecar lokal yang berada di samping Pod GKE Layanan B adalah endpoint dalam komunikasi.

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

Kebijakan endpoint melakukan hal berikut:

Memilih kumpulan endpoint menggunakan pencocok endpoint dan, secara opsional, port di endpoint tersebut.
1. Pencocok endpoint memungkinkan Anda menentukan aturan yang menentukan apakah klien Cloud Service Mesh menerima konfigurasi. Aturan ini didasarkan pada metadata xDS yang disediakan 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 di file bootstrap klien Cloud Service Mesh.
  - Atau, metadata dapat diisi secara otomatis saat Anda menggunakan GKE dengan menambahkan pasangan nilai kunci ke bagian env dari file demo_server.yaml atau demo_client.yaml. Nilai ini diberikan dalam panduan penyiapan Envoy dan panduan penyiapan gRPC tanpa proxy.
    
    Misalnya, hanya dengan Envoy, Anda dapat menambahkan awalan kunci dengan awalan ISTIO_META_. Nama variabel lingkungan proxy yang dimulai dengan ISTIO_META_ 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 di kolom TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, yang disediakan ke klien Cloud Service Mesh dalam informasi bootstrap-nya.
Mereferensikan TLS klien, TLS server, dan kebijakan otorisasi yang mengonfigurasi endpoint tempat permintaan di-resolve.

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

Perhatikan perbedaan antara kebijakan TLS klien dan kebijakan TLS server yang masing-masing dilampirkan ke layanan backend global dan kebijakan endpoint:

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

Mengaktifkan TLS untuk gateway traffic masuk

Setelah menyiapkan mTLS untuk komunikasi dalam mesh, Anda mungkin ingin mengamankan traffic yang masuk ke mesh, yang dikenal sebagai traffic masuk. Cloud Service Mesh dapat mengonfigurasi bidang data Anda agar mewajibkan traffic masuk untuk menggunakan saluran komunikasi terenkripsi TLS.

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

Layanan dalam mesh menghentikan TLS untuk traffic dari load balancer. Dalam model ini, setiap layanan dalam 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 ingress, dikonfigurasi sebagai backend dalam konfigurasi load balancer—khususnya, dalam peta URL load balancer.

Kedua opsi tersebut dijelaskan di bagian ini.

Layanan di mesh menghentikan TLS untuk traffic dari load balancer

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

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

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

Untuk mengamankan kedua koneksi, lakukan hal berikut:

Amankan koneksi antara klien dan load balancer menggunakan Load Balancer Aplikasi eksternal.
Konfigurasikan load balancer agar menggunakan protokol HTTPS atau HTTP/2 saat mencoba membangun koneksi dengan layanan di mesh.
Konfigurasikan Cloud Service Mesh agar klien Cloud Service Mesh Anda menghentikan HTTPS dan menampilkan sertifikat ke klien, yang dalam hal ini adalah load balancer.

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

Saat menyiapkan keamanan Cloud Service Mesh, Anda mengonfigurasi berbagai resource Compute Engine API. Resource ini terpisah dari resource yang Anda konfigurasikan untuk load balancer. Anda membuat kumpulan resource Compute Engine API (aturan penerusan global, proxy target, peta URL, dan layanan backend global) untuk load balancer dan 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 mengonfigurasi Cloud Service Mesh sehingga klien Cloud Service Mesh Anda menghentikan HTTPS dan menampilkan sertifikat kepada klien.

Resource Compute Engine API untuk TLS ke layanan dalam mesh. — Referensi Compute Engine API untuk TLS ke layanan dalam mesh (klik untuk memperbesar)

Dalam model ini, Anda akan melakukan hal berikut:

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

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 langsung menangani layanan di mesh Anda. Sebagai gantinya, proxy tengah berada di tepi mesh dan merutekan 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 terkelola Compute Engine.

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

Dari perspektif keamanan, Anda mengonfigurasi gateway masuk untuk menghentikan TLS, lalu secara opsional mengonfigurasi koneksi dalam mesh sehingga dilindungi oleh mTLS. Hal ini mencakup koneksi antara gateway masuk dan layanan dalam mesh Anda, serta koneksi di antara layanan dalam mesh Anda.

Dari perspektif konfigurasi, Anda melakukan hal berikut:

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

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

Buat resource Mesh untuk merepresentasikan 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 merepresentasikan gateway masuk yang dikelola Cloud Service Mesh.
Lampirkan resource kebijakan TLS server ke resource Gateway.

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

Sebagai contoh, asumsikan hal berikut:

Dua project layanan (1 dan 2), keduanya dilampirkan 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 ingress 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 ingress 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 di mesh project layanan 2 dapat berkomunikasi dengan gateway ingress di project layanan 1 menggunakan VIP 10.0.0.2. Hal ini memungkinkan pemilik project layanan 1 mengonfigurasi perutean, keamanan, dan kebijakan lainnya 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 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.