Keamanan layanan

Dokumen ini memberikan ringkasan keamanan layanan dengan Cloud Service Mesh. Fitur ini ditujukan untuk 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. Dalam mesh, setiap layanan memiliki identitas. Fitur berikut membantu mendukung komunikasi yang aman:

  • Autentikasi dan enkripsi yang menggunakan keamanan lapisan transpor (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 layanan diizinkan untuk mengakses layanan lain dan tindakan mana yang diizinkan.

Menggunakan sertifikat dan kunci yang disediakan oleh certificate authority (CA) pribadi, Certificate Authority Service Google, memudahkan Anda untuk mempertahankan 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 fokus menggantikan aplikasi monolitik yang besar. Panggilan layanan berkomunikasi satu sama lain melalui jaringan. Panggilan ini, yang merupakan panggilan dalam proses di aplikasi monolitik, menghadirkan tantangan keamanan, jadi sebaiknya autentikasi, enkripsi, dan otorisasi panggilan tersebut. Langkah-langkah ini mendukung prinsip zero trust, yang menganggap semua traffic jaringan berisiko, terlepas dari apakah traffic berasal dari dalam atau di 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, file bantuan gRPC atau Envoy tanpa proxy mengautentikasi dan mengenkripsi komunikasi dengan 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 secara otomatis ke semua layanan di mesh Anda.
  • Rotasi kunci dan sertifikat otomatis untuk memberikan keamanan tambahan.
  • Integrasi dengan Google Kubernetes Engine (GKE) untuk menggunakan semua kemampuannya, seperti deskripsi dan label deployment.
  • Ketersediaan tinggi layanan terkelola Google, termasuk kumpulan otoritas sertifikat pribadi terkelola Cloud Service Mesh dan CA Service.
  • Keamanan yang terikat dengan Identity and Access Management (IAM) Google: otorisasi layanan berdasarkan akun layanan Google yang diotorisasi.
  • Interoperabilitas yang lancar dengan workload berbasis Envoy dan tanpa proxy. Misalnya, layanan dapat berada di balik proxy Envoy, tetapi klien menggunakan keamanan mesh layanan gRPC tanpa proxy. Sebaliknya, layanan dapat berada di balik keamanan mesh layanan gRPC tanpa proxy, tetapi klien menggunakan proxy Envoy.

Komunikasi layanan ke layanan yang aman

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

  • Nyatakan dan validasi identitas mereka.
  • Mengenkripsi 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 tunduk pada serangan man-in-the-middle, saat penyerang mencegat traffic dan memeriksa atau memanipulasi kontennya.

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 kontennya.

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 penipu? Misalnya, dalam interaksi permintaan-respons biasa 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 dapat memeriksa kontennya. 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 over TLS standar, yang tidak didasarkan pada autentikasi bersama, server memiliki sertifikat yang digunakan 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 memberikan otorisasi kepada klien berdasarkan identitas klien terverifikasi.

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

Mengizinkan panggilan layanan

Anda dapat memilih untuk mengizinkan atau menolak akses layanan menggunakan kebijakan otorisasi. Dengan Cloud Service Mesh, Anda dapat menentukan aturan izinkan dan tolak untuk memberikan otorisasi akses berdasarkan parameter permintaan. Anda dapat mendasarkan aturan ini pada parameter Lapisan 3 dan Lapisan 7, termasuk client ID, 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 di 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 ke pemanggil yang bergantung pada layanan. Jika pemanggil mencoba mengakses layanan yang izinnya tidak dimiliki, upaya tersebut akan ditolak.

Dengan Cloud Service Mesh, Anda dapat mengonfigurasi kebijakan otorisasi yang memungkinkan data plane 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 menentukan apakah ada kecocokan aturan. Jika kecocokan ditemukan, permintaan atau RPC akan diizinkan atau ditolak. Anda dapat menentukan aturan untuk dicocokkan dengan atribut seperti berikut:

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

Penamaan aman

Sebagai mekanisme keamanan tambahan, Anda dapat mengonfigurasi pemberian nama 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 dicoba dihubungkan oleh klien. Selama pertukaran TLS, backend layanan menampilkan sertifikat X.509 ke klien. Selanjutnya, klien akan memeriksa sertifikat untuk mengonfirmasi bahwa sertifikat X.509 cocok dengan salah satu nama atau identitas SPIFFE. Untuk informasi selengkapnya tentang identitas SPIFFE, lihat 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 hal berikut:

  • Gateway masuk yang menangani traffic yang memasuki mesh atau beberapa domain lain
  • Gateway keluar yang menangani traffic yang keluar dari mesh atau beberapa domain lain
  • 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 akan 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 memasuki mesh (melalui gateway masuk) harus 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.

Enkripsi dan mode autentikasi yang didukung

Saat layanan memanggil layanan lain, langkah pertama dalam membangun komunikasi yang aman adalah meminta setiap layanan untuk membuktikan identitasnya kepada layanan lain. Tingkat layanan yang perlu membuktikan identitasnya didasarkan pada mode TLS yang Anda konfigurasikan.

Anda dapat mengonfigurasi tingkat keamanan berikut:

  • Tidak dienkripsi/tidak diautentikasi
  • TLS
  • TLS Bersama (mTLS)
  • Permissive: mTLS atau tidak dienkripsi/tidak diautentikasi, bergantung pada cara klien memulai koneksi

Sertifikat dan certificate authority

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

  • Layanan yang ingin membuktikan identitasnya ke layanan lain akan menampilkan sertifikatnya ke layanan lain. CA yang dipercaya oleh kedua layanan tersebut 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 merupakan certificate authority. Untuk mengaktifkan komunikasi yang aman, Anda harus menyiapkan mekanisme yang melakukan hal berikut:

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

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

Arsitektur dan resource

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

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

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

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 disertakan ke resource layanan backend global.

Saat mengonfigurasi TLS, Anda harus menyediakan mekanisme yang digunakan klien untuk memvalidasi sertifikat yang diterima 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 API clientCertificate. Klien menggunakan informasi ini untuk menampilkan sertifikat ke server selama TLS handshake.

Dalam rilis ini, Cloud Service Mesh mendukung otoritas sertifikat terkelola, Layanan CA. Konfigurasi sangat mudah: 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.

Kebijakan TLS server

Kebijakan TLS server (resource ServerTlsPolicy) memungkinkan Anda menentukan mode TLS sisi server dan informasi penyedia sertifikat yang akan diterapkan ke data plane Anda. Kebijakan TLS server mendukung TLS, mTLS, dan, khusus 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 menyediakan daftar nama alternatif subjek di kolom subjectAltNames. Saat klien memulai handshake TLS dengan salah satu backend layanan, server akan menampilkan sertifikat X.509-nya. Klien memeriksa kolom subjectAltName sertifikat. Jika kolom berisi salah satu nilai yang ditentukan, komunikasi akan berlanjut. Mekanisme ini telah dijelaskan sebelumnya di Pemberian nama aman.

Kebijakan otorisasi

Kebijakan otorisasi (resource AuthorizationPolicy) menentukan cara server memberi otorisasi pada permintaan masuk atau RPC. Kebijakan ini dapat dikonfigurasi untuk mengizinkan atau menolak RPC atau permintaan masuk 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 berasal dari sertifikat klien dalam koneksi TLS bersama, atau dapat berupa identitas standby 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. Dapat berupa salah satu dari 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 akan 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 akan 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 akan dievaluasi dalam urutan berikut untuk menentukan apakah permintaan diizinkan atau ditolak.

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

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

  3. Kebijakan dengan tindakan ALLOW: jika tidak ada kebijakan ALLOW atau jika kebijakan ALLOW 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 total 5 kebijakan otorisasi per Gateway.
  • Anda dibatasi hingga 20 resource AuthzPolicy per project.
  • Satu AuthzPolicy dapat mengarah ke maksimal 100 Gateway.

Langkah selanjutnya