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

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

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

Pengantar

Pendekatan tradisional untuk keamanan jaringan adalah menentukan perimeter keamanan di sekitar sekelompok aplikasi. Firewall digunakan di perimeter ini untuk mengizinkan atau menolak traffic berdasarkan alamat IP sumber dan tujuan, sekaligus memercayai aplikasi dan traffic yang terdapat dalam perimeter. Namun, kepercayaan ini melibatkan risiko. Orang dalam yang berbahaya, atau siapa saja yang membahayakan perimeter dapat bergerak bebas di dalam jaringan, mengakses dan mengekspor data, menyerang sistem pihak ketiga, dan mengganggu sistem administrasi.

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

• Alamat IP pod tidak mewakili identitas beban kerja yang membuat koneksi dengan memadai. Di lingkungan Kubernetes, alamat IP Pod ditetapkan secara sementara dan sering didaur ulang saat Pod muncul dan hilang.

• Sering kali tidak mungkin mengidentifikasi kumpulan alamat IP yang kecil dan tetap untuk host tujuan tertentu. Alamat IP sering berubah, bervariasi menurut wilayah, dan dapat diambil dari rentang yang besar atau mewakili cache, proxy, atau CDN.

• Beberapa tim yang menggunakan cluster multi-tenant yang sama, dengan rentang IP sumber bersama, mungkin memiliki persyaratan konektivitas eksternal yang berbeda.

Cloud Service Mesh adalah mesh layanan yang terkelola sepenuhnya di Google Cloud berdasarkan mesh layanan Istio open source. Mesh layanan menyediakan cara yang seragam untuk menghubungkan, mengelola, dan mengamankan komunikasi aplikasi. Mesh layanan menggunakan pendekatan yang berfokus pada aplikasi dan menggunakan identitas aplikasi tepercaya, bukan pendekatan yang berfokus pada IP jaringan.

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

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

Arsitektur defense-in-depth

Diagram di bawah menunjukkan arsitektur yang menggunakan pendekatan defense-in-depth untuk kontrol terperinci traffic keluar untuk cluster yang digunakan oleh beberapa tim. Kontrol ini didasarkan pada kontrol jaringan Lapisan 4 (transport) dan Lapisan 7 (aplikasi).

Arsitektur ini menggunakan resource dan kontrol berikut:

• Cluster GKE pribadi: Node di cluster GKE pribadi hanya memiliki alamat IP internal dan tidak terhubung ke internet secara default.

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

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

• Kumpulan node GKE dengan akun layanan yang berbeda: Hal ini memungkinkan Anda mengonfigurasi aturan firewall yang berbeda untuk diterapkan, bergantung pada kumpulan node tempat node berada.

• namespaces Kubernetes: Anda membuat namespace untuk setiap tim guna memberikan isolasi dan kontrol administratif yang didelegasikan. Administrator jaringan menggunakan namespace khusus untuk men-deploy gateway keluar dan mengonfigurasi pemilihan rute ke host eksternal.

• Kebijakan jaringan Kubernetes: Kebijakan jaringan memungkinkan Anda menerapkan kontrol Lapisan 4 ke Pod. Setiap kebijakan jaringan tercakup dalam suatu namespace dan dapat dicakup secara lebih terperinci untuk Pod tertentu dalam namespace.

• Gateway keluar: Traffic yang keluar dari Pod dalam mesh diarahkan melalui proxy gateway keluar khusus yang berjalan di node khusus. Anda men-deploy gateway keluar dengan penskalaan otomatis Pod horizontal sehingga jumlah replika diskalakan naik dan turun dengan traffic.

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

• Resource sidecar: Anda menggunakan resource Sidecar untuk mengontrol cakupan konfigurasi proxy sidecar yang berjalan di setiap Pod workload. Anda dapat menggunakan resource Sidecar untuk mengonfigurasi namespace, Pod, dan layanan eksternal yang terlihat oleh beban kerja.

• 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 workload tertentu dengan mengikuti prinsip hak istimewa terendah, tanpa perlu menangani secret.

Mengonfigurasi kontrol traffic keluar

Jika Anda menggunakan gateway keluar untuk mengamankan traffic keluar dari mesh, sebaiknya konfigurasi kontrol defense-in-depth yang dijelaskan di bagian ini.

Menggunakan GKE Pribadi dengan Cloud NAT

