Get best of the week

Memahami Kebijakan Jaringan dengan Calico



Calico Network Plugin menyediakan berbagai kebijakan jaringan dengan sintaksis terpadu untuk melindungi host pada perangkat keras, mesin virtual, dan pod. Kebijakan ini dapat diterapkan dalam namespace atau kebijakan jaringan global yang berlaku untuk titik akhir host (untuk melindungi aplikasi yang berjalan langsung pada host - server atau mesin virtual dapat menjadi host secara langsung) atau untuk beban kerja titik akhir(untuk melindungi aplikasi yang berjalan dalam wadah atau mesin virtual yang dihosting). Kebijakan Calico memungkinkan Anda untuk menerapkan langkah-langkah keamanan ke berbagai titik di jalur paket menggunakan parameter seperti preDNAT, tidak terlacak, dan applyOnForward. Memahami cara kerja opsi ini dapat membantu meningkatkan keamanan dan kinerja sistem secara keseluruhan. Artikel ini menjelaskan inti dari pengaturan kebijakan Calico ini (preDNAT, unraracked, dan applyOnForward) yang diterapkan pada host titik akhir, dengan penekanan pada apa yang terjadi dalam jalur pemrosesan paket (rantai iptabel).

Artikel ini mengasumsikan bahwa Anda memiliki pemahaman tentang bagaimana kebijakan jaringan Kubernetes dan Calico bekerja. Jika tidak, kami sarankan Anda mencoba tutorial kebijakan jaringan dasar dan tutorial perlindungan host menggunakan Calico sebelum membaca artikel ini. Kami juga berharap Anda memiliki pemahaman dasar tentang iptables di Linux. Kebijakan jaringan global

Calicomemungkinkan Anda menerapkan seperangkat aturan akses label (untuk meng-host grup dan beban kerja / pod). Ini sangat berguna jika Anda menggunakan sistem heterogen bersama - mesin virtual, sistem langsung pada perangkat keras, atau infrastruktur kubernet. Selain itu, Anda dapat melindungi cluster Anda (node) menggunakan seperangkat kebijakan deklaratif dan menerapkan kebijakan jaringan untuk lalu lintas masuk (misalnya, melalui layanan NodePorts atau IP Eksternal).

Pada tingkat mendasar, ketika Calico menghubungkan pod ke jaringan (lihat diagram di bawah), Calico menghubungkannya ke host menggunakan antarmuka Ethernet (veth) virtual. Lalu lintas yang dikirim oleh pod tiba di host dari antarmuka virtual ini dan diproses seolah-olah berasal dari antarmuka jaringan fisik. Secara default, Calico memanggil antarmuka ini caliXXX. Karena lalu lintas datang melalui antarmuka virtual, ia melewati iptables, seolah-olah pod berada pada jarak satu hop. Karena itu, ketika lalu lintas datang / berasal dari pod, itu diteruskan dari sudut pandang tuan rumah.

Pada simpul Kubernetes tempat Calico berjalan, Anda dapat memetakan antarmuka virtual (veth) ke beban kerja sebagai berikut. Dalam contoh di bawah ini, Anda dapat melihat bahwa veth # 10 (calic1cbf1ca0f8) terhubung ke cnx-manager- * di namespace pemantauan-calico.

