Pod, node, atau klaster: apa yang sebenarnya dialihkan sidecar VPN

Sidecar VPN di dalam Pod Kubernetes tampak seperti VPN tingkat host dengan tata krama lebih baik, dan kemiripannya berhenti di batas namespace. Kontainer dalam satu Pod berbagi namespace jaringan, termasuk ruang alamat dan port, jadi sidecar yang memasang rute dan kebijakan benar-benar mengubah ke mana paket aplikasi pergi. Ia tidak mengubah apa pun bagi Pod lain di node itu, dan tidak menyentuh tumpukan milik node kecuali Anda mengonfigurasinya begitu. Memahami batas itu dengan benar menentukan apa yang dapat Anda terapkan dan apa yang harus Anda uji. Bagian berikut menelusurinya dari namespace ke luar.

Namespace bersama, konsekuensi bersama

Dua kontainer dalam satu Pod berbicara lewat loopback dan melihat antarmuka yang sama, dan itulah sebabnya pola sidecar berfungsi sama sekali: aplikasi tidak perlu tahu ada terowongan, karena rute yang ia selesaikan dipasang di namespace yang ia gunakan. Properti yang sama berarti kesalahan sidecar adalah kesalahan aplikasi. Rute yang menangkap terlalu banyak, atau perubahan DNS yang menunjuk ke resolver di dalam terowongan, berlaku segera bagi setiap proses di Pod itu. Dalam namespace bersama tidak ada perutean per kontainer, jadi sidecar tidak dapat dibatasi pada satu proses.

Inilah mekanisme yang perlu diingat saat meninjau: radius dampaknya adalah Pod, bukan node dan bukan klaster.

Apa yang tidak dijangkau sidecar

Pod lain mempertahankan namespace dan perutean mereka sendiri, jadi beban kerja yang membutuhkan egress yang sama membutuhkan sidecar yang sama atau, sebagai gantinya, desain tingkat node. Lalu lintas node juga berada di luar namespace Pod, dan Pod dengan jaringan host sengaja keluar sepenuhnya dari isolasi ini. Jika Anda menjalankan sidecar dengan jaringan host untuk mencapai sesuatu yang praktis, Anda telah memperluas cakupan dari satu Pod ke seluruh node dan sebaiknya mengatakannya dengan lantang.

Lalu lintas layanan klaster adalah kejutan umum lainnya. Rute default yang lebar di dalam Pod dapat menangkap permintaan yang ditujukan ke server API atau layanan ClusterIP, yang kemudian gagal dengan cara yang tampak seperti terowongan rusak.

Rencana rute: rentang Pod, layanan, node, dan VPN

Tuliskan keempat rentang dan periksa tumpang tindihnya sebelum menerapkan apa pun: CIDR Pod, CIDR layanan, alamat node, dan tujuan di balik VPN. Tumpang tindih antara rentang privat VPN dan ruang klaster itu sendiri tidak jarang, dan rute default adalah solusi yang salah untuk itu. Rencana rute berada di repositori yang sama dengan manifes, karena klaster berikutnya bisa memberikan rentang Pod dan layanan yang sama sekali berbeda.

DNS adalah bagian dari rencana, bukan urusan terpisah. Sidecar yang menulis ulang konfigurasi resolver dapat merusak penemuan layanan di dalam klaster sambil membuat pencarian eksternal bekerja sempurna.

Mulai dan gagal adalah keadaan eksplisit

Proses sidecar yang berjalan bukanlah kebijakan egress. Putuskan lalu lintas apa yang boleh mengalir sebelum terowongan siap dan apa yang terjadi jika ia mati sesudahnya, lalu terapkan keputusan itu: probe yang menggerbangi kontainer aplikasi, kebijakan jaringan yang menolak secara default, atau keduanya. Tanpa salah satunya, aplikasi mulai, menyelesaikan nama, dan mengirim lalu lintas keluar dari jalur normal node sementara terowongan masih menghubungkan.

Celah itu singkat di klaster yang sehat dan permanen di klaster yang rusak, dan itulah tepatnya sifat yang disukai penyerang atau kebocoran data tak sengaja.

Pasangkan urutannya dengan uji kegagalan. Bunuh sidecar dan pastikan aplikasi kehilangan egress yang dimaksudkan alih-alih diam-diam mundur.

Kemampuan, kebijakan, dan pengujian dari kontainer aplikasi

Memberikan kemampuan yang diperlukan untuk membuat antarmuka dan mengubah rute adalah keputusan hak istimewa, dan hak istimewa yang sesuai untuk Pod terisolasi tidak otomatis sesuai pada tumpukan node. Gunakan mekanisme kebijakan jaringan dan keamanan yang didukung klaster, dan jangan menganggap setiap implementasi CNI atau kebijakan memperlakukan antarmuka VPN dengan cara yang sama; perbedaannya muncul justru pada kasus kegagalan yang Anda pedulikan.

Ujilah dari kontainer aplikasi yang sebenarnya, dengan permintaan baru ke tujuan privat, layanan klaster, dan internet publik. Uji dari sidecar membuktikan terowongan berfungsi, bukan bahwa aplikasi dapat mencapai apa yang dibutuhkannya.

Dokumentasikan asumsi jaringan klaster di samping konfigurasi VPN. Memindahkan beban kerja ke klaster lain kemudian menjadi latihan memeriksa rencana rute, bukan perubahan image yang diam-diam berhenti berfungsi.