Jika keamanan penting, persyaratan pertama bagi banyak organisasi adalah menghindari penetapan alamat IP publik ke beban kerja mereka. Cluster GKE pribadi memenuhi persyaratan ini. Anda dapat mengonfigurasi mode VPC Native di cluster pribadi sehingga Pod dan layanan diberi alamat IP dari rentang sekunder di VPC. Alamat IP Pod Native VPC dapat dirutekan secara native dalam jaringan VPC.

Beberapa beban kerja mungkin memerlukan akses ke layanan di luar jaringan VPC dan ke internet. Untuk mengizinkan beban kerja terhubung ke host eksternal tanpa perlu memiliki alamat IP publik, konfigurasikan Cloud NAT untuk menyediakan penafsiran alamat jaringan (NAT).

Pastikan Cloud NAT dikonfigurasi sehingga gateway keluar dapat membuat koneksi simultan dalam jumlah yang memadai ke tujuan eksternal. Anda dapat menghindari kehabisan port dan masalah terkait penundaan penggunaan kembali koneksi dengan menetapkan jumlah minimum port per VM secara 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

Kemungkinan beban kerja Anda harus memiliki akses ke Google API dan layanan Google. Gunakan Akses Google Pribadi dengan Zona DNS kustom untuk mengizinkan konektivitas dari subnet VPC pribadi ke Google API menggunakan kumpulan 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 lebih mengamankan Google API dan layanan Google

Menggunakan Workload Identity adalah cara yang direkomendasikan untuk mengizinkan beban kerja GKE melakukan autentikasi dengan Google API dan bagi administrator untuk menerapkan kontrol otorisasi "hak istimewa terendah" menggunakan IAM.

Saat menggunakan Akses Google Pribadi, Workload Identity, dan IAM, Anda dapat mengizinkan Pod beban kerja dengan aman untuk mengabaikan gateway keluar dan terhubung langsung ke Google API dan layanan.

Menggunakan namespace Kubernetes untuk kontrol administratif

Namespace adalah resource organisasi yang berguna di lingkungan yang memiliki banyak pengguna, tim, atau tenant. Fleet dapat dianggap sebagai cluster virtual, dan memungkinkan tanggung jawab administratif untuk grup resource Kubernetes didelegasikan kepada administrator yang berbeda.

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

Cloud Service Mesh dibuat di namespace Kubernetes dengan menggunakannya sebagai unit tenancy dalam mesh layanan. Kebijakan otorisasi mesh dan resource sidecar dapat membatasi visibilitas dan akses berdasarkan namespace, identitas, dan atribut Lapisan 7 (aplikasi) dari traffic jaringan.

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

Menjalankan gateway keluar di node gateway khusus

Menjalankan gateway keluar di node dalam node pool gateway khusus menawarkan beberapa keuntungan. Node yang menghadap ke luar dapat menggunakan konfigurasi yang di-harden, dan Anda dapat mengonfigurasi aturan firewall VPC untuk mencegah workload menjangkau host eksternal secara langsung. Node pool dapat diskalakan secara otomatis secara independen menggunakan autoscaler cluster.

Untuk mengizinkan kontrol administratif terpisah dari gateway keluar, deploy gateway ke namespace istio-egress khusus. Namun, namespace adalah resource seluruh cluster dan tidak dapat digunakan untuk mengontrol node tempat deployment berjalan. Untuk kontrol deployment, gunakan pemilih node untuk deployment gateway keluar sehingga berjalan di node yang diberi label sebagai anggota node pool gateway.

Pastikan hanya Pod gateway yang dapat berjalan di node gateway. Pod lain harus ditolak dari node gateway, jika tidak, kontrol keluar dapat diabaikan. Workload dapat dicegah agar tidak berjalan di node tertentu dengan menggunakan taint dan toleransi. Anda harus menambahkan taint ke node di node pool gateway dan menambahkan toleransi yang sesuai ke deployment gateway keluar.

Penting: Batasi toleransi deployment gateway keluar sehingga beban kerja tidak dapat di-deploy ke node gateway. Opsi untuk membatasi penggunaan toleransi akan dijelaskan nanti dalam panduan ini.

Menerapkan aturan firewall VPC ke node tertentu

