Keamanan layanan

Dokumen ini memberikan ringkasan tentang 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.

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

  • Autentikasi dan enkripsi yang menggunakan Transport Layer Security (TLS) dan multi-TLS (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 kepada 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.

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

Dalam arsitektur modern berbasis microservice, layanan yang lebih kecil dan lebih terfokus akan 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 lakukan autentikasi, enkripsi, dan otorisasi. Langkah-langkah ini mendukung prinsip zero trust, di mana semua traffic jaringan dianggap berisiko, terlepas dari apakah traffic tersebut berasal dari dalam atau luar jaringan.

Pola desain mesh layanan memisahkan setiap kompleksitas yang terkait dengan komunikasi antarlayanan dari logika bisnis. Sebaliknya, bidang data akan menangani kompleksitas ini. Selain mengurangi kompleksitas aplikasi, pola desain mesh layanan memungkinkan pola keamanan yang mungkin sulit untuk diterapkan dan dikelola.

Dalam model ini, file bantuan gRPC atau Envoy tanpa proxy untuk mengautentikasi dan mengenkripsi komunikasi secara aman dengan memperoleh 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-hal berikut:

  • Penyediaan kunci dan sertifikat secara otomatis ke semua layanan di mesh Anda.
  • Rotasi kunci dan sertifikat secara otomatis untuk memberikan keamanan tambahan.
  • Integrasi dengan Google Kubernetes Engine (GKE) untuk menggunakan semua kemampuannya, seperti label dan deskripsi deployment.
  • Ketersediaan tinggi layanan terkelola Google, termasuk kumpulan certificate authority pribadi yang dikelola Cloud Service Mesh dan 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 belakang keamanan mesh layanan tanpa proxy gRPC, tetapi klien menggunakan proxy Envoy.

Komunikasi antarlayanan 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 dengan menggunakan TLS atau mTLS.

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

Dengan kebijakan otorisasi, Anda dapat 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 transit di jaringan akan ditampilkan dalam teks biasa. Traffic ini mungkin tunduk pada serangan person-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. Jika Anda menggunakan protokol ini melalui TLS, traffic antara klien dan server akan dienkripsi menggunakan TLS yang didasarkan pada sertifikat server. Traffic tidak lagi berupa teks biasa, sehingga mengurangi kemungkinan penyerang dapat menyadap dan memeriksa atau memanipulasi kontennya.

Menggunakan TLS untuk autentikasi

Saat layanan memanggil layanan lain, pertimbangkan pertanyaan-pertanyaan berikut:

  • Bagaimana klien tahu bahwa ia menerima respons dari server yang benar daripada dari penipu? Misalnya, dalam interaksi permintaan-respons umum berdasarkan HTTP, klien tidak memverifikasi identitas server.

  • Apa yang terjadi jika penyerang menyadapan lalu lintas tersebut? Misalnya, traffic HTTP tidak dienkripsi, sehingga siapa pun yang menerima traffic dapat memeriksa kontennya. Serangan ini dikenal sebagai serangan {i>person-in-the-middle<i}.

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 biasa, yang tidak didasarkan pada autentikasi timbal balik, server memiliki sertifikat yang digunakannya untuk mengenkripsi komunikasi antara klien dan server. Klien dapat memverifikasi identitas server dengan memeriksa tanda tangan yang dikirim kembali server selama TLS handshake. Namun, server tidak memverifikasi identitas klien.

Saat autentikasi timbal balik diaktifkan, klien juga memiliki sertifikat. Klien memverifikasi identitas server, seperti yang dijelaskan pada paragraf sebelumnya, dan server juga dapat memverifikasi identitas klien. Baik sertifikat klien maupun server digunakan untuk mengenkripsi saluran komunikasi. Hal ini juga memungkinkan server untuk memberikan otorisasi kepada klien berdasarkan identitas klien yang telah diverifikasi.

Autentikasi TLS (mTLS) dalam mesh layanan.
Autentikasi TLS (mTLS) secara menyeluruh dalam 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 Lapisan 3 dan Lapisan 7, termasuk client ID, yang berasal dari client-cert dalam koneksi mTLS, alamat IP sumber, pencocokan host, pencocokan metode, dan pencocokan header. Diagram berikut menunjukkan otorisasi dengan proxy Envoy. Prosesnya mirip dengan klien gRPC.

Otorisasi dalam 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. Jika pemanggil mencoba mengakses layanan yang tidak diizinkan, upaya tersebut akan ditolak.

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

  • Tindakan: mengizinkan atau menolak
  • Daftar aturan

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

  • Saat mTLS digunakan, akun layanan Kubernetes milik layanan pemanggil
  • Alamat IP (atau rentang alamat) layanan panggilan
  • Porta 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 yang aman dengan Cloud Service Mesh. Dengan begitu, Anda dapat menentukan daftar nama yang diizinkan, atau identitas SPIFFE (Secure Production Identity Framework for Everyone) untuk layanan tertentu yang ingin dihubungkan oleh klien. Selama pertukaran TLS, backend layanan akan menampilkan sertifikat X.509 ke klien. Selanjutnya, klien akan memeriksa sertifikat tersebut untuk mengonfirmasi bahwa sertifikat X.509 cocok dengan salah satu nama atau identitas SPIFFE. Untuk informasi selengkapnya tentang identitas SPIFFE, lihat Framework Identitas Produksi Aman untuk Semuanya.

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 beberapa domain lainnya
  • 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 mesh atau keluar dari mesh mengirim traffic ke gateway. Kemudian, gateway menangani permintaan sesuai dengan aturan yang telah Anda siapkan dengan Cloud Service Mesh. Misalnya, Anda dapat memberlakukan bahwa traffic yang memasuki mesh Anda (meskipun 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 Anda 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 membuat setiap layanan membuktikan identitasnya ke layanan lain. Sejauh mana layanan perlu membuktikan identitasnya 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 dienkripsi/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 kepadanya dengan cara berikut:

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

Cloud Service Mesh bukan certificate authority. Untuk memungkinkan 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 mengetahui detailnya, lihat Langkah berikutnya).

Arsitektur dan referensi

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

Dua resource Google Cloud API mendukung autentikasi di mesh: kebijakan TLS klien dan kebijakan TLS server. Sumber daya ketiga, 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 Mesh Layanan Cloud yang menghentikan komunikasi masuk dari klien Mesh Layanan Cloud lain.

Kebijakan TLS klien

Kebijakan TLS klien memungkinkan Anda menentukan mode TLS sisi klien dan informasi penyedia sertifikat yang akan diterapkan ke bidang data. 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 digunakan klien untuk memvalidasi sertifikat yang diterimanya dari server selama pertukaran TLS 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 memperoleh sertifikat dan kunci pribadinya menggunakan kolom API clientCertificate. Klien menggunakan informasi ini untuk memberikan sertifikat ke server selama TLS handshake.

Dalam rilis ini, Cloud Service Mesh mendukung certificate authority terkelola, CA Service. Konfigurasi 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 CA Service 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 bidang data Anda. Kebijakan TLS server mendukung autentikasi TLS, mTLS, dan, hanya dengan Envoy, Open_or_mTLS. Anda harus 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 akan menyajikan sertifikat X.509-nya. Klien memeriksa kolom subjectAltName sertifikat. Jika kolom berisi salah satu nilai yang ditentukan, komunikasi akan dilanjutkan. Mekanisme ini dijelaskan sebelumnya dalam Penamaan aman.

Kebijakan otorisasi

Kebijakan otorisasi (resource AuthorizationPolicy) menentukan cara server mengotorisasi permintaan masuk atau RPC. Atribut 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. Tambahkan kebijakan otorisasi ke resource kebijakan endpoint.

Batasan

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

Batasan dengan aplikasi gRPC tanpa proxy

Keamanan layanan untuk layanan gRPC tanpa proxy memiliki batasan berikut:

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

Langkah selanjutnya