Kasus penggunaan keamanan layanan

Dokumen ini menjelaskan kasus penggunaan keamanan Traffic Director yang umum. Gunakan informasi ini untuk membantu Anda menentukan model keamanan yang paling sesuai dengan kebutuhan Anda. Dokumen ini juga memberikan ringkasan tingkat tinggi tentang apa yang perlu Anda konfigurasi untuk setiap kasus penggunaan.

Untuk ringkasan keamanan layanan, lihat Keamanan layanan Traffic Director.

Mengaktifkan TLS bersama untuk layanan di mesh

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

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

Bagian berikut tidak membahas aturan penerusan global, proxy HTTPS target, dan peta URL. Resource Compute Engine API ini diperlukan untuk membuat mesh, 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 ke kebijakan TLS klien yang baru.
Buat kebijakan endpoint:
1. Lihat kebijakan TLS server di kolom server_tls_policy.
2. Tentukan EndpointMatcher untuk memilih klien Traffic Director yang harus menerapkan autentikasi pada traffic masuk.
  
  Memilih klien Traffic Director didasarkan pada label yang ditentukan dalam konfigurasi bootstrap klien Traffic Director. Label ini dapat diberikan secara manual atau diisi secara otomatis berdasarkan label yang disediakan ke deployment Google Kubernetes Engine (GKE) Anda.
  
  Pada diagram sebelumnya, label "mesh-service":"true" dikonfigurasi berdasarkan kebijakan endpoint dan klien Traffic Director. Anda dapat memilih label yang sesuai dengan deployment.
3. Secara opsional, 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 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 file bantuan lokal yang berada bersama Pod GKE Layanan B adalah endpoint dalam komunikasi.

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

Kebijakan endpoint akan melakukan hal berikut:

Memilih kumpulan endpoint menggunakan matcher endpoint dan, secara opsional, port pada endpoint tersebut.
1. Pencocok endpoint memungkinkan Anda menentukan aturan yang menentukan apakah klien Traffic Director menerima konfigurasi atau tidak. Aturan ini didasarkan pada metadata xDS yang diberikan entity bidang data ke bidang kontrol—dalam hal ini, Traffic Director.
  
  Anda dapat menambahkan label ke klien Traffic Director sebagai berikut:
  - Anda dapat menentukan metadata ini secara manual dalam file bootstrap klien Traffic Director.
  - Atau, metadata dapat diisi secara otomatis saat Anda menggunakan GKE dengan menambahkan key-value pair ke bagian env dari 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 memberi 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 di kolom TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, yang disediakan untuk klien Traffic Director dalam informasi bootstrap-nya.
Mereferensikan TLS klien, TLS server, dan kebijakan otorisasi yang mengonfigurasi endpoint tempat permintaan diselesaikan.

Mengonfigurasi mode TLS yang tidak kompatibel dapat mengakibatkan gangguan komunikasi. Misalnya, menyetel OPEN pada layanan backend global atau membiarkan kolom kebijakan TLS klien kosong, dan menetapkan MTLS sebagai nilai kebijakan TLS server pada kebijakan endpoint akan menyebabkan upaya komunikasi yang gagal. 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 ditambahkan ke 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 mode TLS, identitas, dan pendekatan validasi rekan yang akan digunakan saat menangani layanan.
Kebijakan TLS server dilampirkan pada kebijakan endpoint. Atribut ini memberi tahu server mode TLS, identitas, dan pendekatan validasi pembanding yang akan digunakan untuk koneksi masuk.

Mengaktifkan TLS untuk ingress gateway