Anda mengonfigurasi pemilihan rute mesh layanan untuk mengarahkan traffic keluar dari beban kerja yang berjalan di node pool default melalui gateway keluar yang berjalan di node pool gateway. Namun, konfigurasi perutean mesh tidak boleh dipercaya sebagai batas keamanan karena ada berbagai cara beban kerja dapat mengabaikan proxy mesh.

Untuk mencegah beban kerja aplikasi terhubung langsung ke host eksternal, terapkan aturan firewall keluar yang membatasi ke node di node pool default. Terapkan aturan firewall terpisah ke node gateway sehingga Pod gateway keluar 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 firewall dan arah traffic yang diterapkan. Aturan keluar berlaku untuk traffic keluar dan aturan masuk berlaku untuk traffic masuk. Default untuk egress adalah allow dan default untuk ingress adalah deny.

Aturan firewall diterapkan secara berurutan berdasarkan nomor prioritas yang dapat Anda tentukan. Aturan firewall bersifat stateful, yang berarti jika traffic tertentu dari VM diizinkan, traffic kembali menggunakan koneksi yang sama juga diizinkan.

Diagram berikut menunjukkan cara aturan firewall terpisah dapat diterapkan ke node di dua node pool yang berbeda berdasarkan akun layanan yang ditetapkan ke node. Dalam hal ini, aturan firewall deny all default menolak akses keluar untuk seluruh VPC. Untuk menghindari penggantian aturan firewall default yang penting bagi cluster Anda untuk beroperasi, aturan deny all harus menggunakan prioritas rendah seperti 65535. Aturan firewall egress tambahan dan prioritas lebih tinggi diterapkan ke node gateway untuk memungkinkannya terhubung langsung ke host eksternal di port 80 dan 443. Kumpulan node default tidak memiliki akses ke host eksternal.

Menggunakan kebijakan Jaringan Kubernetes sebagai firewall untuk Pod dan namespace

Gunakan kebijakan jaringan Kubernetes untuk menerapkan lapisan keamanan tambahan sebagai bagian dari strategi defense-in-depth. Kebijakan jaringan dicakupkan ke namespace dan beroperasi di Lapisan 4 (transpor). Dengan kebijakan jaringan, Anda dapat membatasi traffic masuk dan keluar:

• Antar-namespace
• Ke Pod dalam namespace
• Ke port dan blok IP tertentu.

Setelah kebijakan jaringan memilih Pod di namespace, koneksi apa pun yang tidak diizinkan secara eksplisit akan ditolak. Jika beberapa kebijakan jaringan diterapkan, hasilnya bersifat tambahan dan merupakan gabungan dari kebijakan tersebut. Urutan penerapan kebijakan tidak menjadi masalah.

Beberapa contoh kebijakan jaringan meliputi:

• Izinkan koneksi keluar dari namespace workload ke namespace istio-system dan istio-egress. Pod harus dapat terhubung ke bidang kontrol dan gateway keluar.
• Izinkan workload membuat kueri DNS dari namespace workload ke port 53 di namespace kube-system.
• Atau, izinkan workload di namespace yang sama untuk terhubung satu sama lain.
• Secara opsional, izinkan koneksi keluar antara namespace yang digunakan oleh tim aplikasi yang berbeda.
• Izinkan koneksi keluar dari namespace beban kerja ke VIP untuk Google API (ditampilkan menggunakan Akses Google Pribadi). Cloud Service Mesh menyediakan CA terkelola dan mengeksposnya sebagai API, sehingga proxy sidecar harus dapat terhubung ke CA tersebut. Ada kemungkinan juga bahwa beberapa beban kerja memerlukan akses ke Google API.
• Izinkan koneksi keluar dari namespace beban kerja ke server metadata GKE sehingga proxy sidecar dan beban kerja dapat membuat kueri metadata dan mengautentikasi ke Google API.

Secara default, saat proxy sidecar dimasukkan ke dalam Pod beban kerja, aturan iptables diprogram sehingga proxy menangkap semua traffic TCP masuk dan keluar. Namun, seperti yang disebutkan sebelumnya, ada cara bagi workload untuk mengabaikan proxy. Aturan firewall VPC mencegah akses keluar langsung dari node default yang menjalankan workload. Anda dapat menggunakan kebijakan jaringan Kubernetes untuk memastikan bahwa tidak ada egress eksternal langsung dari namespace workload dan bahwa egress dapat dilakukan 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 Service Mesh

