ქსელის პოლიტიკის ვარიანტების გააზრება Calico-სთან ერთად

Calico ქსელის მოდული უზრუნველყოფს ქსელის პოლიტიკის ფართო სპექტრს ერთიანი სინტაქსით, რათა დაიცვან ტექნიკის ჰოსტები, ვირტუალური მანქანები და პოდი. ეს წესები შეიძლება გამოყენებულ იქნას სახელთა სივრცეში ან იყოს გლობალური ქსელის პოლიტიკა, რომელიც ვრცელდება მასპინძლის საბოლოო წერტილი (პირდაპირ ჰოსტზე გაშვებული აპლიკაციების დასაცავად - ჰოსტი შეიძლება იყოს სერვერი ან ვირტუალური მანქანა) ან სამუშაო დატვირთვის საბოლოო წერტილი (კონტეინერებში ან მასპინძელ ვირტუალურ მანქანებში გაშვებული აპლიკაციების დასაცავად). Calico-ს პოლიტიკა საშუალებას გაძლევთ გამოიყენოთ უსაფრთხოების ზომები პაკეტის გზის სხვადასხვა წერტილში ისეთი ვარიანტების გამოყენებით, როგორიცაა preDNAT, unraracked და applyOnForward. იმის გაგება, თუ როგორ მუშაობს ეს პარამეტრები, დაგეხმარებათ გააუმჯობესოთ თქვენი მთლიანი სისტემის უსაფრთხოება და შესრულება. ეს სტატია განმარტავს ამ Calico-ს პოლიტიკის ვარიანტების არსს (preDNAT, unraracked და applyOnForward), რომლებიც გამოიყენება ჰოსტის ბოლო წერტილებზე, აქცენტით იმაზე, თუ რა ხდება პაკეტის დამუშავების ბილიკებში (iptabels ჯაჭვები).

ეს სტატია ვარაუდობს, რომ თქვენ გაქვთ ძირითადი გაგება, თუ როგორ მუშაობს Kubernetes და Calico ქსელის პოლიტიკა. თუ არა, გირჩევთ სცადოთ ძირითადი ქსელის პოლიტიკის გაკვეთილი и მასპინძლის დაცვის გაკვეთილი Calico-ს გამოყენება ამ სტატიის წაკითხვამდე. ჩვენ ასევე ველით, რომ გქონდეთ ნაწარმოების ძირითადი გაგება iptables ლინუქსში.

კალიკო გლობალური ქსელის პოლიტიკა საშუალებას გაძლევთ გამოიყენოთ წვდომის წესები ეტიკეტების მიხედვით (ჰოსტების ჯგუფებზე და სამუშაო დატვირთვებზე/პოდებზე). ეს ძალიან სასარგებლოა, თუ ერთად იყენებთ ჰეტეროგენულ სისტემებს - ვირტუალურ მანქანებს, სისტემას უშუალოდ აპარატურაზე ან კუბერნეტის ინფრასტრუქტურაზე. გარდა ამისა, შეგიძლიათ დაიცვათ თქვენი კლასტერი (კვანძები) დეკლარაციული პოლიტიკის ნაკრების გამოყენებით და გამოიყენოთ ქსელის პოლიტიკა შემომავალ ტრაფიკზე (მაგალითად, NodePorts ან გარე IP-ების სერვისის მეშვეობით).

ფუნდამენტურ დონეზე, როდესაც Calico აკავშირებს პოდს ქსელთან (იხილეთ დიაგრამა ქვემოთ), ის აკავშირებს მას ჰოსტთან ვირტუალური Ethernet ინტერფეისის (veth) გამოყენებით. პოდის მიერ გაგზავნილი ტრაფიკი ჰოსტში მოდის ამ ვირტუალური ინტერფეისიდან და მუშავდება ისე, როგორც ფიზიკური ქსელის ინტერფეისიდან. ნაგულისხმევად, Calico ასახელებს ამ ინტერფეისებს caliXXX. ვინაიდან ტრაფიკი ვირტუალური ინტერფეისის მეშვეობით მოდის, ის გადის iptables-ში, თითქოს pod ერთი ჰოპის დაშორებით იყოს. ამიტომ, როდესაც ტრაფიკი მოდის/პოდიდან მოდის, ის გადამისამართებულია მასპინძლის თვალსაზრისით.

