Kasus penggunaan keamanan layanan
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.
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.
Bagian berikut menghilangkan diskusi tentang Mesh
, Gateway
, dan Route
Google Cloud Platform. Resource API ini diperlukan untuk membuat mesh dan rute Anda
lalu lintas data, namun 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.
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:
- Rujuk kebijakan TLS server di kolom
server_tls_policy
. 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.(Opsional) Tentukan
TrafficPortSelector
yang hanya menerapkan kebijakan saat permintaan masuk dilakukan ke port yang ditentukan pada bidang data entitas.
- Rujuk kebijakan TLS server di kolom
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.
Kebijakan endpoint akan melakukan hal berikut:
Memilih kumpulan endpoint menggunakan pencocok endpoint dan, jika perlu, port tertentu di endpoint tersebut.
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
daridemo_server.yaml
ataudemo_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 denganISTIO_META_
disertakan dalam bootstrap yang dihasilkan dan dikirim ke server xDS.- name: ISTIO_META_app value: 'review' - name: ISTIO_META_version value: 'canary'
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.
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. Anda membuat serangkaian
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 backend
resource layanan, 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 Cloud Service Mesh Anda menghentikan HTTPS dan memberikan sertifikat ke klien.
Dalam model ini, Anda melakukan hal berikut:
- Membuat
serverTlsPolicy
: konfigurasikanserverCertificate
di resourceserverTlsPolicy
. - Buat kebijakan endpoint:
- Rujuk kebijakan TLS server di kolom
authentication
. - Tentukan
EndpointMatcher
untuk memilih bidang data xDS entitas yang harus menerapkan otentikasi pada lalu lintas masuk. - Secara opsional, tentukan
TrafficPortSelector
yang menerapkan kebijakan hanya saat permintaan masuk dilakukan ke port yang ditentukan pada klien Cloud Service Mesh.
- Rujuk kebijakan TLS server di kolom
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.
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:
Buat resource
Mesh
untuk mewakili mesh.Buat resource
Route
yang mengarah ke backend global yang benar dan melampirkan resourceRoute
ke resourceMesh
.Buat kebijakan TLS server: konfigurasikan
serverCertificate
.Buat resource
Gateway
untuk mewakili Cloud Service Mesh yang dikelola traffic masuk.Lampirkan resource kebijakan TLS server ke resource
Gateway
.
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
berikut ini, saat Anda mengonfigurasi aturan penerusan global untuk load balancer,
Anda memberikan alamat IP yang berbeda (dalam contoh ini, 10.0.0.2
) dengan yang
disediakan saat Anda mengonfigurasi {i>mesh<i} (dalam contoh ini, alamat {i>mesh<i} adalah
10.0.0.1
). Klien yang berkomunikasi melalui xDS Cloud Service Mesh yang dikonfigurasi
entity bidang data 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.
- Untuk mengonfigurasi keamanan layanan Cloud Service Mesh dengan aplikasi gRPC tanpa proxy, lihat Menyiapkan keamanan layanan Cloud Service Mesh dengan gRPC tanpa proxy.