Beban kerja yang berjalan di mesh layanan tidak diidentifikasi berdasarkan alamat IP-nya. Cloud Service Mesh menetapkan identitas yang kuat dan dapat diverifikasi dalam bentuk sertifikat dan kunci X.509 untuk setiap beban kerja. Komunikasi tepercaya antar-workload dibuat menggunakan koneksi TLS bersama (mTLS) yang diautentikasi dan dienkripsi.

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

Meskipun traffic dapat keluar dari mesh langsung dari proxy sidecar, jika Anda memerlukan kontrol tambahan, sebaiknya arahkan traffic melalui gateway keluar seperti yang dijelaskan dalam panduan ini.

Mengelola konfigurasi untuk kontrol keluar di namespace khusus

Mengizinkan administrator jaringan mengelola kontrol secara terpusat menggunakan namespace istio-egress khusus untuk konfigurasi mesh terkait keluar. Seperti yang direkomendasikan sebelumnya, Anda men-deploy gateway keluar ke namespace istio-egress. Anda dapat membuat dan mengelola entri layanan, gateway, dan kebijakan otorisasi di namespace ini.

Penting: Untuk mengonfigurasi gateway dan bidang kontrol mesh, penginstal Cloud Service Mesh akan membuat ConfigMap Kubernetes di namespace istio-system. Jika menginstal gateway di namespace yang berbeda, Anda bertanggung jawab untuk menyalin ConfigMap ke namespace tersebut dan untuk mempertahankan setelan di dalamnya saat mengupgrade. Versi Cloud Service Mesh berikutnya akan mengelola konfigurasi gateway secara otomatis.

Mewajibkan konfigurasi eksplisit untuk tujuan eksternal

Pastikan proxy mesh hanya diprogram dengan rute ke host eksternal yang ditentukan secara eksplisit di registry mesh layanan. Tetapkan mode kebijakan traffic keluar ke REGISTRY_ONLY dalam resource sidecar default untuk setiap namespace. Menetapkan kebijakan traffic keluar untuk mesh tidak boleh, sendirinya, dianggap sebagai kontrol perimeter yang aman.

Menentukan tujuan eksternal dengan Entri Layanan

Konfigurasikan Entri Layanan untuk mendaftarkan host eksternal secara eksplisit di registry layanan mesh. Secara default, entri layanan dapat dilihat oleh semua namespace. Gunakan atribut exportTo untuk mengontrol namespace yang dapat melihat entri layanan. Entri Layanan menentukan rute keluar yang dikonfigurasi di proxy mesh, tetapi tidak boleh dianggap sebagai kontrol aman untuk menentukan host eksternal yang dapat dihubungkan oleh workload.

Mengonfigurasi perilaku gateway keluar dengan resource Gateway

Konfigurasikan perilaku load balancing gateway keluar menggunakan resource Gateway. Load balancer dapat dikonfigurasi untuk kumpulan host, protokol, dan port tertentu serta dikaitkan dengan deployment gateway keluar. Misalnya, gateway dapat dikonfigurasi untuk traffic keluar ke port 80 dan 443 untuk setiap host eksternal.

Di Cloud Service Mesh, mTLS otomatis diaktifkan secara default. Dengan mTLS otomatis, proxy sidecar klien akan otomatis mendeteksi apakah server memiliki sidecar. Sidecar klien mengirim mTLS ke workload dengan sidecar dan mengirim traffic teks biasa ke workload tanpa sidecar. Meskipun dengan mTLS otomatis, traffic yang dikirim ke gateway keluar dari proxy sidecar tidak otomatis menggunakan mTLS. Untuk menunjukkan cara mengamankan koneksi ke gateway keluar, Anda harus menetapkan mode TLS di resource Gateway. Jika memungkinkan, gunakan mTLS untuk koneksi dari proxy sidecar ke gateway keluar.

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

Mengonfigurasi Layanan Virtual dan Aturan Tujuan untuk merutekan traffic melalui gateway

Gunakan Layanan Virtual dan Aturan Tujuan untuk mengonfigurasi pemilihan rute traffic dari proxy file bantuan melalui gateway keluar ke tujuan eksternal. Layanan virtual menentukan aturan untuk mencocokkan traffic tertentu. Traffic yang cocok kemudian dikirim ke tujuan. Aturan tujuan dapat menentukan subset (misalnya, gateway keluar atau host eksternal) dan cara traffic harus ditangani saat dirutekan ke tujuan.

