Keamanan layanan

Dokumen ini memberikan ringkasan keamanan layanan dengan Cloud Service Mesh. Fitur ini ditujukan bagi pengguna Cloud Service Mesh yang ingin menambahkan autentikasi, enkripsi, dan otorisasi ke deployment mereka. Dokumen ini mengasumsikan bahwa Anda sudah memahami Ringkasan Cloud Service Mesh dan aplikasi gRPC tanpa proxy.

Cloud Service Mesh memungkinkan Anda mengamankan komunikasi layanan ke layanan di mesh Anda. Dalam mesh, setiap layanan memiliki identitas. Fitur berikut membantu mendukung komunikasi yang aman:

  • Autentikasi dan enkripsi yang menggunakan keamanan lapisan transportasi (TLS) dan TLS bersama (mTLS) untuk Cloud Service Mesh dengan Envoy dan Cloud Service Mesh dengan aplikasi gRPC tanpa proxy. Kebijakan TLS klien dan kebijakan TLS server mengontrol apakah layanan perlu membuktikan identitasnya satu sama lain dan menggunakan saluran komunikasi terenkripsi.
  • Otorisasi, berdasarkan karakteristik klien dan permintaan. Kebijakan otorisasi mengontrol apakah suatu layanan diizinkan untuk mengakses layanan lain dan tindakan mana yang diizinkan.

Dengan menggunakan sertifikat dan kunci yang disediakan oleh certificate authority (CA) pribadi, Certificate Authority Service Google mempermudah Anda menjaga keamanan layanan. Layanan CA menyediakan sertifikat mesh GKE. Fitur sertifikat mesh GKE dan Cloud Service Mesh memungkinkan Anda men-deploy sertifikat ini secara otomatis dan membuat beban kerja menggunakannya. Anda mengubah Pod untuk mengizinkan workload menerima dan menggunakan kredensial mTLS. Keamanan layanan Cloud Service Mesh saat ini hanya tersedia untuk workload berbasis GKE.

Dalam arsitektur berbasis microservice modern, layanan yang lebih kecil dan lebih terfokus menggantikan aplikasi monolitik besar. Panggilan layanan berkomunikasi satu sama lain melalui jaringan. Panggilan ini, yang merupakan panggilan dalam proses di aplikasi monolitik, menimbulkan tantangan keamanan, jadi sebaiknya autentikasi, enkripsi, dan beri otorisasi. Langkah-langkah ini mendukung prinsip zero trust, yang menganggap semua traffic jaringan berisiko, terlepas dari apakah traffic tersebut berasal dari dalam atau luar jaringan.

Pola desain mesh layanan memisahkan kompleksitas apa pun yang terkait dengan komunikasi layanan ke layanan dari logika bisnis. Sebagai gantinya, bidang data menangani kompleksitas ini. Selain mengurangi kompleksitas aplikasi, pola desain mesh layanan memungkinkan pola keamanan yang mungkin sulit diterapkan dan dikelola.

Dalam model ini, gRPC tanpa proxy atau file bantuan Envoy mengautentikasi dan mengenkripsi komunikasi secara aman dengan mendapatkan informasi konfigurasi dari Cloud Service Mesh dan sertifikat dari kumpulan Layanan CA.

Fitur keamanan ini mempermudah proses deployment Cloud Service Mesh Anda dengan menyediakan hal berikut:

  • Penyediaan kunci dan sertifikat otomatis untuk semua layanan di mesh Anda.
  • Rotasi otomatis kunci dan sertifikat untuk memberikan keamanan tambahan.
  • Integrasi dengan Google Kubernetes Engine (GKE) untuk menggunakan semua kemampuannya, seperti deskriptor dan label deployment.
  • Ketersediaan tinggi layanan terkelola Google, termasuk Cloud Service Mesh dan kumpulan otoritas sertifikat pribadi terkelola CA Service.
  • Keamanan yang terkait dengan Google Identity and Access Management (IAM): otorisasi layanan berdasarkan akun layanan Google yang diberi otorisasi.
  • Interoperabilitas yang lancar dengan workload berbasis Envoy dan tanpa proxy. Misalnya, layanan dapat berada di belakang proxy Envoy, tetapi klien menggunakan keamanan mesh layanan tanpa proxy gRPC. Sebaliknya, layanan dapat berada di balik keamanan mesh layanan tanpa proxy gRPC, tetapi klien menggunakan proxy Envoy.

Komunikasi layanan ke layanan yang aman

