Praktik Terbaik untuk menggunakan gateway keluar Cloud Service Mesh di cluster GKE

Dokumen ini menjelaskan cara menggunakan Cloud Service Mesh gateway keluar dan kontrol Google Cloud lainnya untuk mengamankan traffic keluar (traffic keluar) dari workload yang di-deploy di cluster Google Kubernetes Engine (GKE). Ini dapat membatasi koneksi ke layanan eksternal berdasarkan identitas aplikasi sumber, namespace tim, domain tujuan, dan properti permintaan keluar.

Ada tutorial pendamping yang dapat Anda gunakan sebagai cetak biru untuk mengonfigurasi kontrol traffic keluar di klaster.

Audiens yang dituju untuk dokumen ini mencakup jaringan, platform, dan engineer keamanan yang mengelola cluster GKE yang digunakan oleh satu atau lebih banyak tim pengiriman perangkat lunak. Kontrol yang dijelaskan di sini mungkin sangat berguna bagi organisasi yang harus menunjukkan kepatuhan terhadap peraturan (misalnya, GDPR dan PCI).

Pengantar

Pendekatan tradisional terhadap keamanan jaringan adalah untuk mendefinisikan keamanan perimeter di sekitar suatu kelompok aplikasi. {i>Firewall<i} digunakan di lingkungan ini perimeter untuk mengizinkan atau menolak lalu lintas berdasarkan IP sumber dan tujuan alamat IP, sambil memercayai aplikasi dan traffic yang terdapat dalam keliling. Namun, kepercayaan ini melibatkan risiko. Orang dalam yang berniat jahat, atau siapa pun yang menyusupi perimeter dapat bergerak bebas di dalam jaringan, mengakses dan memindahkan data secara tidak sah, menyerang sistem pihak ketiga, dan mengganggu administrasi yang berbeda.

Saat beban kerja yang berjalan di cluster Kubernetes membuat koneksi keluar ke host di internet, menerapkan kontrol keamanan berbasis IP tradisional dapat rumit karena:

  • Alamat IP pod tidak cukup mewakili identitas workload yang membuat koneksi itu. Di lingkungan Kubernetes, IP Pod alamat ditetapkan secara singkat dan sering didaur ulang saat Pod dan mulai.

  • Sering kali tidak mungkin untuk mengidentifikasi set alamat IP yang kecil dan tetap untuk host tujuan tertentu. Alamat IP sering berubah, bervariasi menurut di region Anda, dan dapat diambil dari rentang yang luas atau mewakili {i>cache<i}, {i>proxy<i}, atau CDN.

  • Beberapa tim berbagi cluster multi-tenant yang sama, dengan cluster dalam rentang IP sumber, mungkin memiliki konektivitas eksternal yang berbeda lainnya.

Cloud Service Mesh adalah layanan distribusi layanan Istio open source {i>mesh.<i} Mesh layanan menyediakan cara yang seragam untuk terhubung, mengelola, dan mengamankan komunikasi aplikasi. Mesh layanan menggunakan pendekatan yang berfokus pada aplikasi dan menggunakan identitas aplikasi yang terpercaya, bukan alamat IP pendekatan.

Anda dapat men-deploy mesh layanan secara transparan tanpa perlu memodifikasi mesh yang ada pada kode aplikasi Anda. Menggunakan mesh layanan membantu memisahkan pekerjaan pengembangan tim yang bertanggung jawab untuk mengirimkan dan merilis fitur aplikasi, dari tanggung jawab administrator jaringan dengan menyediakan protokol mengontrol perilaku jaringan.

Cloud Service Mesh menyediakan opsi untuk men-deploy proxy maju mandiri,yang dikenal sebagai gateway keluar, di tepi mesh. Panduan ini menjelaskan cara penggabungan fitur proxy gateway keluar dengan fitur Google Cloud untuk mengontrol, memberi otorisasi, dan mengamati traffic keluar dari workload yang di-deploy ke cluster GKE.

komponen konseptual

Arsitektur defense-in-depth

Diagram di bawah menunjukkan arsitektur yang mengambil pendekatan defense in depth untuk mengontrol traffic keluar secara mendetail untuk cluster yang digunakan tim. Kontrol didasarkan pada Lapisan 4 (transpor) dan Lapisan 7 (aplikasi) kontrol jaringan.

