Keamanan layanan

Dokumen ini memberikan ringkasan keamanan layanan dengan Traffic Director. Layanan ini ditujukan bagi pengguna Traffic Director yang ingin menambahkan autentikasi, enkripsi, dan otorisasi ke deployment mereka. Dokumen ini mengasumsikan bahwa Anda sudah terbiasa menggunakan Traffic Director with Envoy dan menggunakan aplikasi gRPC tanpa proxy.

Traffic Director memungkinkan Anda mengamankan komunikasi antarlayanan di mesh Anda. Di mesh, setiap layanan memiliki identitas. Fitur berikut membantu mendukung komunikasi yang aman:

  • Autentikasi dan enkripsi yang menggunakan Transport Layer Security (TLS) dan mutual TLS (mTLS) untuk Traffic Director dengan Envoy dan Traffic Director 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.

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

Dalam arsitektur berbasis microservice modern, layanan yang lebih kecil dan lebih terfokus akan menggantikan aplikasi monolitik berukuran besar. Panggilan layanan berkomunikasi satu sama lain melalui jaringan. Panggilan ini, yang merupakan panggilan dalam proses dalam aplikasi monolitik, menghadirkan tantangan keamanan, jadi sebaiknya Anda mengautentikasi, mengenkripsi, dan memberi otorisasi. Langkah-langkah ini mendukung prinsip zero trust, yang mana semua traffic jaringan dianggap berisiko, terlepas dari apakah traffic berasal dari dalam atau di luar jaringan.

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

Dalam model ini, gRPC atau file bantuan Envoy tanpa proxy secara aman mengautentikasi dan mengenkripsi komunikasi dengan memperoleh informasi konfigurasi dari Traffic Director dan sertifikat dari kumpulan Layanan CA.

Fitur keamanan ini mempermudah proses deployment Traffic Director Anda dengan menyediakan hal-hal berikut:

  • Penyediaan kunci dan sertifikat otomatis ke 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 deskripsi dan label deployment.
  • Ketersediaan tinggi layanan terkelola Google, termasuk Traffic Director dan kumpulan certificate authority pribadi yang dikelola Layanan CA.
  • 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

Traffic Director 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:

  • Menyatakan dan memvalidasi identitas mereka.
  • Mengenkripsi sesi komunikasi dengan menggunakan TLS atau mTLS.

Di mesh layanan, bidang data menangani jenis keamanan ini sehingga aplikasi tidak perlu melakukan penyediaan khusus untuk mengamankan.

Dengan kebijakan otorisasi, Anda dapat menolak atau mengizinkan akses sesuai dengan aturan yang Anda tentukan.

Gunakan TLS untuk enkripsi

Saat layanan memanggil layanan lain menggunakan protokol HTTP, HTTP/2, atau gRPC, traffic yang melakukan transit jaringan akan ditampilkan dalam teks biasa. Traffic ini mungkin rentan terhadap serangan person-in-the-middle, yaitu ketika penyerang mencegat traffic dan memeriksa atau memanipulasi kontennya.

Untuk mengurangi potensi masalah ini, Anda dapat menggunakan HTTP, HTTP/2, atau gRPC melalui TLS dengan Traffic Director. Jika Anda menggunakan protokol ini melalui TLS, traffic antara klien dan server akan dienkripsi menggunakan TLS yang didasarkan pada sertifikat server. Traffic tidak lagi dalam teks biasa, sehingga mengurangi kemungkinan penyerang dapat menangkap dan memeriksa atau memanipulasi kontennya.

Gunakan TLS untuk autentikasi

Saat layanan memanggil layanan lain, pertimbangkan pertanyaan berikut:

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

  • Apa yang terjadi jika penyerang menyadarkan lalu lintas tersebut? Misalnya, traffic HTTP tidak dienkripsi, sehingga siapa pun yang menerima traffic tersebut dapat memeriksa kontennya. Hal 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 Traffic Director mengonfigurasi jaringan aplikasi untuk klien maupun server—misalnya, dengan mengonfigurasi proxy Envoy di sisi klien dan proxy Envoy lainnya di sisi server—Anda dapat memanfaatkan pola autentikasi lanjutan seperti autentikasi bersama.