Gunakan satu aturan tujuan untuk beberapa host tujuan untuk menentukan secara eksplisit cara mengamankan traffic dari proxy file bantuan ke gateway. Seperti yang dijelaskan sebelumnya, metode yang lebih disukai adalah untuk beban kerja mengirim permintaan teks biasa dan untuk proxy sidecar membuat koneksi mTLS ke gateway.

Gunakan aturan tujuan untuk setiap host eksternal guna mengonfigurasi gateway keluar untuk 'mengupgrade' permintaan HTTP biasa agar menggunakan koneksi TLS (HTTPS) saat meneruskan ke tujuan. Mengupgrade koneksi teks biasa ke TLS sering kali disebut sebagai originasi TLS.

Mengontrol cakupan konfigurasi proxy dengan Resource Sidecar

Konfigurasikan Resource sidecar default untuk setiap namespace guna mengontrol perilaku proxy sidecar. Gunakan properti egress resource Sidecar untuk mengontrol dan meminimalkan host tujuan yang dikonfigurasi di pemroses keluar proxy. Konfigurasi minimal standar mungkin menyertakan tujuan berikut untuk setiap namespace:

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

Konfigurasi pemroses keluar di proxy file bantuan tidak boleh dianggap sebagai kontrol keamanan.

Praktik terbaiknya adalah menggunakan resource Sidecar untuk membatasi ukuran konfigurasi proxy. Secara default, setiap proxy sidecar dalam mesh dikonfigurasi untuk mengizinkan proxy mengirim traffic ke setiap proxy lainnya. Konsumsi memori proxy sidecar dan bidang kontrol dapat dikurangi secara signifikan dengan membatasi konfigurasi proxy hanya ke host yang perlu dikomunikasikan oleh proxy.

Menggunakan Kebijakan Otorisasi untuk mengizinkan atau menolak traffic di gateway keluar

AuthorizationPolicy adalah resource yang memungkinkan Anda mengonfigurasi kebijakan kontrol akses 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 atau namespace beban kerja sumber, koneksi ke gateway keluar harus diautentikasi dengan mTLS. Koneksi dari sidecar ke gateway keluar tidak otomatis menggunakan mTLS, sehingga aturan tujuan untuk koneksi ke gateway harus secara eksplisit menentukan mode TLS ISTIO_MUTUAL.

Untuk mengizinkan atau menolak permintaan di gateway menggunakan kebijakan otorisasi, beban kerja harus mengirim permintaan HTTP biasa ke tujuan di luar mesh. Kemudian, proxy sidecar dapat meneruskan permintaan ke gateway menggunakan mTLS dan gateway dapat memulai koneksi TLS yang aman ke host eksternal.

Untuk mendukung persyaratan keluar dari berbagai tim dan aplikasi, konfigurasi kebijakan otorisasi "hak istimewa terendah" terpisah per namespace atau workload. Misalnya, kebijakan yang berbeda dapat diterapkan di gateway keluar dengan menentukan aturan berdasarkan namespace beban kerja sumber dan atribut permintaan sebagai berikut:

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

  

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

  

Semua permintaan lainnya ditolak.

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

Konfigurasikan aturan tujuan sehingga gateway keluar memulai koneksi TLS (HTTPS) ke tujuan eksternal.

Agar TLS origination di gateway keluar berfungsi, workload harus mengirim permintaan HTTP biasa. Jika workload memulai TLS, gateway keluar akan menggabungkan TLS di atas TLS asli, dan permintaan ke layanan eksternal akan gagal.

Karena beban kerja mengirim permintaan HTTP biasa, konfigurasikan proxy sidecar beban kerja untuk membuat koneksi mTLS saat mengirimnya ke gateway. Gateway keluar kemudian menghentikan koneksi mTLS dan memulai koneksi TLS (HTTPS) reguler ke host tujuan.

Pendekatan ini memiliki beberapa manfaat:

• Anda dapat menggunakan kebijakan otorisasi untuk mengizinkan atau menolak traffic berdasarkan atribut workload sumber dan permintaan.

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

• Di dalam mesh, proxy sidecar dapat mengamati dan menindaklanjuti properti permintaan HTTP (misalnya, header), yang memberikan opsi tambahan untuk observasi dan kontrol.

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

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

