Plugin jaringan Calico menyediakan berbagai kebijakan jaringan dengan sintaksis terpadu untuk melindungi host perangkat keras, mesin virtual, dan pod. Kebijakan ini dapat diterapkan dalam namespace atau menjadi kebijakan jaringan global yang berlaku (untuk melindungi aplikasi yang berjalan langsung di host β host dapat berupa server atau mesin virtual) atau (untuk melindungi aplikasi yang berjalan di container atau mesin virtual yang dihosting). Kebijakan Calico memungkinkan Anda menerapkan tindakan keamanan di berbagai titik di jalur paket menggunakan opsi seperti preDNAT, unraracked, dan applyOnForward. Memahami cara kerja opsi ini dapat membantu meningkatkan keamanan dan kinerja sistem Anda secara keseluruhan. Artikel ini menjelaskan inti dari opsi kebijakan Calico (preDNAT, unraracked, dan applyOnForward) yang diterapkan pada titik akhir host, dengan penekanan pada apa yang terjadi di jalur pemrosesan paket (rantai iptabels).
Artikel ini mengasumsikan bahwa Anda memiliki pemahaman dasar tentang cara kerja kebijakan jaringan Kubernetes dan Calico. Jika belum, kami sarankan untuk mencobanya ΠΈ menggunakan Calico sebelum membaca artikel ini. Kami juga mengharapkan Anda memiliki pemahaman dasar tentang pekerjaan ini di linux.
Belacu memungkinkan Anda menerapkan serangkaian aturan akses berdasarkan label (ke grup host dan beban kerja/pod). Hal ini sangat berguna jika Anda menggunakan sistem heterogen secara bersamaan - mesin virtual, sistem langsung pada perangkat keras, atau infrastruktur kubernetes. Selain itu, Anda dapat melindungi cluster (node) Anda menggunakan serangkaian kebijakan deklaratif dan menerapkan kebijakan jaringan pada lalu lintas masuk (misalnya, melalui layanan NodePorts atau IP Eksternal).
Pada tingkat dasar, ketika Calico menghubungkan sebuah pod ke jaringan (lihat diagram di bawah), Calico menghubungkannya ke host menggunakan antarmuka Ethernet virtual (veth). Lalu lintas yang dikirim oleh pod datang ke host dari antarmuka virtual ini dan diproses dengan cara yang sama seolah-olah berasal dari antarmuka jaringan fisik. Secara default, Calico menamai antarmuka ini caliXXX. Karena lalu lintas datang melalui antarmuka virtual, lalu lintas melewati iptables seolah-olah pod hanya berjarak satu lompatan. Oleh karena itu, ketika lalu lintas datang ke/dari sebuah pod, lalu lintas tersebut diteruskan dari sudut pandang host.
Pada node Kubernetes yang menjalankan Calico, Anda dapat memetakan antarmuka virtual (veth) ke beban kerja sebagai berikut. Pada contoh di bawah ini Anda dapat melihat bahwa veth#10 (calic1cbf1ca0f8) terhubung ke cnx-manager-* di namespace calico-monitoring.
[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
inet6 fe80::ecee:eeff:feee:eeee/64 scope link
valid_lft forever preferred_lft forever
...
[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...
Mengingat Calico membuat antarmuka veth untuk setiap beban kerja, bagaimana cara Calico menegakkan kebijakan? Untuk melakukan ini, Calico membuat kait di berbagai rantai jalur pemrosesan paket menggunakan iptables.
Diagram di bawah menunjukkan rantai yang terlibat dalam pemrosesan paket di iptables (atau subsistem netfilter). Ketika sebuah paket tiba melalui antarmuka jaringan, pertama-tama paket tersebut melewati rantai PREROUTING. Keputusan perutean kemudian dibuat, dan berdasarkan hal ini, paket melewati INPUT (diarahkan ke proses host) atau FORWARD (diarahkan ke pod atau node lain di jaringan). Dari proses lokal, paket melewati rantai OUTPUT dan kemudian POSTROUTING sebelum dikirim melalui kabel.
Perhatikan bahwa pod juga merupakan entitas eksternal (terhubung ke veth) dalam hal pemrosesan iptables. Mari kita rangkum:
- Lalu lintas yang diteruskan (nat, dirutekan atau ke/dari pod) melewati rantai PREROUTING - FORWARD - POSTROUTING.
- Lalu lintas ke proses host lokal melewati rantai PREROUTING - INPUT.
- Lalu lintas dari proses host lokal melewati rantai OUTPUT - POSTROUTING.
Calico memberikan opsi kebijakan yang memungkinkan Anda menerapkan kebijakan di semua rantai. Dengan mengingat hal tersebut, mari kita lihat berbagai opsi konfigurasi kebijakan yang tersedia di Calico. Angka-angka pada daftar opsi di bawah sesuai dengan angka pada diagram di atas.
- Kebijakan titik akhir beban kerja (pod).
- Kebijakan titik akhir host
- Opsi ApplyOnForward
- Kebijakan PreDNAT
- Kebijakan Tidak Terlacak
Mari kita mulai dengan melihat bagaimana kebijakan diterapkan pada titik akhir beban kerja (pod Kubernetes atau VM OpenStack), lalu melihat opsi kebijakan untuk titik akhir host.
Titik Akhir Beban Kerja
Kebijakan Titik Akhir Beban Kerja (1)
Ini adalah opsi untuk melindungi pod kubernetes Anda. Calico mendukung penggunaan Kubernetes NetworkPolicy, tetapi juga menyediakan kebijakan tambahan - Calico NetworkPolicy dan GlobalNetworkPolicy. Calico membuat rantai untuk setiap pod (beban kerja) dan mengaitkan rantai INPUT dan OUTPUT untuk beban kerja ke tabel filter rantai FORWARD.
Titik Akhir Tuan Rumah
Kebijakan Titik Akhir Host (2)
Selain CNI (antarmuka jaringan kontainer), kebijakan Calico memberikan kemampuan untuk melindungi host itu sendiri. Di Calico, Anda dapat membuat titik akhir host dengan menentukan kombinasi antarmuka host dan, jika perlu, nomor port. Penegakan kebijakan untuk entitas ini dicapai dengan menggunakan tabel filter dalam rantai INPUT dan OUTPUT. Seperti yang Anda lihat dari diagram, (2) berlaku untuk proses lokal pada node/host. Artinya, jika Anda membuat kebijakan yang berlaku pada endpoint host, kebijakan tersebut tidak akan memengaruhi lalu lintas menuju/dari pod Anda. Namun ia menyediakan satu antarmuka/sintaks untuk memblokir lalu lintas untuk host dan pod Anda menggunakan kebijakan Calico. Hal ini sangat menyederhanakan proses pengelolaan kebijakan untuk jaringan heterogen. Mengonfigurasi kebijakan titik akhir host untuk meningkatkan keamanan klaster adalah kasus penggunaan penting lainnya.
Kebijakan ApplyOnForward (3)
Opsi ApplyOnForward tersedia dalam kebijakan jaringan global Calico untuk memungkinkan kebijakan diterapkan pada semua lalu lintas yang melewati titik akhir host, termasuk lalu lintas yang akan diteruskan oleh host. Ini termasuk lalu lintas yang diteruskan ke pod lokal atau ke mana pun di jaringan. Calico mengharuskan pengaturan ini diaktifkan untuk kebijakan yang menggunakan PreDNAT dan tidak terlacak, lihat bagian berikut. Selain itu, ApplyOnForward dapat digunakan untuk memantau lalu lintas host jika router virtual atau perangkat lunak NAT digunakan.
Perhatikan bahwa jika Anda perlu menerapkan kebijakan jaringan yang sama pada proses host dan pod, Anda tidak perlu menggunakan opsi ApplyOnForward. Yang perlu Anda lakukan hanyalah membuat label untuk titik akhir host dan titik akhir beban kerja (pod) yang diperlukan. Calico cukup pintar untuk menerapkan kebijakan berdasarkan label, apa pun jenis titik akhir (titik akhir host atau beban kerja).
Kebijakan PreDNAT (4)
Di Kubernetes, port entitas layanan dapat diekspos secara eksternal menggunakan opsi NodePorts atau, secara opsional (saat menggunakan Calico), dengan mengiklankannya menggunakan opsi Cluster IPs atau External IPs. Kube-proxy menyeimbangkan lalu lintas masuk yang terikat ke suatu layanan ke pod dari layanan terkait menggunakan DNAT. Mengingat hal ini, bagaimana Anda menerapkan kebijakan untuk lalu lintas yang datang melalui NodePorts? Untuk memastikan bahwa kebijakan ini diterapkan sebelum lalu lintas diproses oleh DNAT (yang merupakan pemetaan antara host:port dan layanan terkait), Calico menyediakan parameter untuk globalNetworkPolicy yang disebut "preDNAT: true".
Ketika pra-DNAT diaktifkan, kebijakan ini diterapkan pada (4) diagram - dalam tabel mangle rantai PREROUTING - tepat sebelum DNAT. Urutan kebijakan yang biasa tidak diikuti di sini, karena penerapan kebijakan ini terjadi jauh lebih awal di jalur pemrosesan lalu lintas. Namun, kebijakan preDNAT menghormati urutan penerapan di antara kebijakan tersebut.
Saat membuat kebijakan dengan pra-DNAT, penting untuk berhati-hati dengan lalu lintas yang ingin Anda proses dan membiarkan sebagian besar ditolak. Lalu lintas yang ditandai sebagai 'izinkan' dalam kebijakan pra-DNAT tidak akan lagi diperiksa oleh kebijakan titik akhir host, sementara lalu lintas yang gagal dalam kebijakan pra-DNAT akan dilanjutkan melalui rantai yang tersisa.
Calico mewajibkan untuk mengaktifkan opsi applyOnForward saat menggunakan preDNAT, karena menurut definisi tujuan lalu lintas belum dipilih. Lalu lintas dapat diarahkan ke proses host, atau dapat diteruskan ke pod atau node lain.
Kebijakan yang Tidak Terlacak (5)
Jaringan dan aplikasi dapat memiliki perbedaan perilaku yang besar. Dalam beberapa kasus ekstrim, aplikasi mungkin menghasilkan banyak koneksi yang berumur pendek. Hal ini dapat menyebabkan conntrack (komponen inti tumpukan jaringan Linux) kehabisan memori. Biasanya, untuk menjalankan aplikasi jenis ini di Linux, Anda harus mengonfigurasi atau menonaktifkan conntrack secara manual, atau menulis aturan iptables untuk melewati conntrack. Kebijakan tidak terlacak di Calico adalah opsi yang lebih sederhana dan efisien jika Anda ingin memproses koneksi secepat mungkin. Misalnya saja jika Anda menggunakan masif atau sebagai tindakan perlindungan tambahan terhadap .
Baca ini (Atau ) untuk informasi lebih lanjut, termasuk pengujian kinerja menggunakan kebijakan yang tidak terlacak.
Saat Anda menyetel opsi "doNotTrack: true" di Calico globalNetworkPolicy, opsi ini menjadi kebijakan **tidak terlacak** dan diterapkan sejak awal dalam alur pemrosesan paket Linux. Melihat diagram di atas, kebijakan yang tidak terlacak diterapkan dalam rantai PREROUTING dan OUTPUT di tabel mentah sebelum pelacakan koneksi (conntrack) dimulai. Ketika sebuah paket diizinkan oleh kebijakan tidak terlacak, paket tersebut ditandai untuk menonaktifkan pelacakan koneksi untuk paket tersebut. Itu berarti:
- Kebijakan tidak terlacak diterapkan per paket. Tidak ada konsep koneksi (atau aliran). Kurangnya koneksi mempunyai beberapa konsekuensi penting:
- Jika Anda ingin mengizinkan lalu lintas permintaan dan respons, Anda memerlukan aturan untuk masuk dan keluar (karena Calico biasanya menggunakan conntrack untuk menandai lalu lintas respons sebagai diizinkan).
- Kebijakan tidak terlacak tidak berfungsi untuk beban kerja (pod) Kubernetes, karena dalam kasus ini tidak ada cara untuk melacak koneksi keluar dari pod.
- NAT tidak berfungsi dengan benar dengan paket yang tidak terlacak (karena kernel menyimpan pemetaan NAT di conntrack).
- Saat melewati aturan "izinkan semua" dalam kebijakan tidak terlacak, semua paket akan ditandai sebagai tidak terlacak. Hal ini hampir selalu bukan yang Anda inginkan, jadi penting untuk bersikap selektif terhadap paket yang diizinkan oleh kebijakan tidak terlacak (dan mengizinkan sebagian besar lalu lintas melewati kebijakan terlacak normal).
- Kebijakan yang tidak terlacak diterapkan di awal jalur pemrosesan paket. Hal ini sangat penting untuk dipahami saat membuat kebijakan Calico. Anda dapat memiliki kebijakan pod dengan order:1 dan kebijakan tidak terlacak dengan order:1000. Itu tidak masalah. Kebijakan Tidak Terlacak akan diterapkan sebelum kebijakan untuk pod. Kebijakan yang tidak terlacak hanya menghormati perintah eksekusi di antara mereka sendiri.
Karena salah satu tujuan kebijakan doNotTrack adalah untuk menerapkan kebijakan tersebut sejak awal dalam alur pemrosesan paket Linux, Calico mewajibkan untuk menentukan opsi applyOnForward saat menggunakan doNotTrack. Mengacu pada diagram pemrosesan paket, perhatikan bahwa kebijakan tidak terlacak(5) diterapkan sebelum keputusan perutean apa pun. Lalu lintas dapat diarahkan ke proses host, atau dapat diteruskan ke pod atau node lain.
Hasil
Kami melihat berbagai opsi kebijakan (Host endpoint, ApplyOnForward, preDNAT, dan Untracked) di Calico dan bagaimana penerapannya di sepanjang jalur pemrosesan paket. Memahami cara kerjanya membantu dalam mengembangkan kebijakan yang efektif dan aman. Dengan Calico Anda dapat menggunakan kebijakan jaringan global yang berlaku pada label (sekelompok node dan pod) dan menerapkan kebijakan dengan berbagai parameter. Hal ini memungkinkan profesional keamanan dan desain jaringan untuk dengan mudah melindungi βsemuanyaβ (tipe titik akhir) sekaligus menggunakan bahasa kebijakan tunggal dengan kebijakan Calico.
Pengakuan: Saya ingin mengucapkan terima kasih ΠΈ atas ulasan dan informasi berharga mereka.
Sumber: www.habr.com