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 (lama)

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

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

Dokumen ini berlaku untuk konfigurasi yang menggunakan API load balancing. Ini adalah dokumen lama.

Mengaktifkan TLS bersama untuk layanan di mesh

Di {i>mesh<i} layanan, Anda dapat mengaktifkan TLS bersama (mTLS) sehingga klien dan server dalam komunikasi harus membuktikan identitas dan mengenkripsi komunikasi Anda.

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

Bagian berikut ini menghilangkan diskusi aturan penerusan global, target Proxy HTTPS, dan peta URL. Resource Compute Engine API ini diperlukan untuk membuat {i>mesh<i}, tetapi Anda tidak perlu memperbaruinya untuk mengaktifkan mTLS.

Pola sebelumnya dapat dicapai dengan mengonfigurasi hal-hal berikut ke resource Compute Engine API. Diagram ini menggunakan proxy file bantuan, 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 client transport layer security (TLS).
Buat kebijakan TLS server.
Memperbarui kolom securitySettings di layanan backend global yang ada untuk merujuk ke kebijakan TLS klien baru.
Buat kebijakan endpoint:
1. Rujuk kebijakan TLS server di kolom server_tls_policy.
2. Tentukan EndpointMatcher untuk memilih klien Cloud Service Mesh yang harus memberlakukan otentikasi pada lalu lintas 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 otomatis berdasarkan label yang dipasok ke deployment Google Kubernetes Engine (GKE).
  
  Pada diagram sebelumnya, label "mesh-service":"true" adalah dikonfigurasi pada kebijakan endpoint dan klien Cloud Service Mesh. Anda dapat memilih label yang sesuai dengan deployment Anda.
3. (Opsional) Tentukan TrafficPortSelector yang hanya menerapkan kebijakan saat permintaan masuk dilakukan ke port yang ditentukan pada bidang data entitas.

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

Diagram berikut menunjukkan alur traffic dan daftar Compute Engine API yang Anda konfigurasi untuk mengaktifkan mTLS. Proxy file bantuan lokal yang ada bersama Pod GKE Service B adalah endpoint di komunikasi antarlayanan.

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

Kebijakan endpoint akan melakukan hal berikut:

Memilih kumpulan endpoint menggunakan pencocok endpoint dan, jika perlu, port tertentu di endpoint tersebut.
1. Pencocok endpoint memungkinkan Anda menentukan aturan yang menentukan apakah klien Cloud Service Mesh akan menerima konfigurasi. Aturan ini didasarkan pada metadata xDS yang yang disediakan entitas bidang kontrol ke bidang kontrol. dan 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.
  - {i>Metadata<i} dapat terisi secara otomatis ketika Anda menggunakan GKE dengan menambahkan key-value pair ke Bagian env dari demo_server.yaml atau demo_client.yaml . Nilai ini disediakan dalam Panduan penyiapan Envoy dan panduan penyiapan gRPC tanpa proxy.
    
    Misalnya, dengan Envoy saja, Anda dapat memberikan awalan pada kunci dengan awalan Awalan ISTIO_META_. Nama-nama variabel lingkungan {i>proxy<i} yang mulai 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 diberlakukan pada permintaan masuk yang menentukan porta yang juga berada 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 yang disetujui oleh permintaan.

Mengonfigurasi mode TLS yang tidak kompatibel dapat mengakibatkan gangguan pada komunikasi Anda. 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, mengakibatkan kegagalan komunikasi percobaan. Hal ini karena endpoint yang dikonfigurasi agar 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. Ini memberi tahu {i>proxy<i} Envoy atau klien tanpa {i>proxy<i} yang mana mode TLS, identitas, dan validasi data untuk digunakan saat menangani layanan.
Kebijakan TLS server dilampirkan ke kebijakan endpoint. Ini memberi tahu mode TLS, identitas, dan pendekatan validasi sejawat yang akan digunakan untuk koneksi masuk.

Mengaktifkan TLS untuk gateway masuk

Setelah menyiapkan mTLS untuk komunikasi {i>in-mesh<i}, Anda dapat traffic aman yang memasuki mesh Anda, yang dikenal sebagai traffic masuk. Cloud Service Mesh dapat mengonfigurasi bidang data Anda untuk mewajibkan traffic masuk menggunakan saluran komunikasi TLS yang terenkripsi.

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

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