arsitektur secara keseluruhan

Arsitektur ini menggunakan resource dan kontrol berikut:

  • J cluster GKE pribadi: Node pada cluster GKE pribadi hanya memiliki IP internal alamat dan tidak terhubung ke internet secara {i>default<i}.

  • Cloud NAT: Cloud NAT memungkinkan akses internet keluar dari cluster pribadi.

  • Aturan firewall Virtual Private Cloud (VPC): Anda mengonfigurasi aturan firewall VPC untuk menerapkan Lapisan 4 (Transport) kontrol ke koneksi ke dan dari node di GKE . Anda dapat menerapkan aturan firewall VPC ke VM berdasarkan akun layanan atau tag jaringan.

  • Node pool GKE dengan akun layanan yang berbeda. Hal ini memungkinkan Anda mengonfigurasi aturan yang akan diterapkan bergantung pada kumpulan node tempat node berada.

  • Kubernetes namespace: Anda membuat namespace untuk setiap tim guna menyediakan isolasi dan delegasi kontrol administratif. Administrator jaringan menggunakan {i>namespace<i} khusus untuk men-deploy gateway keluar dan mengonfigurasi perutean ke host eksternal.

  • Kubernetes kebijakan jaringan: Kebijakan jaringan memungkinkan Anda menerapkan kontrol Lapisan 4 ke Pod. Setiap kebijakan jaringan mencakup namespace serta dapat dicakup secara lebih mendetail ke Pod tertentu dalam namespace.

  • Gateway keluar: Traffic yang keluar dari Pod dalam mesh diarahkan melalui {i>proxy gateway keluar<i} khusus yang berjalan pada {i>node<i} khusus. Anda men-deploy gateway keluar dengan autoscaler Pod horizontal sehingga jumlah replika akan bertambah dan berkurang seiring dengan traffic.

  • Kebijakan otorisasi: Anda menggunakan kebijakan otorisasi mesh untuk menerapkan kontrol Lapisan 7 (aplikasi) traffic antar Pod dalam mesh dan traffic yang keluar dari mesh.

  • Referensi file bantuan: Anda menggunakan resource file bantuan untuk mengontrol cakupan konfigurasi file bantuan dan menjalankan proxy yang berjalan di tiap Pod workload. Anda dapat menggunakan resource {i>Sidecar<i} untuk mengonfigurasi namespace, Pod, dan layanan eksternal yang dapat dilihat sebagian besar workload standar dan berbasis cloud.

  • Akses Google Pribadi: Opsi ini memungkinkan node dan Pod di cluster pribadi mengakses Google API dan mengambil image Docker dari Container Registry.

  • Workload Identity GKE: Dengan Workload Identity, Anda dapat menggunakan Identity and Access Management (IAM) untuk memberikan izin API ke mengikuti workload prinsip hak istimewa terendah, tanpa perlu menangani secret.

Mengonfigurasi kontrol keluar

Jika Anda menggunakan gateway keluar untuk mengamankan traffic keluar dari mesh, kami sebaiknya Anda mengonfigurasi kontrol defense in depth yang dijelaskan bagian.

Menggunakan Private GKE dengan Cloud NAT

Ketika keamanan adalah hal penting, persyaratan pertama bagi banyak organisasi adalah menghindari penetapan alamat IP publik ke workload mereka. J cluster GKE pribadi memenuhi persyaratan ini. Anda dapat mengonfigurasi Mode VPC Native di ruang pribadi cluster, sehingga Pod dan service akan diberi alamat IP dari yang berbeda di VPC. Alamat IP Pod Native VPC dapat dirutekan secara native dalam Jaringan VPC.

Beberapa workload mungkin memerlukan akses ke layanan di luar jaringan VPC dan ke internet. Untuk mengizinkan workload terhubung ke host eksternal tanpa perlu mereka untuk memiliki alamat IP publik, mengkonfigurasi Cloud NAT untuk memberikan penafsiran alamat jaringan (NAT).

Pastikan bahwa Cloud NAT dikonfigurasi sehingga gateway keluar dapat membuat jumlah koneksi simultan yang memadai ke tujuan eksternal. Anda dapat menghindari kehabisan porta dan masalah dengan penundaan penggunaan ulang koneksi dengan menetapkan jumlah minimum port per VM dengan tepat. Lihat ringkasan alamat dan port Cloud NAT untuk mengetahui detail selengkapnya. Meningkatkan jumlah replika gateway keluar dapat membantu mengurangi kemungkinan konflik pemetaan independen endpoint.