Kubernetes-ის კვანძზე, რომელიც მუშაობს Calico-ზე, შეგიძლიათ ვირტუალური ინტერფეისი (veth) სამუშაო დატვირთვაზე, შემდეგნაირად. ქვემოთ მოცემულ მაგალითში ხედავთ, რომ veth#10 (calic1cbf1ca0f8) დაკავშირებულია cnx-manager-*-თან 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
...

იმის გათვალისწინებით, რომ Calico ქმნის veth ინტერფეისს თითოეული დატვირთვისთვის, როგორ ახორციელებს ის პოლიტიკას? ამისათვის Calico ქმნის კაკვებს პაკეტის დამუშავების გზის სხვადასხვა ჯაჭვებში iptables-ის გამოყენებით.

ქვემოთ მოცემულ დიაგრამაზე ნაჩვენებია ჯაჭვები, რომლებიც ჩართულია პაკეტის დამუშავებაში iptables-ში (ან netfilter ქვესისტემაში). როდესაც პაკეტი ჩამოდის ქსელის ინტერფეისის მეშვეობით, ის ჯერ გადის PREROUTING ჯაჭვში. შემდეგ მიიღება მარშრუტიზაციის გადაწყვეტილება და ამის საფუძველზე პაკეტი გადის INPUT-ზე (მიმართული ჰოსტის პროცესებზე) ან FORWARD-ზე (მიმართულია პოდზე ან ქსელის სხვა კვანძზე). ლოკალური პროცესიდან, პაკეტი გადის OUTPUT და შემდეგ POSTROUTING ჯაჭვში, სანამ კაბელზე გაიგზავნება.

გაითვალისწინეთ, რომ pod არის ასევე გარე ერთეული (დაკავშირებული veth-თან) iptables დამუშავების თვალსაზრისით. მოდით შევაჯამოთ:

• გადაგზავნილი ტრაფიკი (ნატი, მარშრუტირებული ან პოდიდან/პოდიდან) გადის PREROUTING - FORWARD - POSTROUTING ჯაჭვებში.
• ტრაფიკი ლოკალურ მასპინძელ პროცესამდე გადის PREROUTING - INPUT ჯაჭვში.
• ადგილობრივი მასპინძლის პროცესიდან ტრაფიკი გადის OUTPUT - POSTROUTING ჯაჭვის მეშვეობით.

Calico გთავაზობთ პოლიტიკის ვარიანტებს, რომლებიც საშუალებას გაძლევთ გამოიყენოთ პოლიტიკა ყველა ქსელში. ამის გათვალისწინებით, მოდით გადავხედოთ პოლიტიკის კონფიგურაციის სხვადასხვა ვარიანტებს, რომლებიც ხელმისაწვდომია Calico-ში. ქვემოთ მოცემული ვარიანტების ჩამონათვალში რიცხვები შეესაბამება ზემოთ მოცემულ დიაგრამაში მოცემულ ციფრებს.

1. სამუშაო დატვირთვის საბოლოო წერტილის (პოდ) პოლიტიკა
2. ჰოსტის საბოლოო წერტილის პოლიტიკა
3. ApplyOnForward ვარიანტი
4. PreDNAT პოლიტიკა
5. გაუთვალისწინებელი პოლიტიკა

დავიწყოთ იმით, თუ როგორ გამოიყენება წესები სამუშაო დატვირთვის ბოლო წერტილებზე (Kubernetes pods ან OpenStack VMs) და შემდეგ გადავხედოთ პოლიტიკის ვარიანტებს ჰოსტის ბოლო წერტილებისთვის.

სამუშაო დატვირთვის საბოლოო წერტილები

სამუშაო დატვირთვის საბოლოო წერტილის პოლიტიკა (1)

ეს არის თქვენი kubernetes pods დასაცავად. Calico მხარს უჭერს Kubernetes NetworkPolicy-თან მუშაობას, მაგრამ ასევე უზრუნველყოფს დამატებით პოლიტიკას - Calico NetworkPolicy და GlobalNetworkPolicy. Calico ქმნის ჯაჭვს თითოეული პოდისთვის (სამუშაო დატვირთვისთვის) და ამაგრებს INPUT და OUTPUT ჯაჭვებს დატვირთვისთვის FORWARD ჯაჭვის ფილტრის ცხრილზე.

ჰოსტის საბოლოო წერტილები

ჰოსტის საბოლოო წერტილის პოლიტიკა (2)