Kedua opsi tersebut dijelaskan di bagian ini.

Layanan di mesh menghentikan TLS untuk traffic dari load balancer

Jika Anda ingin menyediakan layanan Anda untuk 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 terdapat dua koneksi ketika klien eksternal perlu menjangkau layanan di jala tersebut.

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

Pola yang sama berlaku bila 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 langkah 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 model ini mencoba menghubungkan dengan layanan di mesh.
Mengonfigurasi Cloud Service Mesh agar klien Cloud Service Mesh Anda menghentikan HTTPS dan memberikan sertifikat ke klien, yang dalam kasus ini adalah dengan load balancer Jaringan Passthrough Eksternal Regional.

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

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

Satu set resource mengonfigurasi load balancer Anda, yang memiliki skema load balancing INTERNAL_MANAGED.
Kumpulan resource lainnya mengonfigurasi Cloud Service Mesh, yang memiliki skema load balancing INTERNAL_SELF_MANAGED.

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

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

Dalam model ini, Anda melakukan hal berikut:

Buat kebijakan TLS server: konfigurasikan terminationTls di transportAuthentication.
Buat kebijakan endpoint:
1. Rujuk kebijakan TLS server di kolom authentication.
2. Tentukan EndpointMatcher untuk memilih bidang data xDS entitas yang harus menerapkan otentikasi pada lalu lintas masuk.
3. Secara opsional, tentukan TrafficPortSelector yang menerapkan kebijakan hanya saat permintaan masuk dilakukan ke port yang ditentukan pada 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 dan 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 Anda 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. Sebaliknya, {i>proxy<i} tengah berada di tepi mesh Anda dan mengarahkan traffic ke layanan di dalam mesh, berdasarkan pada konfigurasi yang diterimanya dari Cloud Service Mesh. Proxy tengah dapat berupa proxy Envoy yang Anda deploy pada instance virtual machine (VM) di Grup instance terkelola Compute Engine.

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

Dari perspektif keamanan, Anda mengonfigurasi gateway masuk untuk menghentikan TLS, dan kemudian secara opsional mengkonfigurasi koneksi dalam {i>mesh<i} Anda sehingga mereka dilindungi oleh mTLS. Termasuk koneksi antara gateway masuk dan layanan {i>in-mesh<i}, dan koneksi di antara layanan dalam {i>in-mesh<i} Anda.

Dari perspektif konfigurasi, Anda melakukan hal berikut:

Mengonfigurasi mesh layanan dan mengaktifkan mTLS untuk komunikasi di dalam jaring (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 traffic masuk dan kebijakan TLS server-nya.

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

Membuat aturan penerusan global dan proxy HTTPS target untuk mewakili jalur untuk traffic masuk ke mesh Anda.
Lampirkan peta URL yang ada untuk mesh Anda ke target ini Proxy HTTPS. Peta URL sudah berisi referensi ke berbagai layanan backend global mesh, berdasarkan yang disediakan 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 pada organisasi besar yang menggunakan VPC Bersama. Dalam pengaturan seperti itu, sebuah tim mungkin hanya memungkinkan akses ke layanannya melalui gateway masuknya. Dalam contoh saat mengonfigurasi aturan penerusan global, Anda menyediakan berbeda (dalam contoh ini, 10.0.0.2) dengan yang diberikan saat Anda mengonfigurasi mesh (dalam contoh ini, alamat mesh-nya adalah 10.0.0.1). Klien yang berkomunikasi melalui bidang data xDS yang dikonfigurasi Cloud Service Mesh entity dapat menggunakan alamat ini untuk mengakses gateway masuk.

Sebagai contoh, asumsikan hal berikut:

Dua project layanan (1 dan 2), keduanya dilampirkan ke VPC Bersama yang sama jaringan.
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 10.0.0.2 (VIP).
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 layanan proyek. Klien di-bootstrap untuk menggunakan jaringan yang sama.

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

Batasan

Keamanan layanan Cloud Service Mesh hanya didukung dengan hanya pada container yang tepercaya. 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 (lama).
Untuk mengonfigurasi keamanan layanan Cloud Service Mesh dengan aplikasi gRPC tanpa proxy, lihat Menyiapkan keamanan layanan Cloud Service Mesh dengan gRPC tanpa proxy (lama).