Mengonfigurasi Akses Google Pribadi untuk Google API dan layanan Google

Sepertinya workload Anda perlu memiliki akses ke Google API dan layanan IT perusahaan mereka. Gunakan Akses Google Pribadi dengan Zona DNS kustom untuk memungkinkan konektivitas dari subnet VPC pribadi ke Google API menggunakan yang digunakan untuk empat alamat IP. Saat menggunakan alamat IP ini, Pod tidak perlu memiliki alamat IP eksternal dan traffic tidak pernah keluar dari jaringan Google. Anda dapat menggunakan private.googleapis.com (199.36.153.8/30) atau restricted.googleapis.com (199.36.153.4/30), bergantung pada apakah Anda menggunakan Kontrol Layanan VPC.

Menggunakan Workload Identity dan IAM untuk meningkatkan keamanan Google API dan layanan Google

Menggunakan Identitas Beban Kerja adalah cara yang direkomendasikan untuk mengizinkan otentikasi workload GKE dengan Google API, dan agar administrator menerapkan "hak istimewa terendah" otorisasi menggunakan IAM.

Saat menggunakan Akses Google Pribadi, Workload Identity, dan IAM, Anda dapat mengizinkan Pod workload secara aman untuk melewati gateway keluar dan terhubung langsung pada Google API dan layanan Google.

Menggunakan namespace Kubernetes untuk kontrol administratif

Namespace adalah resource organisasi yang sangat membantu di lingkungan di mana ada banyak pengguna, tim, atau penyewa. Mereka dapat dianggap sebagai alat virtual cluster, dan memberikan tanggung jawab administratif untuk grup Kubernetes resource untuk didelegasikan ke administrator yang berbeda.

Namespace adalah fitur penting untuk mengisolasi kontrol administratif. Namun, alat tersebut secara default tidak menyediakan isolasi node, isolasi bidang data, atau isolasi jaringan.

Cloud Service Mesh membangun di atas namespace Kubernetes dengan menggunakannya sebagai unit sewa dalam sebuah mesh layanan. Kebijakan otorisasi mesh dan resource file bantuan dapat batasi visibilitas dan akses berdasarkan namespace, identitas, dan Lapisan 7 (aplikasi) pada traffic jaringan.

Demikian pula, Anda dapat menggunakan kebijakan jaringan Kubernetes untuk mengizinkan atau menolak jaringan di Lapisan 4 (transportasi).

Menjalankan gateway keluar pada node gateway khusus

Menjalankan gateway keluar pada node dalam penawaran node gateway khusus beberapa keuntungan. Node yang digunakan secara eksternal dapat menggunakan konfigurasi yang di-hardening, dan Anda dapat mengonfigurasi aturan firewall VPC untuk mencegah workload mencapai untuk host eksternal secara langsung. Kumpulan node dapat diskalakan otomatis secara independen menggunakan autoscaler cluster.

Untuk mengizinkan kontrol administratif terpisah dari gateway keluar, deploy gateway tersebut ke namespace istio-egress khusus. Namun, namespace adalah konfigurasi cluster resource Anda tidak dapat digunakan untuk mengontrol node mana yang akan digunakan yang dijalankan. Untuk kontrol deployment, gunakan pemilih node untuk deployment gateway keluar agar berjalan di node yang diberi label yang merupakan anggota kumpulan node gateway.

Memastikan bahwa hanya Pod gateway yang dapat berjalan pada node gateway. Pod lain harus ditolak dari node gateway, jika tidak, kontrol traffic keluar dapat dilewati. Workload dapat dicegah agar tidak berjalan pada node tertentu dengan menggunakan taint dan toleransi. Anda harus mengotori node di kumpulan node gateway dan menambahkan node yang sesuai toleransi terhadap deployment gateway keluar.

Menerapkan aturan firewall VPC ke node tertentu

Anda mengonfigurasi perutean mesh layanan untuk mengarahkan traffic keluar dari workload yang berjalan di kumpulan node default melalui gateway keluar yang berjalan pada kumpulan node gateway. Namun, konfigurasi perutean mesh harus tidak dipercaya sebagai batasan keamanan karena ada berbagai cara di mana dapat mengabaikan {i>proxy<i} mesh.