DNS, nama host, dan karakter pengganti

Saat merutekan, menolak, atau mengizinkan traffic berdasarkan host tujuan, Anda harus memiliki kepercayaan penuh pada integritas sistem DNS untuk me-resolve nama DNS ke alamat IP yang benar. Di cluster Kubernetes Engine, layanan DNS Kubernetes menangani kueri DNS dan pada gilirannya mendelegasikan kueri eksternal ke server metadata GKE dan DNS Internal. Tetapkan atribut resolusi entri layanan ke DNS saat merutekan ke host eksternal, sehingga proxy sidecar bertanggung jawab untuk membuat kueri DNS.

Cloud Service Mesh dapat merutekan traffic berdasarkan host karakter pengganti. Kasus paling sederhana adalah karakter pengganti untuk host yang memiliki nama yang sama dan dihosting di kumpulan server yang sama. Misalnya, jika satu kumpulan server dapat menayangkan domain yang dicocokkan oleh *.example.com, host karakter pengganti dapat digunakan.

Gateway egress standar tidak dapat meneruskan berdasarkan host karakter pengganti yang lebih umum dan arbitrer (misalnya *.com) karena batasan tertentu pada proxy Envoy yang digunakan oleh Istio. Envoy hanya dapat merutekan traffic ke host yang telah ditentukan, alamat IP yang telah ditentukan, atau ke alamat IP tujuan asli permintaan. Saat menggunakan gateway keluar, IP tujuan asli permintaan akan hilang karena diganti dengan IP gateway dan host tujuan arbitrer tidak dapat dikonfigurasi sebelumnya.

Penegakan kebijakan administratif

Menggunakan Kontrol Akses Berbasis Peran (RBAC) Kubernetes

Hanya administrator yang diberi otorisasi yang dapat mengonfigurasi kontrol keluar. Konfigurasikan Kontrol Akses Berbasis Peran (RBAC) Kubernetes untuk menghindari pengabaian kontrol keluar yang tidak sah. Terapkan peran RBAC sehingga hanya administrator jaringan yang dapat mengelola namespace istio-egress,istio-system,, dankube-system serta resource berikut:

• Sidecar
• ServiceEntry
• Gateway
• AuthorizationPolicy
• NetworkPolicy

Membatasi penggunaan toleransi

Seperti yang dijelaskan sebelumnya, Anda dapat menggunakan taint dan toleransi untuk mencegah Pod workload di-deploy di node gateway. Namun, secara default, tidak ada yang mencegah deployment workload dengan toleransi untuk node gateway sehingga kontrol keluar dapat dilewati. Jika memungkinkan untuk menerapkan kontrol administrative terpusat atas pipeline deployment, Anda dapat menggunakannya untuk menerapkan batasan pada penggunaan kunci toleransi tertentu.

Pendekatan lainnya adalah menggunakan kontrol akses Kubernetes. Anthos menyertakan komponen yang disebut Pengontrol Kebijakan yang berfungsi sebagai pengontrol penerimaan Kubernetes dan memvalidasi bahwa deployment memenuhi batasan kebijakan yang Anda tentukan.

Memastikan traffic dicatat

Sering kali perlu mencatat semua traffic yang melintasi perimeter jaringan. Pencatatan traffic sangat penting jika Anda harus dapat menunjukkan kepatuhan terhadap peraturan perlindungan data umum. Log traffic 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 memungkinkan proses debug yang mudah dengan kubectl, aktifkan logging traffic ke stdout saat menginstal Cloud Service Mesh menggunakan setelan accessLogFile.

Log audit dikirim ke Cloud Logging setiap kali CA Mesh membuat sertifikat untuk beban kerja.

Pertimbangkan untuk menggunakan cluster terpisah untuk gateway keluar di 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 egress ke kumpulan node khusus, Anda dapat men-deploy gateway ke cluster terpisah yang tidak menjalankan workload reguler. Penggunaan cluster terpisah memberikan isolasi yang serupa antara workload dan gateway, sekaligus menghindari kebutuhan akan taint dan toleransi. Gateway keluar dapat membagikan cluster terpisah dengan gateway masuk atau layanan pusat lainnya.

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

Langkah selanjutnya

• Baca panduan hardening GKE
• Pelajari cara mengelola konfigurasi dan kebijakan di seluruh infrastruktur Anda dengan Anthos Configuration Management
• Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.