Anda sedang melihat dokumentasi Service Mesh v1.20 lama.

Versi yang tersedia

Cloud Service Mesh
Arsip 1.20
arsip 1.19
Arsip 1.18

Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan keamanan Cloud Service Mesh

Keamanan Cloud Service Mesh membantu Anda memitigasi ancaman orang dalam dan mengurangi risiko pelanggaran data dengan memastikan bahwa semua komunikasi antara workload dienkripsi, diotentikasi bersama, dan diotorisasi.

Secara tradisional, segmentasi mikro yang menggunakan aturan berbasis IP telah digunakan untuk memitigasi risiko pihak internal. Namun, adopsi container, layanan bersama, dan lingkungan produksi terdistribusi yang tersebar di banyak {i>cloud<i} membuat lebih sulit untuk dikonfigurasi dan bahkan lebih sulit untuk dikelola.

Dengan Cloud Service Mesh, Anda dapat mengonfigurasi lapisan layanan kontekstual dan meminta keamanan jaringan kontekstual yang terlepas dari keamanan tersebut dari jaringan yang mendasarinya. Karena itu, Cloud Service Mesh memungkinkan Anda mengadopsi postur defense in depth yang konsisten dengan keamanan Zero-Trust prinsip AI. Anda dapat melakukannya melalui kebijakan deklaratif dan tanpa memodifikasi kode aplikasi apa pun.

TLS bersama

Cloud Service Mesh menggunakan TLS bersama (mTLS) untuk autentikasi peer. {i>Authentication<i} (Otentikasi) mengacu pada identitas: siapa layanan ini? siapakah pengguna akhir ini? dan dapatkah saya memercayai bahwa mereka adalah orang yang mereka katakan?

mTLS memungkinkan beban kerja untuk memverifikasi identitas dan mengotentikasi satu sama lain. Anda mungkin telah terbiasa dengan TLS sederhana melalui digunakan di HTTPS agar browser dapat memercayai server web dan mengenkripsi data yang dipertukarkan. Ketika TLS sederhana digunakan, klien menetapkan bahwa server dapat dipercaya dengan memvalidasi sertifikatnya. mTLS adalah implementasi dari di mana klien dan server masing-masing memberikan sertifikat dan memverifikasi identitas satu sama lain.

mTLS adalah cara yang digunakan Cloud Service Mesh untuk menerapkan autentikasi dan enkripsi antarlayanan.

Di Cloud Service Mesh 1.6 dan yang lebih baru, mTLS otomatis diaktifkan secara default. Dengan mobil mTLS, proxy file bantuan klien secara otomatis mendeteksi apakah server memiliki file bantuan. File bantuan klien mengirimkan mTLS ke workload dengan file bantuan dan mengirim teks biasa ke workload tanpa file bantuan. Namun, perlu diketahui bahwa layanan menerima teks biasa dan traffic mTLS. Untuk mengamankan mesh layanan, sebaiknya migrasikan layanan agar hanya menerima lalu lintas mTLS.

Untuk informasi selengkapnya tentang cara menerapkan mTLS saja, lihat Cloud Service Mesh sebagai contoh: mTLS.

Konfigurasi Cipher Suite

Daftar berikut mencakup cipher default Cloud Service Mesh yang sesuai dengan FIPS suite:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

Untuk peningkatan keamanan, versi TLS minimum sisi server yang didukung oleh Workload Cloud Service Mesh adalah versi 1.2, yang mendukung penyesuaian cipher suite. Perlu diperhatikan bahwa Cloud Service Mesh juga mendukung TLS v1.3, yang melakukan hard code cipher suite dan tidak mendukung perubahan parameter.

Untuk informasi selengkapnya tentang cipher suite, lihat Konfigurasi TLS umum Envoy dan Autentikasi TLS Bersama Istio.

Manfaat keamanan

Cloud Service Mesh memberikan manfaat keamanan berikut:

Mengurangi risiko serangan replay atau peniruan identitas yang menggunakan data curian kredensial Anda. Cloud Service Mesh mengandalkan sertifikat mTLS untuk melakukan autentikasi rekan-rekan, bukan token pembawa seperti Token Web JSON (JWT). Karena sertifikat mTLS terikat ke saluran TLS, tidak mungkin entitas dalam lingkungan produksi Anda untuk meniru identitas entitas lain hanya memutar ulang token otentikasi tanpa mengakses kunci pribadi.
Memastikan enkripsi saat proses pengiriman. Menggunakan mTLS untuk otentikasi juga memastikan bahwa semua komunikasi TCP dienkripsi saat transit.
Memastikan hanya klien yang diotorisasi yang dapat mengakses layanan dengan data. Hanya klien yang diotorisasi yang dapat mengakses layanan dengan data sensitif terlepas dari lokasi jaringan klien dan tingkat aplikasi memiliki kredensial yang lengkap. Anda dapat menentukan bahwa hanya klien yang memiliki layanan resmi identitas atau dalam namespace Kubernetes resmi dapat mengakses layanan. Anda dapat menggunakan kebijakan akses berbasis IP untuk memberikan akses kepada klien yang dikerahkan di luar lingkungan GKE Enterprise.
Memitigasi risiko pelanggaran data pengguna dalam jaringan produksi Anda. Anda dapat memastikan bahwa orang dalam hanya dapat mengakses data sensitif melalui dengan klien besar. Selain itu, Anda dapat memastikan bahwa klien tertentu hanya dapat memperoleh akses terhadap data pengguna jika klien dapat menyajikan token pengguna yang valid dan berumur pendek. Ini mengurangi risiko penyusupan kredensial klien tunggal penyerang mengakses semua data pengguna.
Mengidentifikasi klien mana yang mengakses layanan dengan data sensitif. Logging akses Cloud Service Mesh merekam identitas mTLS klien dalam di samping alamat IP. Dengan demikian, Anda dapat dengan mudah memahami beban kerja mengakses layanan bahkan jika workload bersifat efemeral dan di-deploy secara dinamis, dan di cluster yang berbeda atau jaringan Virtual Private Cloud (VPC).

Fitur

Bagian ini menjelaskan fitur yang disediakan Cloud Service Mesh untuk mewujudkan manfaat keamanannya.

Rotasi sertifikat dan kunci otomatis

Menggunakan mTLS berdasarkan identitas layanan memungkinkan untuk mengenkripsi semua TCP komunikasi dan memberikan kredensial akses yang lebih aman dan tidak dapat diputar ulang kontrol. Salah satu tantangan utama dalam menggunakan mTLS dalam skala besar adalah mengelola kunci dan sertifikat untuk semua workload target. Cloud Service Mesh menangani rotasi Sertifikat dan kunci mTLS untuk workload GKE Enterprise tanpa mengganggu komunikasi Anda. Konfigurasi interval pembaruan sertifikat yang lebih kecil dapat mengurangi risiko.

Certificate authority Cloud Service Mesh

Cloud Service Mesh mencakup sertifikat pribadi multi-regional terkelola otoritas sertifikat, Cloud Service Mesh certificate authority, untuk menerbitkan sertifikat untuk mTLS. Otoritas sertifikat {i>Cloud Service Mesh<i} adalah layanan yang sangat andal dan skalabel dan dioptimalkan untuk workload yang diskalakan secara dinamis di platform cloud. Dengan otoritas sertifikat Cloud Service Mesh, Google mengelola keamanan dan ketersediaan backend CA. Dengan certificate authority Cloud Service Mesh, Anda dapat mengandalkan satu root kepercayaan di seluruh cluster GKE Enterprise. Saat menggunakan certificate authority Cloud Service Mesh, Anda dapat mengandalkan kumpulan workload identity untuk menyediakan isolasi secara menyeluruh. Menurut secara default, autentikasi akan gagal jika klien dan server tidak berada dalam kumpulan workload identity yang sama.

Sertifikat dari certificate authority Cloud Service Mesh mencakup data berikut tentang layanan aplikasi Anda:

ID project Google Cloud
Namespace GKE
Nama akun layanan GKE

Certificate Authority Service

Sebagai alternatif certificate authority Cloud Service Mesh, Anda dapat mengonfigurasi Cloud Service Mesh untuk menggunakan Certificate Authority Service, yang cocok untuk kasus penggunaan berikut:

Jika Anda memerlukan certificate authority lain untuk menandatangani sertifikat workload cluster yang berbeda.
Jika Anda ingin menggunakan sertifikat plugin CA Kustom Istio.
Jika Anda perlu mendukung kunci penandatanganan di HSM terkelola.
Jika Anda berada di industri yang diatur dengan regulasi ketat dan harus mematuhi kebijakan.
Jika Anda ingin menggabungkan Cloud Service Mesh CA ke perusahaan kustom root certificate untuk menandatangani sertifikat workload.