Untuk mencegah beban kerja aplikasi terhubung langsung ke host eksternal, menerapkan aturan firewall keluar yang dibatasi ke node dalam kumpulan node default. Terapkan aturan firewall terpisah ke node gateway sehingga gateway keluar Pod yang berjalan di dalamnya dapat terhubung ke host eksternal.

Saat membuat aturan firewall VPC, Anda menentukan port dan protokol yang diizinkan atau ditolak oleh aturan {i>firewall<i} dan arah traffic tempat penerapannya. Aturan keluar berlaku untuk lalu lintas keluar dan aturan traffic masuk berlaku untuk traffic masuk. Default untuk traffic keluar adalah allow dan default untuk traffic masuk adalah deny.

Aturan {i>Firewall<i} diterapkan secara berurutan berdasarkan nomor prioritas yang dapat Anda tentukan. Aturan {i>firewall<i} bersifat stateful, yang berarti bahwa jika lalu lintas tertentu dari VM diizinkan, lalu traffic yang kembali menggunakan koneksi yang sama juga diizinkan.

Diagram berikut menunjukkan cara penerapan aturan firewall terpisah ke node di dua kumpulan node berbeda berdasarkan akun layanan yang ditetapkan ke sebuah node. Di beberapa dalam kasus ini, aturan firewall deny all default menolak akses keluar untuk seluruh Jaringan VPC. Agar tidak menimpa aturan {i>firewall<i} default yang penting untuk cluster agar beroperasi, aturan deny all Anda harus menggunakan prioritas rendah seperti 65535. Aturan firewall keluar dengan prioritas yang lebih tinggi dan tambahan diterapkan ke {i>node<i} gateway untuk memungkinkan koneksi langsung ke {i>host<i} eksternal pada port 80 dan 443. Kumpulan node default tidak memiliki akses ke host eksternal.

kumpulan node firewall

Menggunakan kebijakan Jaringan Kubernetes sebagai firewall untuk Pod dan namespace

Gunakan Kebijakan jaringan Kubernetes menerapkan lapisan keamanan ekstra sebagai bagian dari strategi pertahanan mendalam. Kebijakan jaringan mencakup namespace dan beroperasi di Lapisan 4 (transportasi). Dengan kebijakan jaringan, Anda dapat membatasi traffic masuk dan keluar:

  • Di antara namespace
  • Ke Pod dalam namespace
  • Ke porta dan blok IP tertentu.

Setelah kebijakan jaringan memilih Pod dalam namespace, setiap koneksi yang secara eksplisit tidak diizinkan akan ditolak. Saat beberapa kebijakan jaringan diterapkan, hasilnya adalah tambahan dan merupakan gabungan dari kebijakan. Urutan yang menunjukkan kebijakan diterapkan tidak masalah.

Tutorial pendamping menyertakan contoh kebijakan jaringan berikut:

  • Izinkan koneksi keluar dari namespace workload ke Namespace istio-system dan istio-egress. Pod harus dapat terhubung ke istiod dan gateway keluar.
  • Izinkan workload membuat kueri DNS dari namespace workload ke port 53 dalam namespace kube-system.
  • Atau, izinkan beban kerja di namespace yang sama untuk saling terhubung.
  • Secara opsional, izinkan koneksi keluar antara namespace yang digunakan oleh tim aplikasi yang berbeda.
  • Izinkan koneksi keluar dari namespace workload ke VIP untuk Google API (terekspos menggunakan Akses Google Pribadi). Mesh Layanan Cloud menyediakan CA terkelola dan mengeksposnya sebagai API, jadi proxy file bantuan harus dapat terhubung ke sana. Mungkin juga beberapa workload memerlukan akses ke Google API.
  • Mengizinkan koneksi keluar dari namespace workload ke metadata GKE server sehingga {i>proxy<i} file bantuan dan beban kerja itu dapat membuat {i>metadata<i} membuat kueri dan melakukan autentikasi ke Google API.