Cloud Service Mesh menyediakan otorisasi serta keamanan antar-layanan dengan enkripsi dan autentikasi yang menggunakan TLS. Kebijakan TLS klien dan kebijakan TLS server memungkinkan layanan melakukan hal berikut:

  • Menegaskan dan memvalidasi identitas mereka.
  • Enkripsi sesi komunikasi menggunakan TLS atau mTLS.

Dalam mesh layanan, bidang data menangani jenis keamanan ini sehingga aplikasi tidak perlu membuat ketentuan khusus agar aman.

Kebijakan otorisasi memungkinkan Anda menolak atau mengizinkan akses sesuai dengan aturan yang Anda tentukan.

Menggunakan TLS untuk enkripsi

Saat layanan memanggil layanan lain menggunakan protokol HTTP, HTTP/2, atau gRPC, traffic yang melewati jaringan akan berupa teks biasa. Traffic ini mungkin rentan terhadap serangan person-in-the-middle, di mana penyerang mencegat traffic dan memeriksa atau memanipulasi isinya.

Untuk mengurangi potensi masalah ini, Anda dapat menggunakan HTTP, HTTP/2, atau gRPC melalui TLS dengan Cloud Service Mesh. Saat Anda menggunakan protokol ini melalui TLS, traffic antara klien dan server dienkripsi menggunakan TLS yang didasarkan pada sertifikat server. Traffic tidak lagi dalam teks biasa, sehingga mengurangi kemungkinan penyerang dapat mencegat dan memeriksa atau memanipulasi isinya.

Menggunakan TLS untuk autentikasi

Saat layanan memanggil layanan lain, pertimbangkan pertanyaan berikut:

  • Bagaimana klien mengetahui bahwa klien menerima respons dari server yang benar, bukan dari server palsu? Misalnya, dalam interaksi permintaan-respons khas berdasarkan HTTP, klien tidak memverifikasi identitas server.

  • Apa yang terjadi jika penyerang mencegat traffic tersebut? Misalnya, traffic HTTP tidak dienkripsi, sehingga siapa pun yang menerima traffic tersebut dapat memeriksa isinya. Hal ini dikenal sebagai serangan man-in-the-middle.

Untuk mengurangi masalah ini, Anda dapat menggunakan HTTP, HTTP/2, dan gRPC melalui TLS. Dalam pertukaran antara klien dan server ini, server harus menggunakan sertifikat server untuk membuktikan identitasnya kepada klien. Permintaan dan respons kemudian dienkripsi menggunakan TLS.

Autentikasi TLS bersama

Saat Cloud Service Mesh mengonfigurasi jaringan aplikasi untuk klien dan server—misalnya, dengan mengonfigurasi proxy Envoy di sisi klien dan proxy Envoy lain di sisi server—Anda dapat memanfaatkan pola autentikasi lanjutan seperti autentikasi bersama.

Dalam pertukaran HTTP melalui TLS yang umum, yang tidak didasarkan pada autentikasi bersama, server memiliki sertifikat yang digunakannya untuk mengenkripsi komunikasi antara klien dan server. Klien dapat memverifikasi identitas server dengan memeriksa tanda tangan yang dikirim kembali oleh server selama handshake TLS. Namun, server tidak memverifikasi identitas klien.

Jika autentikasi bersama diaktifkan, klien juga memiliki sertifikat. Klien memverifikasi identitas server, seperti yang dijelaskan di paragraf sebelumnya, dan server juga dapat memverifikasi identitas klien. Sertifikat klien dan server digunakan untuk mengenkripsi saluran komunikasi. Hal ini juga memungkinkan server mengizinkan klien berdasarkan identitas klien terverifikasi.

Autentikasi TLS bersama (mTLS) di service mesh.
Autentikasi TLS bersama (mTLS) di mesh layanan (klik untuk memperbesar)

Mengizinkan panggilan layanan

Anda dapat memilih untuk mengizinkan atau menolak akses layanan dengan menggunakan kebijakan otorisasi. Dengan Cloud Service Mesh, Anda dapat menentukan aturan izinkan dan tolak untuk mengizinkan akses berdasarkan parameter permintaan. Anda dapat mendasarkan aturan ini pada parameter Layer 3 dan Layer 7, termasuk ID klien, yang berasal dari client-cert dalam koneksi mTLS, alamat IP sumber, kecocokan host, kecocokan metode, dan kecocokan header. Diagram berikut menunjukkan otorisasi dengan proxy Envoy. Prosesnya mirip dengan klien gRPC.