CNI-ს (კონტეინერის ქსელის ინტერფეისის) გარდა, Calico პოლიტიკა უზრუნველყოფს თავად ჰოსტის დაცვის შესაძლებლობას. Calico-ში შეგიძლიათ შექმნათ ჰოსტის საბოლოო წერტილი ჰოსტის ინტერფეისის კომბინაციის და, საჭიროების შემთხვევაში, პორტის ნომრების მითითებით. ამ ერთეულისთვის პოლიტიკის აღსრულება მიიღწევა ფილტრის ცხრილის გამოყენებით INPUT და OUTPUT ჯაჭვებში. როგორც დიაგრამიდან ხედავთ, (2) ისინი მიმართავენ ლოკალურ პროცესებს კვანძზე/ჰოსტზე. ანუ, თუ თქვენ შექმნით პოლიტიკას, რომელიც ეხება მასპინძლის საბოლოო წერტილს, ეს არ იმოქმედებს ტრაფიკზე, რომელიც მიდის თქვენს პოდებში. მაგრამ ის უზრუნველყოფს ერთ ინტერფეისს/სინტაქსს თქვენი მასპინძლისა და პოდებისთვის ტრაფიკის დასაბლოკად Calico-ს პოლიტიკის გამოყენებით. ეს მნიშვნელოვნად ამარტივებს ჰეტეროგენული ქსელის პოლიტიკის მართვის პროცესს. ჰოსტის საბოლოო წერტილის პოლიტიკის კონფიგურაცია კლასტერების უსაფრთხოების გასაძლიერებლად არის გამოყენების კიდევ ერთი მნიშვნელოვანი შემთხვევა.

ApplyOnForward პოლიტიკა (3)

ApplyOnForward ვარიანტი ხელმისაწვდომია Calico-ს გლობალური ქსელის პოლიტიკაში, რათა დაუშვას პოლიტიკის გამოყენება ჰოსტის ბოლო წერტილის გავლით გამავალი ტრაფიკის მიმართ, მათ შორის ტრაფიკზე, რომელიც გადამისამართდება მასპინძლის მიერ. ეს მოიცავს ტრაფიკს, რომელიც გადამისამართებულია ადგილობრივ პოდში ან ქსელის სხვაგან. Calico მოითხოვს ამ პარამეტრის ჩართვას პოლიტიკისთვის, რომელიც იყენებს PreDNAT-ს და არ არის თვალყურის დევნება, იხილეთ შემდეგი სექციები. გარდა ამისა, ApplyOnForward შეიძლება გამოყენებულ იქნას ჰოსტის ტრაფიკის მონიტორინგისთვის იმ შემთხვევებში, როდესაც გამოიყენება ვირტუალური როუტერი ან პროგრამული უზრუნველყოფა NAT.

გაითვალისწინეთ, რომ თუ თქვენ გჭირდებათ იგივე ქსელის პოლიტიკის გამოყენება როგორც ჰოსტის პროცესებზე, ასევე პოდებზე, მაშინ არ გჭირდებათ ApplyOnForward ოფციის გამოყენება. ყველაფერი რაც თქვენ უნდა გააკეთოთ არის ლეიბლის შექმნა საჭირო ჰოსტენდის წერტილისა და სამუშაო დატვირთვის ბოლო წერტილისთვის (pod). Calico საკმარისად ჭკვიანია იმისათვის, რომ განახორციელოს პოლიტიკა ლეიბლებზე დაფუძნებული, განურჩევლად საბოლოო წერტილის ტიპისა (ჰოსტენდის წერტილი ან სამუშაო დატვირთვა).

PreDNAT პოლიტიკა (4)

Kubernetes-ში, სერვისული ერთეულის პორტები შეიძლება გამოჩნდეს გარედან NodePorts ოფციის გამოყენებით ან სურვილისამებრ (Calico-ს გამოყენებისას), კლასტერული IP-ების ან გარე IP-ების ოფციების გამოყენებით მათი რეკლამირებით. Kube-პროქსი აბალანსებს შემომავალ ტრაფიკს, რომელიც უკავშირდება სერვისს შესაბამისი სერვისის პოდებში DNAT-ის გამოყენებით. ამის გათვალისწინებით, როგორ ახორციელებთ პოლიტიკას NodePorts-ით შემოსული ტრაფიკისთვის? იმის უზრუნველსაყოფად, რომ ეს წესები გამოყენებული იქნება ტრაფიკის დამუშავებამდე DNAT-ის მიერ (რომელიც არის რუქა ჰოსტ:პორტსა და შესაბამის სერვისს შორის), Calico უზრუნველყოფს პარამეტრს globalNetworkPolicy-სთვის, სახელწოდებით "preDNAT: true".

