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 lain 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 pengiriman software. Kontrol yang dijelaskan di sini mungkin sangat berguna 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 ada dalam perimeter. Namun, kepercayaan ini melibatkan risiko. Orang dalam yang berbahaya, atau siapa pun yang membobol perimeter, dapat bergerak bebas di dalam jaringan, mengakses dan mengeksfiltrasi data, menyerang sistem pihak ketiga, serta mengganggu sistem administrasi.

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

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

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

• Beberapa tim yang berbagi 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. Service mesh 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 terhadap perilaku jaringan.

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

Arsitektur defense-in-depth

Diagram di bawah menunjukkan arsitektur yang menerapkan pendekatan pertahanan mendalam untuk kontrol traffic keluar yang terperinci bagi cluster yang digunakan oleh beberapa tim. Kontrol ini didasarkan pada kontrol jaringan Lapisan 4 (transportasi) 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 Layer 4 (Transportasi) pada 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.

• Namespace Kubernetes: Anda membuat namespace untuk setiap tim guna menyediakan 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 lebih baik untuk Pod tertentu dalam suatu 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 egress dengan penskalaan otomatis Pod horizontal sehingga jumlah replika dapat ditingkatkan dan diturunkan sesuai 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 menarik 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 keluar

Jika Anda menggunakan gateway keluar untuk mengamankan traffic keluar dari mesh, sebaiknya Anda mengonfigurasi kontrol pertahanan mendalam yang dijelaskan di bagian ini.

Menggunakan GKE Pribadi dengan Cloud NAT

Jika keamanan penting, persyaratan pertama dari 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 memerlukan alamat IP publik, konfigurasikan Cloud NAT untuk menyediakan penafsiran alamat jaringan (NAT).

Pastikan Cloud NAT dikonfigurasi sehingga gateway keluar dapat membuat koneksi simultan yang memadai ke tujuan eksternal. Anda dapat menghindari kelelahan port 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

Kemungkinan beban kerja Anda perlu memiliki akses ke API dan layanan Google. Gunakan Akses Google Pribadi dengan zona DNS Kustom untuk mengizinkan konektivitas dari subnet VPC pribadi ke Google API menggunakan serangkaian empat alamat IP. Saat menggunakan alamat IP ini, Pod tidak perlu memiliki alamat IP eksternal dan traffic tidak pernah meninggalkan 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 API dan layanan Google

Penggunaan 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 workload dengan aman untuk melewati gateway keluar dan terhubung langsung ke Google API dan layanan Google.

Menggunakan namespace Kubernetes untuk kontrol administratif

Namespace adalah resource organisasi yang berguna dalam lingkungan yang memiliki banyak pengguna, tim, atau tenant. Namespace 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 dibangun di atas namespace Kubernetes dengan menggunakannya sebagai unit kepemilikan dalam mesh layanan. Kebijakan otorisasi mesh dan resource sidecar dapat membatasi visibilitas dan akses berdasarkan namespace, identitas, dan atribut traffic jaringan Lapisan 7 (aplikasi).

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

Menjalankan gateway keluar di node gateway khusus

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

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

Pastikan hanya Pod gateway yang dapat berjalan di node gateway. Pod lain harus dihindari dari node gateway, jika tidak, kontrol keluar dapat dilewati. 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.

Menerapkan aturan firewall VPC ke node tertentu

Anda mengonfigurasi perutean 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 yang dapat digunakan beban kerja untuk melewati proxy mesh.

Untuk mencegah beban kerja aplikasi terhubung langsung ke host eksternal, terapkan aturan firewall keluar yang ketat ke node di node pool default. Terapkan aturan firewall terpisah ke node gateway sehingga Pod gateway keluar yang berjalan di node tersebut dapat terhubung ke host eksternal.

Saat membuat aturan firewall VPC, Anda menentukan port dan protokol yang diizinkan atau ditolak oleh aturan firewall serta arah traffic yang berlaku. 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 bahwa jika traffic tertentu dari VM diizinkan, maka traffic kembali menggunakan koneksi yang sama juga diizinkan.

Diagram berikut menunjukkan cara menerapkan aturan firewall terpisah ke node dalam dua node pool 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 agar cluster Anda dapat beroperasi, aturan deny all Anda harus menggunakan prioritas rendah seperti 65535. Aturan firewall keluar yang bersifat aditif dan memiliki prioritas lebih tinggi diterapkan ke node gateway untuk mengizinkannya 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 pertahanan yang mendalam. Kebijakan jaringan dicakup ke namespace dan beroperasi di Lapisan 4 (transport). 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, semua koneksi yang tidak diizinkan secara eksplisit akan ditolak. Jika beberapa kebijakan jaringan diterapkan, hasilnya bersifat aditif dan merupakan gabungan dari kebijakan tersebut. Urutan penerapan kebijakan tidak menjadi masalah.

Berikut beberapa contoh kebijakan jaringan:

• 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.
• Secara opsional, izinkan workload 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 (diekspos menggunakan Akses Google Pribadi). Cloud Service Mesh menyediakan CA terkelola dan mengeksposnya sebagai API, sehingga proxy sidecar harus dapat terhubung ke CA tersebut. Kemungkinan juga beberapa workload memerlukan akses ke Google API.
• Izinkan koneksi keluar dari namespace workload ke server metadata GKE agar proxy sidecar dan workload dapat membuat kueri metadata dan melakukan autentikasi ke Google API.