Otorisasi di mesh layanan.
Otorisasi dalam mesh layanan menggunakan Envoy (klik untuk memperbesar)

Membatasi akses menggunakan otorisasi

Praktik terbaik dalam mesh layanan adalah mematuhi prinsip hak istimewa terendah. Anda dapat mematuhi prinsip ini dengan membatasi akses layanan hanya untuk pemanggil yang bergantung pada layanan tersebut. Jika pemanggil mencoba mengakses layanan yang tidak diizinkan, upaya tersebut akan ditolak.

Dengan Cloud Service Mesh, Anda dapat mengonfigurasi kebijakan otorisasi yang memungkinkan bidang data Anda mengizinkan atau menolak akses layanan berdasarkan aturan yang Anda tentukan. Kebijakan ini terdiri dari dua komponen:

  • Tindakan: izinkan atau tolak
  • Daftar aturan

Saat permintaan atau RPC dikirim, klien Cloud Service Mesh di layanan yang dipanggil akan menentukan apakah ada kecocokan aturan. Jika kecocokan ditemukan, permintaan atau RPC akan diizinkan atau ditolak. Anda dapat menentukan aturan untuk mencocokkan atribut seperti berikut:

  • Saat mTLS digunakan, akun layanan Kubernetes dari layanan yang memanggil
  • Alamat IP (atau rentang alamat) layanan yang memanggil
  • Port layanan tujuan
  • Atribut HTTP permintaan, termasuk nama host, metode, dan header HTTP yang ditentukan pengguna.

Penamaan yang aman

Sebagai mekanisme keamanan tambahan, Anda dapat mengonfigurasi penamaan aman dengan Cloud Service Mesh. Hal ini memungkinkan Anda menentukan daftar nama yang diizinkan, atau identitas SPIFFE (Secure Production Identity Framework for Everyone), untuk layanan tertentu yang coba dihubungkan oleh klien. Selama pertukaran TLS, backend layanan menampilkan sertifikat X.509 ke klien. Kemudian, klien memeriksa sertifikat untuk mengonfirmasi bahwa sertifikat X.509 cocok dengan salah satu nama atau identitas SPIFFE. Untuk mengetahui informasi selengkapnya tentang identitas SPIFFE, lihat artikel Secure Production Identity Framework for Everyone.

Mengamankan traffic di gateway

Untuk mengonfigurasi gateway, Anda dapat menggunakan Cloud Service Mesh. Gateway adalah proxy Envoy mandiri yang biasanya bertindak sebagai salah satu dari berikut ini:

  • Gateway masuk yang menangani traffic yang memasuki mesh atau domain lain
  • Gateway keluar yang menangani traffic yang keluar dari mesh atau domain lainnya
  • Reverse proxy atau proxy tengah yang mendistribusikan traffic masuk di antara satu atau beberapa layanan

Klien yang ingin mengirim traffic ke dalam mesh atau keluar dari mesh mengirim traffic ke gateway. Kemudian, gateway akan menangani permintaan sesuai dengan aturan yang telah Anda siapkan dengan Cloud Service Mesh. Misalnya, Anda dapat mewajibkan traffic yang masuk ke mesh Anda (melalui gateway masuk) dienkripsi menggunakan TLS.

Komponen keamanan

Keamanan layanan Cloud Service Mesh mendukung kebijakan TLS klien, kebijakan TLS server, dan kebijakan otorisasi. Anda membuat kebijakan ini agar Cloud Service Mesh dapat mengonfigurasi bidang data dan mengaktifkan kemampuan keamanan. Untuk membuat atau memperbarui kebijakan ini, Anda tidak perlu membuat perubahan pada aplikasi Anda.

Enkripsi dan mode autentikasi yang didukung

Saat layanan memanggil layanan lain, langkah pertama dalam membangun komunikasi yang aman adalah membuat setiap layanan membuktikan identitasnya ke layanan lain. Tingkat pembuktian identitas layanan didasarkan pada mode TLS yang Anda konfigurasi.

Anda dapat mengonfigurasi tingkat keamanan berikut:

  • Tidak dienkripsi/tidak diautentikasi
  • TLS
  • TLS bersama (mTLS)
  • Permisif: mTLS atau tidak terenkripsi/tidak diautentikasi, bergantung pada cara klien memulai koneksi

Sertifikat dan certificate authority