Secara default, saat proxy file bantuan dimasukkan ke dalam Pod workload, iptables aturan diprogram sehingga {i>proxy<i} menangkap semua TCP masuk dan keluar kemacetan. Namun, seperti yang disebutkan sebelumnya, ada cara bagi beban kerja untuk melewati {i>proxy<i}. Aturan firewall VPC mencegah akses keluar langsung dari yang secara default menjalankan beban kerja. Anda dapat menggunakan kebijakan jaringan Kubernetes untuk memastikan bahwa tidak ada traffic keluar eksternal langsung yang mungkin dilakukan dari namespace workload dan traffic keluar tersebut dapat terjadi ke namespace istio-egress.

Jika Anda juga mengontrol traffic masuk dengan kebijakan jaringan, Anda perlu membuat kebijakan traffic masuk agar sesuai dengan kebijakan traffic keluar.

Konfigurasi dan keamanan Anthos Service Mesh

Workload yang berjalan di mesh layanan tidak diidentifikasi berdasarkan IP-nya untuk alamat internal dan eksternal. Cloud Service Mesh menetapkan identitas yang kuat dan dapat diverifikasi di bentuk sertifikat X.509 dan untuk setiap workload. Komunikasi tepercaya antar-beban kerja ditetapkan menggunakan otentikasi dan enkripsi mutual TLS (mTLS).

Penggunaan autentikasi mTLS dengan identitas yang jelas untuk setiap aplikasi memungkinkan Anda menggunakan kebijakan otorisasi mesh untuk kontrol terperinci atas cara workload dapat berkomunikasi dengan layanan eksternal.

Meskipun traffic dapat meninggalkan mesh langsung dari proxy file bantuan, jika Anda memerlukan kontrol tambahan, sebaiknya arahkan traffic melalui gateway keluar sebagaimana dijelaskan dalam panduan ini.

Mengelola konfigurasi untuk kontrol keluar dalam namespace khusus

Izinkan administrator jaringan untuk mengelola kontrol secara terpusat menggunakan instance Namespace istio-egress untuk konfigurasi mesh terkait keluar. Seperti sebelumnya sebaiknya deploy gateway keluar ke namespace istio-egress. Anda dapat membuat dan mengelola entri layanan, gateway, dan kebijakan otorisasi di namespace ini.

Mewajibkan konfigurasi eksplisit tujuan eksternal

Pastikan bahwa {i>proxy<i} mesh hanya diprogram dengan rute ke host eksternal yang secara eksplisit ditentukan dalam registry mesh layanan. Setel mode kebijakan traffic keluar ke REGISTRY_ONLY secara default resource bantuan untuk setiap namespace. Menyetel kebijakan traffic keluar untuk mesh tidak boleh, dianggap sebagai pengendali perimeter yang aman.

Menentukan tujuan eksternal dengan Entri Layanan

Konfigurasi Entri Layanan untuk secara eksplisit mendaftarkan host eksternal dalam registry layanan mesh. Menurut secara default, entri layanan terlihat oleh semua namespace. Gunakan Atribut eksporTo untuk mengontrol namespace tempat entri layanan dapat dilihat. Entri Layanan menentukan rute keluar yang dikonfigurasi di {i>proxy<i} mesh tetapi harus tidak dianggap sebagai kontrol yang aman untuk menentukan dapat terhubung dengan workload host di atas.

Mengonfigurasi perilaku gateway keluar dengan resource Gateway

Konfigurasikan perilaku load balancing gateway keluar menggunakan Gateway resource Anda Load balancer dapat dikonfigurasi untuk sekumpulan host tertentu, protokol, dan port, serta terkait dengan deployment gateway keluar. Sebagai Misalnya, gateway dapat dikonfigurasi untuk traffic keluar ke porta 80 dan 443 untuk semua {i>host<i} eksternal.

Di Cloud Service Mesh 1.6 dan yang lebih baru, mTLS otomatis diaktifkan secara default. Dengan mTLS otomatis, proxy file bantuan klien secara otomatis mendeteksi apakah memiliki file bantuan. File bantuan klien mengirimkan mTLS ke workload dengan file bantuan dan mengirimkan traffic teks biasa ke workload tanpa file bantuan. Bahkan dengan mTLS otomatis, traffic yang dikirim ke gateway keluar dari proxy file bantuan tidak secara otomatis menggunakan mTLS. Untuk menunjukkan bagaimana koneksi ke gateway keluar harus diamankan, Anda harus mengatur mode TLS pada sumber daya {i>Gateway<i}. Bila memungkinkan, gunakan mTLS untuk koneksi dari proxy file bantuan ke gateway keluar.

