Keamanan layanan (lama)

Dokumen ini memberikan ringkasan keamanan layanan dengan Cloud Service Mesh menggunakan API load balancing. Panduan ini ditujukan untuk pengguna Cloud Service Mesh yang ingin menambahkan autentikasi, enkripsi, dan otorisasi ke deployment mereka. Dokumen ini mengasumsikan bahwa Anda sudah memahami Cloud Service Mesh dengan Envoy dan dengan aplikasi gRPC tanpa proxy.

Dokumen ini berlaku untuk konfigurasi yang menggunakan API load balancing. Jika Anda menggunakan API pemilihan rute layanan, lihat Keamanan layanan. Ini adalah dokumen lama.

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 hanya tersedia untuk beban kerja 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 menyediakan 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:

  • Menyatakan dan memvalidasi 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 cara 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. Dengan begitu, Anda dapat 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 oleh 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.

Untuk mengaktifkan layanan keamanan, gunakan proxy HTTPS target atau proxy gRPC target dalam deployment Anda. Anda tidak dapat menggunakan proxy HTTP target atau proxy TCP target.

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. Kebijakan TLS server dapat dilampirkan ke resource proxy HTTPS target atau 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 mengizinkan 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. Kebijakan otorisasi dapat dilampirkan ke resource proxy HTTPS target atau resource kebijakan endpoint.

Batasan

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

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.

Langkah selanjutnya