Sertifikat dan certificate authority (CA) tepercaya memberikan fondasi untuk kepercayaan dalam sistem terdistribusi seperti mesh layanan. Dengan menggunakan sertifikat, layanan dapat membuktikan identitasnya dan memverifikasi identitas yang diberikan kepada mereka dengan cara berikut:

  • Layanan yang ingin membuktikan identitasnya ke layanan lain akan memberikan sertifikatnya ke layanan lain tersebut. CA yang dipercayai kedua layanan menandatangani dan menerbitkan sertifikat ini secara kriptografis.
  • Layanan yang menerima sertifikat ini dapat memverifikasi bahwa sertifikat berasal dari CA yang dipercayainya.

Cloud Service Mesh bukan otoritas sertifikat. Untuk mengaktifkan komunikasi yang aman, Anda harus menyiapkan mekanisme yang melakukan hal berikut:

  • Menyediakan identitas dan sertifikat
  • Menyediakan sertifikat untuk klien Cloud Service Mesh, seperti proxy Envoy, yang dikonfigurasi oleh Cloud Service Mesh

Cloud Service Mesh mendukung Layanan CA Google. Panduan penyiapan untuk Envoy dan gRPC tanpa proxy mencakup petunjuk untuk menyiapkannya (untuk detailnya, lihat Langkah berikutnya).

Arsitektur dan resource

Cloud Service Mesh mencakup namespace Network Security API, yang terdiri dari tiga Google Cloud resource API yang memungkinkan Anda menentukan kebijakan keamanan yang harus diterapkan ke data plane Anda.

Dua Google Cloud resource API mendukung autentikasi di mesh: kebijakan TLS klien dan kebijakan TLS server. Resource ketiga, yaitu kebijakan otorisasi, mendukung otorisasi.

Namespace Network Services API mencakup resource kebijakan endpoint, yang memungkinkan Cloud Service Mesh menyediakan konfigurasi (TLS server, TLS klien, dan kebijakan otorisasi) ke endpoint. Endpoint adalah klien Cloud Service Mesh yang menghentikan komunikasi masuk dari klien Cloud Service Mesh lainnya.

Kebijakan TLS klien

Kebijakan TLS klien memungkinkan Anda menentukan mode TLS sisi klien dan informasi penyedia sertifikat yang akan diterapkan ke bidang data Anda. Kebijakan TLS klien mendukung autentikasi TLS dan mTLS. Kebijakan TLS klien harus dilampirkan ke resource layanan backend global.

Saat mengonfigurasi TLS, Anda harus menyediakan mekanisme yang memungkinkan klien memvalidasi sertifikat yang diterimanya dari server selama pertukaran TLS dengan menggunakan kolom API serverValidationCa. Klien menggunakan informasi ini untuk mendapatkan sertifikat validasi yang dapat digunakan untuk memvalidasi sertifikat server.

Saat mengonfigurasi mTLS, Anda juga harus menyediakan mekanisme yang digunakan klien untuk mendapatkan sertifikat dan kunci pribadinya menggunakan kolom clientCertificate API. Klien menggunakan informasi ini untuk memberikan sertifikat ke server selama TLS handshake.

Dalam rilis ini, Cloud Service Mesh mendukung certificate authority terkelola, CA Service. Konfigurasinya sederhana: Anda menentukan nama plugin google_cloud_private_spiffe saat mengonfigurasi penyedia sertifikat. Hal ini menyebabkan klien xDS Anda memuat sertifikat dan kunci dari lokasi statis. Sebagai prasyarat, Anda harus mengonfigurasi kumpulan Layanan CA dan mengaktifkan sertifikat mesh di cluster GKE Anda.

Kebijakan TLS server

Kebijakan TLS server (resource ServerTlsPolicy) memungkinkan Anda menentukan mode TLS sisi server dan informasi penyedia sertifikat yang akan diterapkan ke bidang data Anda. Kebijakan TLS server mendukung TLS, mTLS, dan, hanya dengan Envoy, autentikasi Open_or_mTLS. Anda melampirkan kebijakan TLS server ke resource kebijakan endpoint.

Nama alternatif subjek

Saat mengonfigurasi kolom securitySettings layanan backend global, Anda dapat memberikan daftar nama alternatif subjek di kolom subjectAltNames. Saat klien memulai handshake TLS dengan salah satu backend layanan, server menampilkan sertifikat X.509-nya. Klien memeriksa kolom subjectAltName sertifikat. Jika kolom berisi salah satu nilai yang ditentukan, komunikasi akan berlanjut. Mekanisme ini dijelaskan sebelumnya di bagian Penamaan aman.