Anda dapat mengizinkan beban kerja memulai koneksi TLS (HTTPS) itu sendiri. Jika beban kerja berasal dari koneksi TLS, biasanya di port 443, Anda harus mengonfigurasi gateway untuk menggunakan mode passthrough untuk koneksi pada porta. Namun, jika menggunakan mode passthrough, gateway tidak dapat menerapkan kebijakan otorisasi berdasarkan identitas beban kerja atau properti permintaan terenkripsi. Selain itu, saat ini tidak memungkinkan untuk menggunakan mTLS dan passthrough secara bersamaan.

{i>tls pass through<i}

Mengonfigurasi Layanan Virtual dan Aturan Tujuan untuk mengarahkan traffic melalui gateway

Gunakan Layanan Virtual dan Aturan Tujuan untuk mengonfigurasi perutean traffic dari proxy file bantuan melalui traffic keluar {i>gateway<i} ke tujuan eksternal. Layanan virtual menentukan aturan untuk pencocokan traffic tertentu. Traffic yang cocok kemudian dikirim ke tujuan. Akun aturan dapat menentukan subset (misalnya, gateway keluar atau host eksternal) dan bagaimana lalu lintas harus ditangani saat dirutekan ke tujuan.

Gunakan aturan tujuan tunggal untuk beberapa host tujuan secara eksplisit menentukan cara mengamankan lalu lintas dari {i> proxy file<i} ke {i>gateway<i} harus diamankan. Sebagai dijelaskan sebelumnya, metode yang direkomendasikan adalah agar beban kerja mengirim dan bagi proxy file bantuan untuk memulai koneksi mTLS ke gateway.

Gunakan aturan tujuan untuk setiap host eksternal guna mengonfigurasi gateway keluar untuk 'tingkatkan' permintaan HTTP biasa untuk menggunakan koneksi TLS (HTTPS) saat meneruskan ke destinasinya. Meningkatkan koneksi teks polos ke TLS sering kali disebut sebagai sebagai asal TLS.

Mengontrol cakupan konfigurasi proxy dengan Resource Sidecar

Mengonfigurasi default Resource file bantuan untuk setiap namespace guna mengontrol perilaku proxy file bantuan. Gunakan properti keluar resource Sidecar untuk mengontrol dan meminimalkan host tujuan yang dikonfigurasi di pemroses keluar proxy. Konfigurasi minimal yang umum mungkin sertakan tujuan berikut untuk setiap namespace:

  • Pod dalam namespace yang sama
  • Google API dan Layanan Google
  • Server metadata GKE
  • Host eksternal tertentu yang telah dikonfigurasi menggunakan entri layanan

Konfigurasi pemroses keluar di proxy file bantuan tidak boleh, di sendiri, dianggap sebagai pengendalian keamanan.

Praktik terbaiknya adalah menggunakan resource file bantuan untuk membatasi ukuran proxy konfigurasi Anda. Secara default, setiap proxy file bantuan dalam mesh dikonfigurasi untuk mengizinkan untuk mengirim lalu lintas data ke setiap {i>proxy<i} lainnya. Pemakaian memori file bantuan {i>proxy<i} dan bidang kontrol bisa sangat dikurangi dengan membatasi konfigurasi {i>proxy<i} hanya kepada {i>host<i} yang mereka butuhkan untuk berkomunikasi kami.

Menggunakan Kebijakan Otorisasi untuk mengizinkan atau menolak traffic di gateway keluar

AuthorizationPolicy adalah resource yang memungkinkan Anda mengonfigurasi kebijakan kontrol akses yang terperinci untuk traffic mesh. Anda dapat membuat kebijakan untuk mengizinkan atau menolak traffic berdasarkan properti sumber, tujuan, atau traffic itu sendiri (misalnya, host atau header permintaan HTTP).

Untuk mengizinkan atau menolak koneksi berdasarkan identitas workload sumber atau namespace, koneksi ke gateway keluar harus diotentikasi dengan mTLS. Koneksi dari file bantuan ke gateway keluar tidak otomatis menggunakan mTLS, jadi aturan tujuan untuk koneksi ke gateway harus secara eksplisit menentukan Mode TLS ISTIO_MUTUAL.