[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 bahwa Calico membuat antarmuka veth untuk setiap beban kerja, bagaimana cara menerapkan kebijakan? Untuk melakukan ini, Calico membuat kait di berbagai rantai jalur pemrosesan paket menggunakan iptables.

Diagram di bawah ini menunjukkan rantai yang terlibat dalam pemrosesan paket di iptables (atau subsistem netfilter). Ketika sebuah paket tiba melalui antarmuka jaringan, itu pertama kali melalui rantai PREROUTING. Kemudian keputusan routing dibuat, dan berdasarkan ini, paket melewati baik 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 mengirimnya melalui kabel.

Perhatikan bahwa pod juga merupakan objek eksternal (terhubung ke veth) dalam hal penanganan iptables. Untuk meringkas:

  • Lalu lintas yang diteruskan (nat, dialihkan 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 untuk menerapkan kebijakan ke semua rantai. Dengan mengingat hal itu, mari kita lihat berbagai pengaturan kebijakan yang tersedia di Calico. Angka-angka dalam daftar opsi di bawah ini sesuai dengan angka-angka pada diagram di atas.

  1. Kebijakan titik akhir beban kerja (pod)
  2. Inangi kebijakan titik akhir
  3. Opsi ApplyOnForward
  4. Kebijakan PreDNAT
  5. Kebijakan Tidak Dilacak

Mari kita mulai dengan melihat bagaimana kebijakan berlaku untuk titik akhir beban kerja (Kubernetes atau OpenStack VMs pods), dan kemudian lihat opsi kebijakan untuk titik akhir host.

Titik akhir beban kerja


Kebijakan Endpoint Beban Kerja (1)


Ini adalah opsi untuk melindungi pod kubernet Anda. Calico mendukung kerja dengan Kubernetes NetworkPolicy, tetapi juga memberikan kebijakan tambahan - Calico NetworkPolicy dan GlobalNetworkPolicy. Calico membuat rantai untuk setiap pod (beban kerja) dan kait ke rantai INPUT dan OUTPUT untuk beban kerja ke tabel filter rantai FORWARD.

Host titik akhir


Kebijakan Endpoint Host (2)


Selain CNI (antarmuka jaringan kontainer), kebijakan Calico memberikan kemampuan untuk melindungi host secara langsung. Di Calico, Anda dapat membuat titik akhir host dengan menentukan kombinasi antarmuka host dan, jika perlu, nomor port. Penerapan kebijakan untuk entitas ini dicapai menggunakan tabel filter dalam rantai INPUT dan OUTPUT. Seperti dapat dilihat dari diagram, (2) mereka diterapkan pada proses lokal pada node / host. Artinya, jika Anda membuat kebijakan yang berlaku untuk titik akhir host, itu tidak akan mempengaruhi lalu lintas pergi ke / dari pod Anda. Tetapi ia menyediakan antarmuka / sintaks tunggal untuk memblokir lalu lintas untuk host dan pod Anda menggunakan kebijakan Calico. Ini sangat menyederhanakan proses pengelolaan kebijakan untuk jaringan heterogen. Mengkonfigurasi kebijakan titik akhir host untuk meningkatkan perlindungan cluster adalah kasus penggunaan penting lainnya.

Kebijakan Berlaku Berlanjut (3)


Opsi ApplyOnForward tersedia dalam kebijakan jaringan global Calico untuk memungkinkan kebijakan berlaku untuk semua lalu lintas yang melewati titik akhir host, termasuk lalu lintas yang akan diteruskan oleh tuan rumah. Lalu lintas ini termasuk dikirim ke pod lokal atau di 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 melacak lalu lintas host saat menggunakan router virtual atau perangkat lunak NAT.

Perhatikan bahwa jika Anda perlu menerapkan kebijakan jaringan yang sama untuk proses host dan pod, maka Anda tidak harus menggunakan opsi ApplyOnForward. Anda hanya perlu membuat label untuk titik hostend akhir dan titik akhir beban kerja (pod) yang diinginkan. Calico cukup pintar untuk menerapkan kebijakan berbasis label, terlepas dari jenis titik akhir (hostendpoint atau beban kerja).

Kebijakan PreDNAT (4)


Di Kubernetes, port entitas layanan dapat diteruskan ke luar menggunakan opsi NodePorts atau, secara opsional (saat menggunakan Calico), dengan mendeklarasikannya melalui opsi IP Cluster atau IP Eksternal. Kube-proxy menyeimbangkan lalu lintas masuk yang terikat ke layanan ke pod dari layanan yang sesuai menggunakan DNAT. Dengan ini, bagaimana Anda menerapkan kebijakan untuk lalu lintas yang datang melalui NodePorts? Agar 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-kebijakan ini diterapkan pada (4) dalam diagram - dalam tabel mangle pada rantai PREROUTING - tepat sebelum DNAT. Kebijakan pesanan biasa tidak dihormati di sini, karena penerapan kebijakan ini terjadi jauh lebih awal di sepanjang jalur pemrosesan lalu lintas. Namun, kebijakan preDNAT menghormati urutan aplikasi di antara mereka sendiri.

Saat membuat kebijakan dengan pra-DNAT, penting untuk memperhatikan lalu lintas yang ingin Anda proses dan membiarkan sebagian besar ditolak. Lalu lintas yang ditandai sebagai 'diizinkan' dalam kebijakan pra-DNAT tidak akan lagi diperiksa oleh kebijakan hostendpoint, sementara lalu lintas ketika kebijakan pra-DNAT gagal akan terus mengalir melalui sisa rantai.
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 diarahkan ke pod atau ke node lain.

Kebijakan Tidak Dilacak (5)


Jaringan dan aplikasi dapat memiliki perbedaan besar dalam perilaku. Dalam beberapa kasus ekstrem, aplikasi dapat menghasilkan banyak koneksi jangka pendek. Ini dapat menyebabkan kurangnya memori untuk conntrack (komponen utama dari tumpukan jaringan Linux). Secara tradisional, untuk menjalankan jenis aplikasi ini di Linux, Anda perlu mengkonfigurasi atau menonaktifkan conntrack secara manual, atau menulis aturan iptables untuk memotong conntrack. Kebijakan yang tidak dilacak di Calico adalah opsi yang lebih sederhana dan lebih efisien jika Anda ingin memproses koneksi secepat mungkin. Misalnya, jika Anda menggunakan memcache masif atau sebagai tindakan perlindungan tambahan terhadap DDOS .

Baca posting blog ini (atau terjemahan kami) untuk informasi lebih lanjut, termasuk tes kinerja menggunakan kebijakan yang tidak terlacak.

Ketika Anda mengatur opsi "doNotTrack: true" ke Calico globalNetworkPolicy, itu menjadi kebijakan ** tidak terlacak ** dan diterapkan pada tahap paling awal dari pipa pemrosesan paket Linux. Jika Anda 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 yang tidak dilacak, itu ditandai untuk menonaktifkan pelacakan koneksi untuk paket ini. Itu berarti:

  • Kebijakan yang tidak terlacak diterapkan untuk setiap paket. Tidak ada konsep koneksi (atau aliran). Kurangnya koneksi memerlukan beberapa konsekuensi penting:
  • , , , ( Calico conntrack, ).
  • untracked workload Kubernetes (pod’), pod’.
  • NAT ( ​​ NAT conntrack).
  • « » untracked- . , , untracked- ( ).
  • Kebijakan yang tidak dilacak diterapkan di awal pipa pemrosesan paket. Ini sangat penting untuk dipahami ketika membuat kebijakan Calico. Anda dapat memiliki kebijakan untuk pod dengan pesanan: 1 dan kebijakan yang tidak dilacak dengan pesanan: 1000. Itu tidak masalah. Kebijakan yang tidak terlacak akan diterapkan sebelum kebijakan untuk pod. Kebijakan yang tidak dilacak hanya menghormati urutan pelaksanaannya saja.

Karena salah satu tujuan dari kebijakan doNotTrack adalah untuk menegakkan kebijakan tersebut pada tahap paling awal dari pipa pemrosesan paket Linux, Calico mewajibkan untuk menentukan opsi applyOnForward saat menggunakan doNotTrack. Mengacu pada diagram pemrosesan paket, perhatikan bahwa kebijakan yang tidak terlacak (5) diterapkan sebelum keputusan routing apa pun. Lalu lintas dapat diarahkan ke proses host, atau dapat diarahkan ke pod atau ke node lain.

Ringkasan


Kami melihat berbagai opsi kebijakan (Host endpoint, ApplyOnForward, preDNAT, dan Untracked) di Calico dan bagaimana mereka berlaku untuk pemrosesan paket. Memahami pekerjaan mereka membantu dalam mengembangkan kebijakan yang efektif dan aman. Dengan Calico, Anda dapat menggunakan kebijakan jaringan global, yang berlaku untuk label (sekelompok node dan pod) dan menerapkan kebijakan dengan berbagai parameter. Hal ini memungkinkan para profesional keamanan dan desain jaringan dengan mudah melindungi segera "segalanya" (tipe titik akhir) menggunakan bahasa kebijakan yang sama dengan kebijakan Calico.


Pengakuan: Saya ingin mengucapkan terima kasih kepada Sean Crampton dan Alex Pollitt atas ulasan mereka dan atas informasi berharga.

More articles:


All Articles