Secara default, saat proxy sidecar disuntikkan ke Pod beban kerja, aturan iptables diprogram sehingga proxy menangkap semua traffic TCP masuk dan keluar. Namun, seperti yang disebutkan sebelumnya, ada cara agar workload dapat melewati proxy. Aturan firewall VPC mencegah akses keluar langsung dari node default yang menjalankan workload. Anda dapat menggunakan kebijakan jaringan Kubernetes untuk memastikan tidak ada egress eksternal langsung dari namespace workload dan bahwa egress dapat dilakukan ke namespace istio-egress.

Jika Anda juga mengontrol ingress dengan kebijakan jaringan, Anda perlu membuat kebijakan ingress yang sesuai dengan kebijakan egress Anda.

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 workload. Komunikasi tepercaya antar-workload dibuat menggunakan koneksi TLS timbal balik (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 secara langsung dari proxy file bantuan, jika Anda membutuhkan kontrol tambahan, sebaiknya arahkan traffic melalui gateway keluar seperti yang dijelaskan dalam panduan ini.

Mengelola konfigurasi untuk kontrol traffic keluar di namespace khusus

Izinkan 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.

Mewajibkan konfigurasi eksplisit tujuan eksternal

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

Menentukan tujuan eksternal dengan Entri Layanan

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

Mengonfigurasi perilaku gateway keluar dengan resource Gateway

Konfigurasi perilaku load balancing gateway keluar menggunakan resource Gateway. Load balancer dapat dikonfigurasi untuk serangkaian host, protokol, dan port tertentu serta dikaitkan dengan deployment gateway keluar. Misalnya, gateway dapat dikonfigurasi untuk keluar ke port 80 dan 443 untuk host eksternal mana pun.

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 menyetel mode TLS di resource Gateway. Jika memungkinkan, gunakan mTLS untuk koneksi dari proxy sidecar ke gateway keluar.

Beban kerja dapat diizinkan untuk memulai koneksi TLS (HTTPS) sendiri. Jika beban kerja memulai 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 workload atau properti permintaan terenkripsi. Selain itu, saat ini tidak mungkin 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 perutean 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 menangani traffic saat dirutekan ke tujuan.

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

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

Mengontrol cakupan konfigurasi proxy dengan Resource Sidecar

Konfigurasi resource Sidecar default untuk setiap namespace guna mengontrol perilaku proxy sidecar. Gunakan properti keluar dari resource Sidecar untuk mengontrol dan meminimalkan host tujuan yang dikonfigurasi di pemroses keluar proxy. Konfigurasi minimal yang umum dapat mencakup 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, dengan sendirinya, dianggap sebagai kontrol keamanan.

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

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, konfigurasikan 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, maka izinkan traffic.

  

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

  

Semua permintaan lainnya ditolak.

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

Konfigurasi 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 membungkus 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 mengirimkannya ke gateway. Kemudian, gateway keluar akan 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 beban kerja sumber dan permintaan.

• Traffic antara Pod workload dan gateway keluar dienkripsi dan diautentikasi (mTLS) serta 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), sehingga memberikan opsi tambahan untuk kemampuan pengamatan dan kontrol.

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

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

DNS, nama host, dan karakter pengganti

Saat merutekan, menolak, atau mengizinkan traffic berdasarkan host tujuan, Anda harus memiliki kepercayaan penuh pada integritas sistem DNS Anda untuk menyelesaikan nama DNS ke alamat IP yang benar. Di cluster Kubernetes Engine, layanan DNS Kubernetes menangani kueri DNS dan selanjutnya 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 wildcard. Kasus yang paling sederhana adalah karakter pengganti untuk host yang memiliki nama yang sama dan dihosting di serangkaian server yang sama. Misalnya, jika satu set server dapat melayani domain yang cocok dengan *.example.com, maka host karakter pengganti dapat digunakan.

Gateway keluar standar tidak dapat meneruskan berdasarkan host wildcard 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 sebelumnya, alamat IP yang telah ditentukan sebelumnya, 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 berwenang yang dapat mengonfigurasi kontrol keluar. Konfigurasi Kontrol Akses Berbasis Peran (RBAC) Kubernetes untuk menghindari pengelakan kontrol keluar yang tidak sah. Terapkan peran RBAC sehingga hanya administrator jaringan yang dapat mengelola namespace istio-egress,istio-system,, dan kube-system serta resource berikut:

• File bantuan
• 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 workload di-deploy dengan toleransi untuk node gateway dan dengan demikian memungkinkan kontrol keluar diabaikan. Jika kontrol administratif terpusat dapat diterapkan pada pipeline deployment, Anda dapat menggunakannya untuk menerapkan batasan pada penggunaan kunci toleransi tertentu.

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

Memastikan traffic dicatat

Sering kali, semua traffic yang melintasi perimeter jaringan perlu dicatat. Pencatatan log 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 mempermudah proses debug dengan kubectl, aktifkan logging traffic ke stdout saat menginstal Cloud Service Mesh menggunakan setelan accessLogFile.

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

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 node pool khusus, Anda dapat men-deploy gateway ke cluster terpisah yang tidak menjalankan workload reguler. Menggunakan cluster terpisah memberikan isolasi 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 kebijakan tersebut beroperasi di Layer 4 (transport), kebijakan tersebut tidak dapat membatasi koneksi lintas cluster berdasarkan namespace atau Pod tujuan.

Langkah berikutnya

• 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.