Biaya certificate authority Cloud Service Mesh disertakan dalam Cloud Service Mesh penetapan harga. CA Service tidak disertakan dalam basis Harga Cloud Service Mesh dan dikenai biaya terpisah. Selain itu, CA Service memiliki SLA eksplisit, tapi Certificate authority Cloud Service Mesh tidak demikian.

Untuk integrasi ini, semua workload di Cloud Service Mesh diberi dua Peran IAM:

Kebijakan kontrol akses kontekstual (firewall)

Dengan Cloud Service Mesh, Anda dapat mengonfigurasi kebijakan keamanan jaringan yang berdasarkan identitas mTLS versus alamat IP pembanding. Hal ini memungkinkan Anda membuat kebijakan yang tidak bergantung pada lokasi jaringan dari beban kerja. Hanya komunikasi lintas cluster dalam project Google Cloud yang sama yang saat ini didukung.

Meminta kebijakan kontrol akses berbasis klaim (firewall)

Selain identitas mTLS, Anda dapat memberikan akses berdasarkan klaim permintaan di header JWT permintaan HTTP atau gRPC. Cloud Service Mesh memungkinkan Anda menegaskan bahwa JWT ditandatangani oleh entitas tepercaya. Ini berarti Anda dapat mengonfigurasi kebijakan yang mengizinkan akses dari klien tertentu hanya jika terdapat klaim permintaan atau cocok dengan nilai yang ditentukan.

Autentikasi pengguna dengan Identity-Aware Proxy

Anda mengautentikasi pengguna yang mengakses layanan apa pun yang diekspos pada Gateway masuk Cloud Service Mesh dengan menggunakan Identity-Aware Proxy (IAP). IAP dapat mengautentikasi pengguna yang masuk dari browser, berintegrasi dengan penyedia identitas khusus, dan mengeluarkan token JWT berumur pendek atau RCToken yang kemudian dapat digunakan untuk memberi akses di gateway Ingress atau layanan downstream (dengan menggunakan mobil samping). Untuk informasi selengkapnya, lihat Mengintegrasikan IAP dengan Cloud Service Mesh.

Autentikasi pengguna dengan Penyedia Identitas yang sudah ada

Anda dapat mengintegrasikan Penyedia Identitas yang ada dengan Cloud Service Mesh untuk memberikan autentikasi pengguna akhir berbasis browser dan kontrol akses ke project yang di-deploy sebagian besar workload standar dan berbasis cloud. Untuk informasi selengkapnya, lihat Mengonfigurasi autentikasi pengguna Cloud Service Mesh.

Mengakses logging dan pemantauan

Cloud Service Mesh memastikan bahwa log dan metrik akses tersedia di Google Cloud Observability, dan menyediakan dasbor terintegrasi untuk memahami pola akses layanan atau beban kerja berdasarkan data ini. Anda juga dapat memilih untuk mengonfigurasi tujuan pribadi. Cloud Service Mesh memungkinkan Anda mengurangi derau di log akses dengan hanya mencatat akses yang berhasil satu kali dalam periode waktu yang dapat dikonfigurasi. Permintaan yang ditolak oleh kebijakan keamanan atau mengakibatkan {i>error<i} selalu dicatat. Hal ini memungkinkan Anda secara signifikan mengurangi biaya yang terkait dengan penyerapan, penyimpanan, dan pemrosesan log, tanpa kehilangan tentang sinyal keamanan utama.

Sesuai dengan FIPS

Semua komponen dan proxy bidang kontrol dalam cluster pada penggunaan arsitektur x86 Enkripsi tervalidasi FIPS 140-2 modul.

Batasan

Keamanan Cloud Service Mesh saat ini memiliki batasan berikut:

Autentikasi pengguna yang menggunakan IAP mengharuskan layanan dipublikasikan ke internet. IAP dan Cloud Service Mesh memungkinkan Anda mengonfigurasi kebijakan yang dapat membatasi akses bagi pengguna dan klien yang diotorisasi di rentang IP yang diizinkan. Jika Anda memilih untuk hanya mengekspos layanan kepada klien dalam jaringan yang sama, Anda harus mengonfigurasi mesin kebijakan khusus untuk pengguna autentikasi, dan penerbitan token.