Setelah menyiapkan mTLS untuk komunikasi dalam mesh, Anda mungkin ingin mengamankan traffic yang memasuki mesh Anda, yang dikenal sebagai traffic masuk. Traffic Director dapat mengonfigurasi bidang data Anda agar 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 balancing—khususnya, di 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 dalam mesh, gateway masuk, dikonfigurasi sebagai backend dalam konfigurasi load balancer—khususnya, di 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 untuk klien di luar Google Cloud, Anda dapat menggunakan Load Balancer Aplikasi eksternal. Klien mengirim traffic ke alamat IP virtual Anycast global (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 mencapai load balancer, yang kemudian 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 ketika mencoba membuat koneksi dengan layanan di mesh.
Konfigurasikan Traffic Director sehingga klien Traffic Director menghentikan HTTPS dan memberikan sertifikat ke klien, yang dalam hal ini adalah load balancer.

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

Saat menyiapkan keamanan Traffic Director, Anda akan mengonfigurasi berbagai resource Compute Engine API. Resource ini terpisah dari resource yang Anda konfigurasikan untuk load balancer. Dengan kata lain, Anda membuat dua kumpulan resource Compute Engine API (aturan penerusan global, proxy target, peta URL, dan layanan backend global) dengan skema load balancing yang berbeda:

Satu kumpulan resource mengonfigurasi load balancer Anda, yang memiliki skema load balancing INTERNAL_MANAGED.
Kumpulan resource lainnya akan mengonfigurasi Traffic Director, yang memiliki skema load balancing INTERNAL_SELF_MANAGED.

Pada langkah 3, Anda mengonfigurasi Traffic Director sehingga klien Traffic Director menghentikan HTTPS dan memberikan sertifikat kepada klien.

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

Dalam model ini, Anda melakukan hal berikut:

Buat kebijakan TLS server: konfigurasikan terminationTls di transportAuthentication.
Buat kebijakan endpoint:
1. Lihat 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 dibuat ke port yang ditentukan pada klien Traffic Director.

Karena Load Balancer Aplikasi eksternal sudah dikonfigurasi untuk memulai koneksi TLS ke layanan di mesh Anda, Traffic Director hanya perlu mengonfigurasi klien Traffic Director 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 tepi mesh dan mengarahkan traffic ke layanan di dalam mesh, berdasarkan konfigurasi yang diterima dari Traffic Director. 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 di dalam mesh. — TLS ke gateway masuk dengan mTLS dalam mesh (klik untuk memperbesar)

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

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 mewakili gateway masuk dan kebijakan TLS servernya.

Untuk langkah ketiga, konfigurasikan Traffic Director untuk menghentikan HTTPS dan menyajikan sertifikat sebagai berikut:

Buat aturan penerusan global dan proxy HTTPS target untuk menunjukkan jalur traffic masuk ke mesh Anda.
Lampirkan peta URL yang ada untuk mesh Anda ke proxy HTTPS target ini. Peta URL sudah berisi referensi ke berbagai layanan backend global mesh Anda, berdasarkan konfigurasi yang diberikan saat Anda mengonfigurasi mesh dan mTLS.
Buat kebijakan TLS server: konfigurasikan serverCertificate.
Lampirkan resource kebijakan TLS server ke proxy HTTPS target Anda.

Pola gateway masuk sangat berguna dalam organisasi besar yang menggunakan VPC Bersama. Dalam pengaturan seperti itu, tim mungkin hanya mengizinkan akses ke layanannya melalui gateway masuk. Dalam diagram sebelumnya, saat mengonfigurasi aturan penerusan global, Anda memberikan alamat IP yang berbeda (dalam contoh ini, 10.0.0.2) dibandingkan dengan yang diberikan saat Anda mengonfigurasi mesh (dalam contoh ini, alamat mesh adalah 10.0.0.1). Klien yang berkomunikasi melalui entity bidang data xDS yang dikonfigurasi Traffic Director dapat menggunakan alamat ini untuk mengakses gateway masuk.

Sebagai contoh, asumsikan beberapa hal berikut:

Dua project layanan (1 dan 2), keduanya terhubung ke jaringan VPC Bersama yang sama.
Project layanan 1 berisi mesh layanan yang dikonfigurasi oleh Traffic Director.

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 Traffic Director.

Project layanan 2 mungkin memiliki atau tidak memiliki gateway masuknya sendiri.
Traffic Director mengonfigurasi klien Traffic Director 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 ingress di project layanan 1 menggunakan VIP 10.0.0.2. Hal ini memungkinkan pemilik project layanan 1 untuk mengonfigurasi perutean, keamanan, dan kebijakan lain yang spesifik untuk traffic yang memasuki mesh. Dengan demikian, 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 Traffic Director hanya didukung dengan GKE. Anda tidak dapat men-deploy keamanan layanan dengan Compute Engine.

Langkah selanjutnya

Untuk mengonfigurasi keamanan layanan Traffic Director dengan proxy Envoy, lihat Menyiapkan keamanan layanan Traffic Director dengan Envoy.
Untuk mengonfigurasi keamanan layanan Traffic Director dengan aplikasi gRPC tanpa proxy, lihat Menyiapkan keamanan layanan Traffic Director dengan gRPC tanpa proxy.