Untuk mengizinkan atau menolak permintaan di {i>gateway<i} menggunakan kebijakan otorisasi, workload harus mengirim permintaan HTTP biasa ke tujuan di luar mesh. {i>Proxy<i} file bantuan kemudian dapat meneruskan permintaan ke {i>gateway<i} menggunakan mTLS dan {i>gateway<i} dapat memulai koneksi TLS yang aman ke {i>host<i} eksternal.

Untuk mendukung persyaratan traffic keluar dari berbagai tim dan aplikasi, mengonfigurasi "hak istimewa terendah" yang terpisah otorisasi per namespace atau sebagian besar workload standar dan berbasis cloud. Misalnya, kebijakan yang berbeda dapat diterapkan di gateway keluar dengan menentukan aturan berdasarkan namespace workload sumber dan atribut permintaan sebagai berikut:

  • Jika namespace sumber adalah team-x DAN host tujuan adalah example.com, lalu izinkan traffic.

    contoh kebijakan otorisasi

  • Jika namespace sumber adalah team-y DAN host tujuan adalah httpbin.org DAN jalurnya adalah /status/418, lalu allow traffic.

    kebijakan otorisasi menggunakan httpbin

Semua permintaan lainnya ditolak.

Konfigurasikan gateway keluar untuk memulai koneksi TLS (HTTPS) ke tujuan

Konfigurasikan aturan tujuan agar gateway keluar berasal dari TLS (HTTPS) koneksi ke tujuan eksternal.

Agar asal TLS di gateway keluar dapat berfungsi, workload harus mengirim data biasa Permintaan HTTP. Jika beban kerja memulai TLS, gateway keluar akan menggabungkan TLS pada atas TLS asli, dan permintaan ke layanan eksternal akan gagal.

Karena beban kerja mengirim permintaan HTTP biasa, konfigurasikan metode {i>sidecar proxy<i} untuk membuat koneksi mTLS saat mengirimkannya ke {i>gateway<i}. Gateway keluar kemudian menghentikan koneksi mTLS dan memulai Koneksi TLS (HTTPS) ke host tujuan.

Asal TLS di gateway keluar

Pendekatan ini memiliki beberapa manfaat:

  • Anda dapat menggunakan kebijakan otorisasi untuk mengizinkan atau menolak lalu lintas berdasarkan dari workload sumber dan permintaan.

  • Traffic antara Pod workload dan gateway keluar dienkripsi dan diotentikasi (mTLS) dan traffic antara gateway keluar dan tujuan dienkripsi (TLS/HTTPS).

  • Di dalam mesh, proxy file bantuan dapat mengamati dan bertindak berdasarkan properti permintaan HTTP (misalnya, header), yang memberikan opsi tambahan untuk kemampuan observasi dan kontrol.

  • Kode aplikasi dapat disederhanakan. Developer tidak perlu menangani sertifikat atau library klien HTTPS, dan mesh layanan hanya dapat memastikan komunikasi yang aman dengan penyandian yang standar dan mutakhir.

  • Koneksi TLS tempat gateway keluar berasal ke layanan eksternal dapat digunakan kembali untuk traffic dari banyak Pod. Penggunaan kembali koneksi lebih dan mengurangi risiko batas koneksi tercapai.

DNS, nama host, dan karakter pengganti

Saat mengarahkan, menolak, atau mengizinkan lalu lintas berdasarkan {i>host<i} tujuan, Anda harus memiliki kepercayaan penuh terhadap integritas sistem DNS Anda untuk menyelesaikan nama DNS ke alamat IP yang benar. Di cluster Kubernetes Engine, DNS Kubernetes menangani kueri DNS dan kemudian mendelegasikan kueri eksternal ke GKE server metadata dan DNS Internal. Setel atribut resolusi entri layanan ke DNS saat mengarahkan ke {i>host<i} eksternal, sehingga file bantuan {i>proxy<i} bertanggung jawab untuk membuat kueri DNS.

Cloud Service Mesh dapat merutekan traffic berdasarkan host karakter pengganti. Kasus yang paling sederhana adalah karakter pengganti untuk {i>host<i} yang memiliki nama yang sama dan di-{i>host <i}di satu kumpulan yang sama server. Misalnya, jika satu kumpulan server dapat menyalurkan domain cocok dengan *.example.com, host karakter pengganti dapat digunakan.