როდესაც ჩართულია pre-DNAT, ეს პოლიტიკები განხორციელდება (4) დიაგრამაში - PREROUTING ჯაჭვის mangle ცხრილში - DNAT-მდე უშუალოდ. წესების ჩვეული თანმიმდევრობა აქ არ არის დაცული, რადგან ამ პოლიტიკის გამოყენება გაცილებით ადრე ხდება ტრაფიკის დამუშავების გზაზე. თუმცა, preDNAT პოლიტიკა პატივს სცემს განაცხადის თანმიმდევრობას ერთმანეთში.

DNAT-მდე პოლიტიკის შექმნისას მნიშვნელოვანია იყოთ ფრთხილად იმ ტრაფიკის მიმართ, რომლის დამუშავებაც გსურთ და დაუშვათ უმრავლესობის უარყოფა. ტრაფიკი, რომელიც მონიშნულია, როგორც „დაშვება“ წინა-DNAT პოლიტიკაში აღარ შემოწმდება ჰოსტინგის წერტილის პოლიტიკით, ხოლო ტრაფიკი, რომელიც არ შეესაბამება DNAT-მდე პოლიტიკას, გაგრძელდება დარჩენილი ჯაჭვების მეშვეობით.
Calico-მ სავალდებულო გახადა ApplyOnForward ოფციის ჩართვა preDNAT-ის გამოყენებისას, რადგან განსაზღვრებით ტრაფიკის დანიშნულება ჯერ არ არის შერჩეული. ტრაფიკი შეიძლება იყოს მიმართული მასპინძელ პროცესზე, ან შეიძლება გადამისამართდეს პოდში ან სხვა კვანძში.

თვალთვალის გარეშე პოლიტიკა (5)

ქსელებსა და აპლიკაციებს შეიძლება ჰქონდეთ დიდი განსხვავებები ქცევაში. ზოგიერთ ექსტრემალურ შემთხვევაში, აპლიკაციებმა შეიძლება წარმოქმნან მრავალი ხანმოკლე კავშირი. ამან შეიძლება გამოიწვიოს conntrack-ის (Linux ქსელის სტეკის ძირითადი კომპონენტი) მეხსიერების ამოწურვა. ტრადიციულად, Linux-ზე ამ ტიპის აპლიკაციების გასაშვებად, თქვენ მოგიწევთ ხელით დააკონფიგურიროთ ან გამორთოთ contrack, ან დაწეროთ iptables წესები კონტრაქტის გვერდის ავლით. უკონტროლო პოლიტიკა Calico-ში უფრო მარტივი და ეფექტური ვარიანტია, თუ გსურთ კავშირების რაც შეიძლება სწრაფად დამუშავება. მაგალითად, თუ იყენებთ მასიურს მემქეში ან დაცვის დამატებითი ღონისძიება DDoS.

Წაიკითხე ეს დღიურში შეტყობინება (ან ჩვენი თარგმანი) დამატებითი ინფორმაციისთვის, შესრულების ტესტების ჩათვლით, უკონტროლო პოლიტიკის გამოყენებით.

როდესაც Calico globalNetworkPolicy-ში „doNotTrack: true“ ოფციას აყენებთ, ის იქცევა **მიუწვდომელ** პოლიტიკად და გამოიყენება ძალიან ადრე Linux-ის პაკეტების დამუშავების მილსადენში. ზემოთ მოცემულ დიაგრამას რომ გადავხედოთ, დაუდევრებელი პოლიტიკა გამოიყენება PREROUTING და OUTPUT ჯაჭვებში ნედლეულ ცხრილში, სანამ დაიწყება კავშირის თვალყურის დევნება (conntrack). როდესაც პაკეტი ნებადართულია უკონტროლო პოლიტიკით, იგი აღინიშნება ამ პაკეტისთვის კავშირის თვალთვალის გათიშვის მიზნით. Ეს ნიშნავს:

• უკონტროლო პოლიტიკა გამოიყენება თითო პაკეტზე. კავშირის (ან დინების) ცნება არ არსებობს. კავშირების ნაკლებობას აქვს რამდენიმე მნიშვნელოვანი შედეგი:
• თუ გსურთ დაუშვათ როგორც მოთხოვნის, ასევე პასუხების ტრაფიკი, გჭირდებათ წესი როგორც შემომავალი, ასევე გამავალი (რადგან Calico ჩვეულებრივ იყენებს კონტრაქტს საპასუხო ტრაფიკის დასაშვებად აღსანიშნავად).
• უკონტროლო პოლიტიკა არ მუშაობს Kubernetes-ის დატვირთვებზე (pods), რადგან ამ შემთხვევაში არ არსებობს გზა პოდიდან გამავალი კავშირის თვალყურის დევნება.
• NAT არ მუშაობს გამართულად უკონტროლო პაკეტებთან (რადგან ბირთვი ინახავს NAT რუკებს conntrack-ში).
• უკონტროლო პოლიტიკაში „ყველას დაშვების“ წესის გავლისას, ყველა პაკეტი მონიშნული იქნება, როგორც მიუწვდომელი. ეს თითქმის ყოველთვის არ არის ის, რაც თქვენ გინდათ, ამიტომ მნიშვნელოვანია იყოთ ძალიან შერჩევითი პაკეტების მიმართ, რომლებიც დაშვებულია უკონტროლო პოლიტიკით (და მიეცით საშუალება ტრაფიკის უმეტესობას გაიაროს ნორმალური თვალთვალის პოლიტიკა).
• უკონტროლო პოლიტიკა გამოიყენება პაკეტის დამუშავების მილსადენის დასაწყისშივე. ამის გაგება ძალიან მნიშვნელოვანია Calico-ს პოლიტიკის შექმნისას. თქვენ შეგიძლიათ გქონდეთ პოდ პოლიტიკა შეკვეთით:1 და დაუდევრებელი პოლიტიკა შეკვეთით:1000. ამას მნიშვნელობა არ ექნება. Untracked პოლიტიკა გამოყენებული იქნება პოდისთვის პოლიტიკამდე. უკონტროლო პოლიტიკა პატივს სცემს აღსრულების ბრძანებას მხოლოდ ერთმანეთთან.

იმის გამო, რომ doNotTrack პოლიტიკის ერთ-ერთი მიზანია პოლიტიკის აღსრულება Linux-ის პაკეტების დამუშავების მილსადენის ძალიან ადრეულ პერიოდში, Calico სავალდებულო გახდის doNotTrack-ის გამოყენებისას applicationOnForward ოფციის მითითებას. პაკეტების დამუშავების დიაგრამაზე მითითებით, გაითვალისწინეთ, რომ უკონტროლო(5) პოლიტიკა გამოიყენება მარშრუტიზაციის ნებისმიერ გადაწყვეტილებამდე. ტრაფიკი შეიძლება იყოს მიმართული მასპინძელ პროცესზე, ან შეიძლება გადამისამართდეს პოდში ან სხვა კვანძში.

შედეგები

ჩვენ გადავხედეთ პოლიტიკის სხვადასხვა ვარიანტს (Host endpoint, ApplyOnForward, preDNAT და Untracked) Calico-ში და როგორ გამოიყენება ისინი პაკეტის დამუშავების გზაზე. იმის გაგება, თუ როგორ მუშაობენ ისინი, გვეხმარება ეფექტური და უსაფრთხო პოლიტიკის შემუშავებაში. Calico-ს საშუალებით შეგიძლიათ გამოიყენოთ გლობალური ქსელის პოლიტიკა, რომელიც ეხება ლეიბლს (კვანძებისა და კვანძების ჯგუფს) და გამოიყენოთ პოლიტიკები სხვადასხვა პარამეტრით. ეს საშუალებას აძლევს უსაფრთხოებისა და ქსელის დიზაინის პროფესიონალებს, მოხერხებულად დაიცვან „ყველაფერი“ (ბოლო წერტილების ტიპები) ერთდროულად Calico-ს პოლიტიკის ერთი პოლიტიკის ენის გამოყენებით.

აღიარება: მინდა მადლობა გადავუხადო შონ კრემპტონი и ალექსა პოლიტა მათი განხილვისა და ღირებული ინფორმაციისთვის.

წყარო: www.habr.com