Dokumen ini menjelaskan cara menggunakan gateway keluar Anthos Service Mesh dan kontrol Google Cloud lainnya untuk mengamankan traffic keluar (traffic 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.
Ada tutorial pendamping yang dapat Anda gunakan sebagai cetak biru untuk mengonfigurasi kontrol traffic keluar di cluster Anda sendiri.
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 pada 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 memiliki risiko. Orang dalam yang berniat jahat, atau siapa pun yang menyusupi perimeter dapat bergerak bebas ke dalam jaringan, mengakses dan meretas data, menyerang sistem pihak ketiga, dan mengganggu sistem administratif.
Saat beban kerja 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 merepresentasikan identitas beban kerja yang membuat koneksi. Di lingkungan Kubernetes, alamat IP Pod ditetapkan secara singkat dan sering didaur ulang saat Pod datang dan pergi.
Sering kali, mengidentifikasi set alamat IP dalam jumlah kecil dan tetap untuk host tujuan tertentu sering kali tidak memungkinkan. Alamat IP sering berubah, bervariasi menurut region, dan dapat diambil dari rentang yang besar atau merepresentasikan cache, proxy, atau CDN.
Beberapa tim berbagi cluster multi-tenant yang sama, dengan rentang IP sumber bersama, mungkin memiliki persyaratan konektivitas eksternal yang berbeda.
Anthos Service Mesh adalah distribusi mesh layanan Istio open source yang didukung sepenuhnya oleh Google. Mesh layanan menyediakan cara yang seragam untuk menghubungkan, mengelola, dan mengamankan komunikasi aplikasi. Mesh layanan mengambil 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. Penggunaan mesh layanan membantu memisahkan pekerjaan tim pengembangan yang bertanggung jawab untuk mengirimkan dan merilis fitur aplikasi, dari tanggung jawab administrator jaringan dengan memberikan kontrol deklaratif atas perilaku jaringan.
Anthos Service Mesh menyediakan opsi untuk men-deploy proxy maju mandiri, yang dikenal sebagai gateway keluar, di edge mesh. Panduan ini menjelaskan cara menggabungkan fitur proxy gateway keluar dengan fitur Google Cloud untuk mengontrol, memberi otorisasi, dan mengamati traffic keluar dari workload yang di-deploy ke cluster GKE.
Arsitektur pertahanan mendalam
Diagram di bawah menunjukkan arsitektur yang menggunakan pendekatan defense in depth terhadap kontrol mendetail traffic keluar untuk sebuah cluster yang digunakan oleh beberapa tim. Kontrol ini didasarkan pada kontrol jaringan Lapisan 4 (transpor) 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: Melalui metode ini, Anda dapat mengonfigurasi aturan firewall yang berbeda untuk diterapkan, bergantung pada kumpulan node tempat node tersebut berada.
namespace Kubernetes: Anda membuat namespace untuk setiap tim guna memberikan kontrol administratif yang didelegasikan dan isolasi. 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 disertakan ke namespace dan dapat dicakup secara lebih mendetail ke Pod tertentu dalam namespace.
Gateway keluar: Traffic yang keluar dari Pod dalam mesh akan diarahkan melalui proxy gateway keluar khusus yang berjalan di node khusus. Anda men-deploy gateway keluar dengan penskala otomatis Pod horizontal sehingga jumlah replika meningkat dan menurun sesuai dengan traffic.
Kebijakan otorisasi: Anda menggunakan kebijakan otorisasi mesh untuk menerapkan kontrol (aplikasi) Lapisan 7 untuk memproses traffic antara Pod dalam mesh dan ke traffic yang keluar dari mesh.
Resource file bantuan: Anda menggunakan resource File bantuan untuk mengontrol cakupan konfigurasi proxy file bantuan yang berjalan di setiap Pod beban kerja. 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.
GKE Workload Identity: Dengan Workload Identity, Anda dapat menggunakan Identity and Access Management (IAM) untuk memberikan izin API ke beban kerja 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 Anda, sebaiknya konfigurasikan kontrol pertahanan mendalam yang dijelaskan di bagian ini.
Menggunakan GKE Pribadi dengan Cloud NAT
Jika keamanan menjadi hal yang penting, persyaratan pertama bagi banyak organisasi adalah menghindari penetapan alamat IP publik ke workload mereka. Cluster GKE pribadi memenuhi persyaratan ini. Anda dapat mengonfigurasi mode VPC Native di cluster pribadi agar Pod dan layanan mendapatkan alamat IP dari rentang sekunder di VPC. Alamat IP VPC Native Pod dapat dirutekan secara native dalam jaringan VPC.
Beberapa workload mungkin memerlukan akses ke layanan di luar jaringan VPC dan ke internet. Agar beban kerja dapat terhubung ke host eksternal tanpa mengharuskannya memiliki alamat IP publik, konfigurasikan Cloud NAT untuk menyediakan penafsiran alamat jaringan (NAT).
Pastikan Cloud NAT dikonfigurasi agar gateway keluar dapat membuat koneksi simultan dalam jumlah yang memadai ke tujuan eksternal. Anda dapat menghindari kehabisan port dan masalah terkait penundaan penggunaan ulang koneksi dengan menetapkan jumlah minimum port per VM secara tepat. Lihat Ringkasan port dan alamat Cloud NAT untuk mengetahui detail selengkapnya. Peningkatan 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 Google. Gunakan Akses Google Pribadi dengan Zona DNS kustom untuk mengizinkan konektivitas dari subnet VPC pribadi ke Google API menggunakan satu 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), tergantung apakah Anda menggunakan Kontrol Layanan VPC.
Menggunakan Workload Identity dan IAM untuk meningkatkan keamanan Google API dan layanan Google
Menggunakan Workload Identity adalah cara yang direkomendasikan untuk memungkinkan workload GKE melakukan autentikasi dengan Google API dan agar administrator dapat menerapkan kontrol otorisasi "hak istimewa terendah" menggunakan IAM.
Saat menggunakan Akses Google Pribadi, Workload Identity, dan IAM, Anda dapat dengan aman mengizinkan Pod beban kerja 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. Mereka dapat dianggap sebagai cluster virtual, dan memungkinkan tanggung jawab administratif bagi grup resource Kubernetes untuk didelegasikan ke administrator yang berbeda.
Namespace adalah fitur penting untuk isolasi kontrol administratif. Namun, secara default fungsi tersebut tidak menyediakan isolasi node, isolasi bidang data, atau isolasi jaringan.
Anthos Service Mesh mem-build di namespace Kubernetes dengan menggunakannya sebagai unit tenancy dalam mesh layanan. Kebijakan otorisasi mesh dan resource sidecar dapat membatasi visibilitas dan akses berdasarkan atribut namespace, identitas, dan 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 pada node gateway khusus
Menjalankan gateway keluar pada node dalam kumpulan node gateway khusus menawarkan beberapa keuntungan. Node yang terbuka untuk eksternal dapat menggunakan konfigurasi yang telah di-hardening, dan Anda dapat mengonfigurasi aturan firewall VPC untuk mencegah beban kerja menjangkau host eksternal secara langsung. Kumpulan node dapat diskalakan secara otomatis menggunakan autoscaler cluster.
Untuk mengizinkan kontrol administratif terpisah dari gateway keluar, deploy gateway keluar ke
namespace istio-egress khusus. Namun, namespace adalah resource tingkat cluster dan tidak mungkin digunakan untuk mengontrol node tempat deployment dijalankan. Untuk kontrol deployment, gunakan pemilih node untuk deployment gateway keluar agar deployment berjalan pada node yang diberi label sebagai anggota kumpulan node gateway.
Pastikan hanya Pod gateway yang dapat berjalan di node gateway. Pod lainnya harus dikeluarkan dari node gateway. Jika tidak, kontrol traffic keluar dapat diabaikan. Beban kerja dapat dicegah agar tidak berjalan pada node tertentu menggunakan taint dan toleransi. Anda harus melakukan taint pada node dalam kumpulan node gateway dan menambahkan toleransi yang sesuai ke deployment gateway keluar.
Menerapkan aturan firewall VPC ke node tertentu
Anda mengonfigurasi pemilihan rute mesh layanan untuk mengarahkan traffic keluar dari workload yang berjalan di kumpulan node default melalui gateway keluar yang berjalan di kumpulan node gateway. Namun, konfigurasi pemilihan rute mesh tidak boleh dipercaya sebagai batas keamanan karena ada berbagai cara di mana beban kerja dapat mengabaikan proxy mesh.
Untuk mencegah beban kerja aplikasi terhubung langsung ke host eksternal, terapkan aturan firewall keluar yang ketat ke node dalam kumpulan node 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 dan arah traffic tempat aturan tersebut diterapkan. Aturan keluar berlaku untuk traffic keluar dan aturan masuk berlaku untuk traffic masuk. Default untuk traffic keluar adalah allow dan default untuk traffic masuk adalah deny.
Aturan firewall diterapkan secara berurutan berdasarkan nomor prioritas yang dapat Anda tentukan. Aturan firewall bersifat stateful, artinya jika traffic tertentu dari VM diizinkan, traffic yang ditampilkan menggunakan koneksi yang sama juga diizinkan.
Diagram berikut menunjukkan cara penerapan aturan firewall terpisah ke node di dua kumpulan node yang berbeda berdasarkan akun layanan yang ditetapkan ke sebuah 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 keluar dengan prioritas tambahan dan lebih tinggi diterapkan ke node gateway agar node gateway dapat 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 mencakup namespace dan beroperasi di Lapisan 4 (transpor). Dengan kebijakan jaringan, Anda dapat membatasi traffic masuk dan keluar:
- Di antara namespace
- Untuk Pod dalam namespace
- Ke porta dan blok IP tertentu.
Setelah kebijakan jaringan memilih Pod di namespace, koneksi apa pun yang tidak diizinkan secara eksplisit akan ditolak. Saat beberapa kebijakan jaringan diterapkan, hasilnya adalah tambahan dan merupakan gabungan dari kebijakan tersebut. Urutan kebijakan diterapkan tidak menjadi masalah.
Tutorial pendamping menyertakan contoh kebijakan jaringan berikut:
- Izinkan koneksi keluar dari namespace beban kerja ke
namespace
istio-systemdanistio-egress. Pod harus dapat terhubung ke isoid dan gateway keluar. - Mengizinkan beban kerja untuk membuat kueri DNS dari namespace beban kerja ke port
53 di namespace
kube-system. - Secara opsional, izinkan beban kerja di namespace yang sama untuk terhubung satu sama lain.
- Secara opsional, izinkan koneksi keluar antar-namespace yang digunakan oleh tim aplikasi yang berbeda.
- Mengizinkan koneksi keluar dari namespace beban kerja ke VIP untuk Google API (ditampilkan menggunakan Akses Google Pribadi). Anthos Service Mesh menyediakan CA terkelola dan menampilkannya sebagai API, sehingga proxy file bantuan harus dapat terhubung ke CA. Kemungkinan beberapa workload juga memerlukan akses ke Google API.
- Izinkan koneksi keluar dari namespace beban kerja ke server metadata GKE sehingga proxy file bantuan dan beban kerja dapat membuat kueri metadata dan melakukan autentikasi ke Google API.
Secara default, saat proxy sidecar dimasukkan ke Pod beban kerja, aturan iptables
diprogram sehingga proxy merekam semua traffic TCP
masuk dan keluar. Namun, seperti yang disebutkan sebelumnya, ada beberapa cara agar beban kerja mengabaikan proxy. Aturan firewall VPC mencegah akses keluar langsung dari node default yang menjalankan beban kerja. Anda dapat menggunakan kebijakan jaringan Kubernetes untuk memastikan bahwa tidak ada traffic keluar eksternal langsung yang mungkin dilakukan dari namespace beban kerja dan traffic tersebut dapat keluar 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
Beban kerja yang berjalan di mesh layanan tidak diidentifikasi berdasarkan alamat IP-nya. Anthos Service Mesh menetapkan identitas yang kuat dan dapat diverifikasi dalam bentuk sertifikat dan kunci X.509 untuk setiap workload. Komunikasi tepercaya antara workload dibuat menggunakan koneksi mutual TLS (mTLS) yang diautentikasi dan dienkripsi.
Penggunaan autentikasi mTLS dengan identitas yang jelas untuk setiap aplikasi memungkinkan Anda menggunakan kebijakan otorisasi mesh untuk kontrol mendetail terkait cara kerja beban kerja 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 seperti yang dijelaskan dalam panduan ini.
Mengelola konfigurasi untuk kontrol traffic keluar dalam namespace khusus
Izinkan administrator jaringan mengelola kontrol secara terpusat menggunakan namespace
istio-egress khusus untuk konfigurasi mesh terkait traffic 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 dalam namespace ini.
Mewajibkan konfigurasi eksplisit tujuan eksternal
Pastikan bahwa proxy mesh hanya diprogram dengan rute ke host eksternal yang ditentukan secara eksplisit dalam registry mesh layanan. Setel
mode kebijakan traffic keluar
ke REGISTRY_ONLY di
resource file bantuan
default untuk setiap namespace. Menetapkan kebijakan traffic keluar untuk mesh tidak boleh dianggap sebagai kontrol perimeter yang aman dengan sendirinya.
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 mana yang dapat melihat entri layanan. Entri Layanan menentukan rute keluar yang dikonfigurasi di proxy mesh, tetapi tidak boleh dianggap sebagai kontrol yang aman untuk menentukan ke mana workload host eksternal dapat dihubungkan.
Mengonfigurasi perilaku gateway keluar dengan resource Gateway
Konfigurasikan perilaku load balancing gateway keluar menggunakan resource Gateway. Load balancer dapat dikonfigurasi untuk sekumpulan host, protokol, dan port tertentu serta dikaitkan dengan deployment gateway keluar. Misalnya, gateway mungkin dikonfigurasi untuk traffic keluar ke port 80 dan 443 untuk host eksternal apa pun.
Di Anthos Service Mesh 1.6 dan yang lebih baru, mTLS otomatis diaktifkan secara default. Dengan mTLS otomatis, proxy file bantuan klien secara otomatis mendeteksi apakah server memiliki file bantuan. Sidecar klien mengirimkan mTLS ke workload dengan sidecar dan mengirimkan traffic teks biasa ke beban kerja tanpa sidecar. Meskipun dengan mTLS otomatis, traffic yang dikirim ke gateway keluar dari proxy file bantuan tidak menggunakan mTLS secara otomatis. Untuk menunjukkan cara mengamankan koneksi ke gateway keluar, Anda harus menyetel mode TLS pada resource Gateway. Jika memungkinkan, gunakan mTLS untuk koneksi dari proxy file bantuan ke gateway keluar.
Beban kerja dapat diizinkan untuk memulai koneksi TLS (HTTPS)
sendiri. Jika beban kerja berasal dari koneksi TLS, biasanya pada port 443, Anda harus mengonfigurasi gateway agar menggunakan mode passthrough untuk koneksi pada 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 Anda tidak dapat menggunakan
mTLS dan passthrough secara bersamaan.
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 gateway keluar ke tujuan eksternal. Layanan virtual menentukan aturan untuk menyesuaikan lalu lintas tertentu. Traffic yang cocok kemudian dikirim ke tujuan. Aturan tujuan dapat menentukan subkumpulan (misalnya, gateway keluar atau host eksternal) dan cara penanganan traffic saat dirutekan ke tujuan.
Gunakan satu aturan tujuan untuk beberapa host tujuan untuk secara eksplisit menentukan cara pengamanan traffic dari proxy file bantuan ke gateway. Seperti yang dijelaskan sebelumnya, metode yang direkomendasikan adalah beban kerja mengirim permintaan teks biasa dan proxy file bantuan untuk membuat koneksi mTLS ke gateway.
Gunakan aturan tujuan untuk setiap host eksternal guna mengonfigurasi gateway keluar ke permintaan HTTP biasa 'mengupgrade' agar menggunakan koneksi TLS (HTTPS) saat meneruskan ke tujuan. Mengupgrade koneksi teks biasa ke TLS sering disebut sebagai asal TLS.
Mengontrol cakupan konfigurasi proxy dengan Resource Sidecar
Konfigurasikan resource File bantuan default untuk setiap namespace guna mengontrol perilaku proxy file bantuan. Gunakan properti keluar dari resource Sidecar untuk mengontrol dan meminimalkan host tujuan yang dikonfigurasi dalam pemroses keluar dari proxy. Konfigurasi minimal standar mungkin menyertakan 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 dalam proxy file bantuan tidak boleh dianggap sebagai kontrol keamanan dengan sendirinya.
Praktik terbaiknya adalah menggunakan resource Sidecar untuk membatasi ukuran konfigurasi proxy. Secara default, setiap proxy file bantuan dalam mesh dikonfigurasi untuk mengizinkannya mengirimkan traffic ke setiap proxy lainnya. Konsumsi memori proxy file bantuan dan bidang kontrol dapat dikurangi secara signifikan dengan membatasi konfigurasi proxy hanya untuk host yang perlu diajak berkomunikasi.
Gunakan 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 atau namespace workload sumber, koneksi ke gateway keluar harus diautentikasi dengan mTLS. Koneksi dari file bantuan ke gateway keluar tidak secara 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 mengirimkan permintaan HTTP biasa ke tujuan di luar mesh. Proxy file bantuan kemudian dapat meneruskan permintaan ke gateway menggunakan mTLS dan gateway dapat membuat koneksi TLS yang aman ke host eksternal.
Untuk mendukung persyaratan traffic keluar bagi tim dan aplikasi yang berbeda, konfigurasi kebijakan otorisasi "hak istimewa terendah" yang terpisah per namespace atau beban kerja. Misalnya, kebijakan yang berbeda dapat diterapkan di gateway keluar dengan menentukan aturan berdasarkan namespace beban kerja sumber dan atribut permintaan sebagai berikut:
Jika namespace sumbernya 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.
Konfigurasi gateway traffic keluar untuk membuka koneksi TLS (HTTPS) asal ke tujuan
Konfigurasikan aturan tujuan agar gateway keluar berasal dari koneksi TLS (HTTPS) ke tujuan eksternal.
Agar origin TLS di gateway keluar berfungsi, beban kerja harus mengirim permintaan HTTP biasa. Jika beban kerja memulai TLS, gateway keluar akan menggabungkan TLS di atas TLS asli, dan permintaan ke layanan eksternal akan gagal.
Karena beban kerja mengirimkan permintaan HTTP biasa, konfigurasikan proxy file bantuan beban kerja untuk membuat koneksi mTLS saat mengirimkannya ke gateway. Gateway keluar kemudian menghentikan koneksi mTLS dan membuat 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) dan traffic antara gateway keluar dan tujuan dienkripsi (TLS/HTTPS).
Di dalam mesh, proxy file bantuan dapat mengamati dan menindaklanjuti properti permintaan HTTP (misalnya, header), sehingga memberikan opsi tambahan untuk kemampuan 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 ulang koneksi lebih efisien dan mengurangi risiko tercapainya batas koneksi.
DNS, nama host, dan karakter pengganti
Saat mengarahkan, 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, lalu mendelegasikan kueri eksternal ke server metadata GKE dan DNS Internal. Tetapkan atribut resolusi entri layanan ke DNS saat melakukan pemilihan rute ke host eksternal, sehingga proxy file bantuan bertanggung jawab untuk membuat kueri DNS.
Anthos Service Mesh dapat merutekan traffic berdasarkan host karakter pengganti. Kasus yang paling sederhana adalah karakter pengganti untuk host yang memiliki nama yang sama dan dihosting di sekumpulan server yang sama. Misalnya, jika satu kumpulan server dapat menayangkan domain yang cocok dengan *.example.com, host karakter pengganti dapat digunakan.
Gateway traffic keluar standar tidak dapat maju berdasarkan host karakter pengganti yang lebih umum dan arbitrer (misalnya *.com) karena adanya batasan tertentu dari proxy Envoy yang digunakan oleh Istio. Envoy hanya dapat merutekan traffic ke host yang telah ditetapkan sebelumnya, alamat IP yang telah ditetapkan, atau ke alamat IP tujuan asli dari suatu permintaan.
Saat menggunakan gateway keluar, IP tujuan asli dari permintaan akan hilang karena diganti dengan IP gateway, dan host tujuan arbitrer tidak dapat dikonfigurasi sebelumnya.
Penegakan kebijakan secara administratif
Gunakan Kontrol Akses Berbasis Peran (RBAC) Kubernetes
Hanya administrator resmi yang dapat mengonfigurasi kontrol traffic keluar.
Konfigurasikan Kubernetes Role-based Access Control (RBAC) untuk menghindari pengelakan atas kontrol traffic keluar secara 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 beban kerja di-deploy di node gateway. Namun, secara default, tidak ada yang dapat mencegah beban kerja di-deploy dengan toleransi untuk node gateway, sehingga memungkinkan kontrol traffic keluar diabaikan. Jika memungkinkan untuk menerapkan kontrol administratif terpusat atas pipeline deployment, Anda dapat menggunakannya untuk menerapkan pembatasan pada penggunaan kunci toleransi tertentu.
Pendekatan lainnya adalah menggunakan kontrol penerimaan Kubernetes. Anthos menyertakan komponen bernama Pengontrol Kebijakan yang bertindak sebagai pengontrol penerimaan Kubernetes dan memvalidasi bahwa deployment memenuhi batasan kebijakan yang Anda tentukan.
Pastikan traffic dicatat
Sering kali Anda perlu mencatat semua traffic yang melintasi perimeter jaringan. Logging 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 Anthos Service Mesh di Konsol Google Cloud. Anda dapat memfilter log berdasarkan berbagai atribut, termasuk sumber/tujuan, identitas, ruang nama, atribut traffic, dan latensi.
Untuk mengizinkan proses debug yang mudah dengan kubectl, aktifkan logging traffic ke stdout saat menginstal Anthos 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
Anthos 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 tersebut ke cluster terpisah yang tidak menjalankan beban kerja reguler. Menggunakan cluster terpisah akan menyediakan isolasi serupa antara workload dan gateway, sekaligus menghindari kebutuhan untuk taint dan toleransi. Gateway keluar dapat menggunakan cluster yang terpisah dengan gateway masuk atau layanan pusat lainnya.
Anda dapat menggunakan kebijakan jaringan Kubernetes dalam deployment multi-cluster, tetapi karena beroperasi di Lapisan 4 (transpor), kebijakan tersebut tidak dapat membatasi koneksi lintas cluster berdasarkan namespace tujuan atau Pod.
Langkah selanjutnya
- Coba tutorial pendamping
- Lihat 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.