Gateway keluar standar tidak dapat diteruskan berdasarkan aturan yang lebih umum dan arbitrer host karakter pengganti (misalnya *.com) karena batasan tertentu dari Envoy proxy yang digunakan oleh Istio. Envoy hanya dapat merutekan lalu lintas ke {i>host<i} yang telah ditentukan sebelumnya, yang telah ditetapkan sebelumnya, atau ke alamat IP tujuan asli dari permintaan. Saat menggunakan gateway keluar, IP tujuan asli permintaan akan hilang karena diganti dengan IP {i>gateway<i} dan tujuan arbitrer host tidak dapat dikonfigurasi sebelumnya.

Penegakan administratif terhadap kebijakan

Menggunakan Role Based Access Control (RBAC) Kubernetes

Hanya administrator yang diotorisasi yang dapat mengonfigurasi kontrol keluar. Konfigurasi Role Based Access Control (RBAC) Kubernetes untuk menghindari pengelakan tanpa izin atas kontrol traffic keluar. Terapkan peran RBAC sehingga hanya administrator jaringan yang dapat mengelola namespace istio-egress,istio-system, dan kube-system serta resource berikut:

  • Sidecar
  • ServiceEntry
  • Gateway
  • AuthorizationPolicy
  • NetworkPolicy

Membatasi penggunaan toleransi

Sebagai dijelaskan sebelumnya Anda dapat menggunakan taint dan toleransi untuk mencegah Pod workload di-deploy pada node gateway. Namun, secara default, tidak ada yang dapat mencegah beban kerja agar tidak di-deploy dengan toleransi node gateway untuk mengabaikan kontrol traffic keluar. Jika memungkinkan untuk menerapkan kebijakan yang terpusat kontrol administratif atas pipeline deployment, Anda dapat menggunakannya untuk menerapkan batasan pada penggunaan kunci toleransi tertentu.

Pendekatan lain adalah dengan menggunakan Kontrol penerimaan Kubernetes. Anthos mencakup komponen yang disebut Pengontrol Kebijakan yang berfungsi sebagai pengontrol penerimaan Kubernetes dan memvalidasi deployment tersebut memenuhi batasan kebijakan yang Anda tentukan.

Memastikan traffic dicatat

Anda sering kali perlu mencatat semua traffic yang melintasi perimeter jaringan. Pencatatan lalu lintas sangat penting jika Anda harus dapat menunjukkan kepatuhan terhadap peraturan perlindungan data umum. Log lalu lintas dikirim langsung ke Cloud Logging dan dapat diakses dari dasbor Cloud Service Mesh di Konsol Google Cloud. Anda dapat memfilter log berdasarkan berbagai atribut, termasuk sumber/tujuan, identitas, namespace, atribut traffic, dan latensi.

Untuk memudahkan proses debug dengan kubectl, aktifkan logging traffic ke stdout saat menginstal Cloud Service Mesh dengan menggunakan setelan accessLogFile.

Log audit dikirim ke Cloud Logging setiap kali CA Mesh membuat sertifikat untuk sebagian besar workload standar dan berbasis cloud.

Pertimbangkan untuk menggunakan cluster terpisah untuk gateway keluar dalam mesh multi-cluster

Cloud Service Mesh dapat di-deploy di lebih dari satu cluster GKE. Mesh multi-cluster memperkenalkan kemungkinan baru untuk mengontrol traffic keluar dan juga beberapa batasan.

Daripada men-deploy gateway keluar ke kumpulan node khusus, Anda dapat men-deploy gateway ke cluster terpisah yang tidak menjalankan beban kerja reguler. Menggunakan cluster terpisah menyediakan isolasi serupa antara workload dan gateway, sekaligus menghindari kebutuhan akan taint dan toleransi. Gateway keluar dapat berbagi cluster terpisah dengan gateway masuk atau layanan pusat lainnya.

Anda dapat menggunakan kebijakan jaringan Kubernetes dalam deployment multi-cluster, tetapi karena beroperasi pada Lapisan 4 (transportasi), mereka tidak dapat membatasi lintas cluster koneksi berdasarkan Pod atau namespace tujuan.

Langkah selanjutnya