Cloud Service Mesh dan Traffic Director kini bergabung menjadi Cloud Service Mesh. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

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 mana yang paling sesuai dengan kebutuhan Anda. Dokumen ini juga memberikan ringkasan umum tentang hal-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

Di mesh layanan, Anda dapat mengaktifkan TLS timbal balik (mTLS) sehingga klien dan server dalam komunikasi harus membuktikan identitasnya dan mengenkripsi komunikasi.

Autentikasi TLS bersama (mTLS) di service mesh. — 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 memperbaruinya 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 keamanan lapisan transport (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. Referensi kebijakan TLS server di kolom server_tls_policy.
2. Tentukan EndpointMatcher untuk memilih klien Cloud Service Mesh 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) Anda.
  
  Dalam 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 dibuat ke port tertentu pada entitas bidang data.

Diagram berikut menunjukkan resource Compute Engine yang Anda konfigurasi 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 Service 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 sekumpulan 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 entitas 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 otomatis saat Anda menggunakan GKE dengan menambahkan pasangan kunci-nilai 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, dengan Envoy saja, Anda dapat menambahkan awalan ISTIO_META_ ke kunci. 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 diberikan ke klien Cloud Service Mesh dalam informasi bootstrap-nya.
Mereferensikan TLS klien, TLS server, dan kebijakan otorisasi yang mengonfigurasi endpoint yang dituju permintaan.

Mengonfigurasi mode TLS yang tidak kompatibel dapat menyebabkan gangguan komunikasi. Misalnya, menyetel OPEN pada layanan backend global atau mengosongkan kolom kebijakan TLS klien, dan menyetel MTLS sebagai nilai kebijakan TLS server pada kebijakan endpoint, akan menyebabkan 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 kebijakan endpoint dan layanan backend global:

Kebijakan TLS klien diterapkan ke layanan backend global. Objek ini memberi tahu proxy Envoy atau klien tanpa proxy mode TLS, identitas, dan pendekatan validasi peer yang akan digunakan saat mengakses layanan.
Kebijakan TLS server dilampirkan ke kebijakan endpoint. Setelan 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 Anda, yang dikenal sebagai traffic ingress. Cloud Service Mesh dapat mengonfigurasi bidang data Anda agar mengharuskan traffic ingress untuk 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 ingress 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 membuat layanan Anda tersedia bagi klien di luar Google Cloud, Anda dapat menggunakan Load Balancer Aplikasi eksternal. Klien mengirim traffic ke alamat IP virtual (VIP) Anycast 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 dalam mesh (klik untuk memperbesar)

Pola yang sama berlaku saat Anda menggunakan Load Balancer Aplikasi internal. Traffic dari klien internal pertama-tama 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.
Konfigurasi load balancer untuk menggunakan protokol HTTPS atau HTTP/2 saat mencoba membuat koneksi dengan layanan di mesh.
Konfigurasi Cloud Service Mesh agar klien Cloud Service Mesh Anda menghentikan HTTPS dan menampilkan sertifikat kepada klien, yang dalam hal ini adalah 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 mengonfigurasi berbagai resource Compute Engine API. Resource ini terpisah dari resource yang Anda konfigurasi untuk load balancer. Anda membuat serangkaian 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 menghentikan HTTPS dan menampilkan sertifikat kepada klien.

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

Dalam model ini, Anda akan melakukan hal berikut:

Buat serverTlsPolicy: konfigurasi serverCertificate di resource serverTlsPolicy.
Buat kebijakan endpoint:
1. Referensi 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 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 Anda untuk menghentikan koneksi TLS.

Gateway ingress 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 edge mesh Anda dan merutekan traffic ke layanan di dalam mesh, berdasarkan konfigurasi yang diterimanya 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 agar dilindungi oleh mTLS. Hal ini mencakup koneksi antara gateway ingress dan layanan dalam mesh Anda, serta koneksi di antara layanan dalam mesh Anda.

Dari perspektif konfigurasi, Anda melakukan hal berikut:

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

Untuk langkah ketiga, konfigurasi 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: konfigurasi serverCertificate.
Buat resource Gateway untuk merepresentasikan gateway ingress yang dikelola Cloud Service Mesh.
Lampirkan resource kebijakan TLS server ke resource Gateway.

Pola gateway ingress sangat berguna dalam organisasi besar yang menggunakan VPC Bersama. Dalam setelan seperti itu, tim mungkin hanya mengizinkan akses ke layanannya melalui gateway ingress. Dalam diagram sebelumnya, saat mengonfigurasi aturan penerusan global untuk load balancer, Anda memberikan alamat IP yang berbeda (dalam contoh ini, 10.0.0.2) dengan alamat IP yang diberikan saat mengonfigurasi mesh (dalam contoh ini, alamat mesh adalah 10.0.0.1). Klien yang berkomunikasi melalui entity 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 10.0.0.2 VIP. Hal ini memungkinkan pemilik project layanan 1 mengonfigurasi perutean, keamanan, dan kebijakan lain yang khusus untuk traffic yang masuk ke 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 berikutnya

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.