Dalam pertukaran HTTP over TLS umum, 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 dikirimkan kembali server selama handshake TLS. Namun, server tidak memverifikasi identitas klien.

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

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

Mengizinkan panggilan layanan

Anda dapat memilih untuk mengizinkan atau menolak akses layanan dengan menggunakan kebijakan otorisasi. Dengan Traffic Director, 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 paling rendah. Anda dapat mematuhi prinsip ini dengan membatasi akses layanan hanya ke pemanggil yang bergantung pada layanan. Jika pemanggil mencoba mengakses layanan yang tidak diotorisasi, upaya tersebut akan ditolak.

Dengan Traffic Director, 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: mengizinkan atau menolak
  • Daftar aturan

Saat permintaan atau RPC dikirim, klien Traffic Director pada layanan yang dipanggil akan menentukan apakah ada kecocokan aturan. Jika ditemukan kecocokan, permintaan atau RPC akan diizinkan atau ditolak. Anda dapat menentukan aturan untuk dicocokkan pada 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 yang aman

Sebagai mekanisme keamanan tambahan, Anda dapat mengonfigurasi penamaan yang aman dengan Traffic Director. Opsi 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 akan menampilkan sertifikat X.509 ke klien. Klien kemudian memeriksa sertifikat untuk memastikan bahwa sertifikat X.509 cocok dengan salah satu nama atau identitas SPIFFE. Untuk informasi selengkapnya tentang identitas SPIFFE, lihat Framework Identitas Produksi Aman untuk Semua Orang.

Mengamankan traffic di gateway

Untuk mengonfigurasi gateway, Anda dapat menggunakan Traffic Director. Gateway adalah proxy Envoy mandiri yang biasanya berfungsi 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 lain
  • 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 akan mengirim traffic ke gateway. Kemudian, gateway akan menangani permintaan sesuai dengan aturan yang telah Anda siapkan dengan Traffic Director. Misalnya, Anda dapat menerapkan agar traffic yang masuk ke mesh Anda (meskipun gateway masuk) harus dienkripsi menggunakan TLS.

Komponen keamanan

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

Mode enkripsi dan autentikasi yang didukung

Saat layanan memanggil layanan lain, langkah pertama dalam melakukan komunikasi yang aman adalah membuat setiap layanan membuktikan identitasnya kepada 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 identitas dan memverifikasi identitas yang ditampilkan kepada layanan dengan cara berikut:

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

Traffic Director bukan otoritas sertifikat. Untuk memungkinkan komunikasi yang aman, Anda harus menyiapkan mekanisme yang melakukan hal berikut:

  • Menyediakan identitas dan sertifikat
  • Menyediakan sertifikat untuk klien Traffic Director, seperti proxy Envoy, yang dikonfigurasi Traffic Director

Traffic Director 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

Traffic Director mencakup namespace Network Security API, yang terdiri dari tiga resource Google Cloud API yang dapat Anda gunakan 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 API Layanan Jaringan mencakup resource kebijakan endpoint, yang memungkinkan Traffic Director menyediakan konfigurasi (TLS server, TLS klien, dan kebijakan otorisasi) ke endpoint. Endpoint adalah klien Traffic Director yang menghentikan komunikasi masuk dari klien Traffic Director 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 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 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 memberikan sertifikat ke server selama handshake TLS.

Dalam rilis ini, Traffic Director mendukung certificate authority terkelola, CA Service. Konfigurasi mudah: Anda menentukan nama plugin google_cloud_private_spiffe saat mengonfigurasi penyedia sertifikat. Dengan demikian, klien xDS Anda akan 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. Anda melampirkan kebijakan otorisasi ke resource kebijakan endpoint.

Batasan

Keamanan layanan Traffic Director hanya didukung dengan GKE. Anda tidak dapat men-deploy keamanan layanan dengan Compute Engine.

Batasan terkait 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