Kebijakan otorisasi

Kebijakan otorisasi (resource AuthorizationPolicy) menentukan cara server mengizinkan permintaan atau RPC yang masuk. Kebijakan ini dapat dikonfigurasi untuk mengizinkan atau menolak permintaan masuk atau RPC berdasarkan berbagai parameter, seperti identitas klien yang mengirim permintaan, host, header, dan atribut HTTP lainnya. Anda melampirkan kebijakan otorisasi ke resource kebijakan endpoint.

Aturan kebijakan otorisasi memiliki komponen berikut:

  • from: menentukan identitas klien yang diizinkan oleh aturan. Identitas dapat diperoleh dari sertifikat klien dalam koneksi TLS bersama, atau dapat berupa identitas sekitar yang terkait dengan VM klien, seperti dari akun layanan atau tag aman.
  • to: menentukan operasi yang diizinkan oleh aturan, seperti URL yang dapat diakses atau metode HTTP yang diizinkan.
  • when: memungkinkan Anda menentukan batasan tambahan yang harus dipenuhi. Anda dapat menggunakan ekspresi Common Expression Language (CEL) untuk menentukan batasan.
  • action: menentukan tindakan aturan. Nilainya bisa berupa ALLOW, DENY, atau CUSTOM.

Batasan

Keamanan layanan Cloud Service Mesh hanya didukung dengan GKE. Anda tidak dapat men-deploy keamanan layanan dengan Compute Engine.

Saat mengevaluasi permintaan, kebijakan otorisasi akan melakukan salah satu tindakan berikut:

  • ALLOW: memberikan akses ke resource yang diminta jika permintaan cocok dengan aturan yang ditentukan dalam kebijakan otorisasi. Kebijakan otorisasi memblokir akses ke resource yang diminta jika permintaan tidak cocok dengan aturan yang ditentukan dalam kebijakan otorisasi. Permintaan ditolak jika tidak cocok dengan kebijakan ALLOW, meskipun kebijakan lain mengizinkannya.

  • DENY: memblokir akses ke resource jika permintaan cocok dengan salah satu aturan yang ditentukan dalam kebijakan DENY. Kebijakan otorisasi memberikan akses ke resource yang diminta jika permintaan tidak cocok dengan aturan yang ditentukan dalam kebijakan otorisasi. Permintaan ditolak jika cocok dengan kebijakan DENY, meskipun kebijakan lain mengizinkannya.

  • CUSTOM (Tidak didukung di Cloud Service Mesh): memungkinkan integrasi dengan sistem otorisasi eksternal untuk keputusan otorisasi yang kompleks. Tindakan CUSTOM digunakan untuk kebijakan yang menggunakan ekstensi layanan untuk keputusan otorisasi.

Urutan evaluasi kebijakan otorisasi

Jika beberapa kebijakan otorisasi dikaitkan dengan satu resource, kebijakan tersebut dievaluasi dalam urutan berikut untuk menentukan apakah permintaan diizinkan atau ditolak.

  1. Kebijakan dengan tindakan CUSTOM: jika kebijakan CUSTOM menolak permintaan, permintaan akan langsung ditolak. DENY atau ALLOW tidak dievaluasi, meskipun ada yang dikonfigurasi.

  2. Kebijakan dengan tindakan DENY: jika ada kebijakan DENY yang cocok dengan permintaan, permintaan akan ditolak. Kebijakan ALLOW tidak dievaluasi, meskipun jika ada yang dikonfigurasi.

  3. Kebijakan dengan tindakan ALLOW: jika tidak ada kebijakan ALLOW atau jika ada kebijakan ALLOW yang cocok dengan permintaan, permintaan akan diizinkan. Namun, jika tidak ada kebijakan ALLOW yang cocok dengan permintaan, permintaan akan ditolak.

Batasan pada aplikasi gRPC tanpa proxy

Keamanan layanan untuk layanan gRPC tanpa proxy memiliki batasan berikut:

  • Rilis ini terbatas untuk Java, Python, C++, dan Go.

Kuota AuthzPolicy

  • Anda dibatasi hingga total 5 kebijakan otorisasi per Gateway.
  • Anda dibatasi hingga 20 resource AuthzPolicy per project.
  • Satu AuthzPolicy dapat mengarah ke hingga 100 Gateway.

Langkah berikutnya