Հասկանալով Calico-ի հետ ցանցային քաղաքականության կիրարկման տարբերակները

Calico ցանցային հավելվածը տրամադրում է ցանցային քաղաքականության լայն շրջանակ՝ միասնական շարահյուսությամբ՝ պաշտպանելու ապարատային հոսթերը, վիրտուալ մեքենաները և պատյանները: Այս քաղաքականությունները կարող են կիրառվել անունների տարածքում կամ լինել գլոբալ ցանցային քաղաքականություն, որը վերաբերում է հյուրընկալող վերջնակետ (անմիջապես հոսթի վրա աշխատող հավելվածները պաշտպանելու համար - հոսթը կարող է լինել սերվեր կամ վիրտուալ մեքենա) կամ ծանրաբեռնվածության վերջնակետ (կոնտեյներներում կամ տեղակայված վիրտուալ մեքենաներում աշխատող հավելվածները պաշտպանելու համար): Calico-ի քաղաքականությունը թույլ է տալիս կիրառել անվտանգության միջոցներ փաթեթի ճանապարհի տարբեր կետերում՝ օգտագործելով այնպիսի տարբերակներ, ինչպիսիք են preDNAT, unraracked և applyOnForward: Հասկանալը, թե ինչպես են աշխատում այս տարբերակները, կարող է օգնել բարելավել ձեր ընդհանուր համակարգի անվտանգությունն ու արդյունավետությունը: Այս հոդվածը բացատրում է Calico քաղաքականության այս ընտրանքների էությունը (preDNAT, unracked և applyOnForward), որոնք կիրառվում են հոսթի վերջնակետերի վրա՝ շեշտը դնելով այն բանի վրա, թե ինչ է տեղի ունենում փաթեթների մշակման ուղիներում (iptabels շղթաներ):

Այս հոդվածը ենթադրում է, որ դուք հիմնական հասկացողություն ունեք, թե ինչպես են աշխատում Kubernetes-ի և Calico-ի ցանցային քաղաքականությունները: Եթե ​​ոչ, խորհուրդ ենք տալիս փորձել հիմնական ցանցային քաղաքականության ձեռնարկ и հյուրընկալող պաշտպանության ձեռնարկ օգտագործելով Calico-ն այս հոդվածը կարդալուց առաջ: Մենք նաև ակնկալում ենք, որ դուք կունենաք աշխատանքի հիմնական պատկերացում iptables linux-ում։

Calico- ն գլոբալ ցանցային քաղաքականություն թույլ է տալիս կիրառել մուտքի կանոնների մի շարք ըստ պիտակների (հոսթների խմբերի և աշխատանքային ծանրաբեռնվածության/փոդերի): Սա շատ օգտակար է, եթե դուք միասին օգտագործում եք տարասեռ համակարգեր՝ վիրտուալ մեքենաներ, համակարգ անմիջապես սարքաշարի վրա կամ kubernetes ենթակառուցվածք: Բացի այդ, դուք կարող եք պաշտպանել ձեր կլաստերը (հանգույցները)՝ օգտագործելով մի շարք դեկլարատիվ քաղաքականություն և կիրառել ցանցային քաղաքականություն մուտքային տրաֆիկի նկատմամբ (օրինակ՝ NodePorts կամ External IPs ծառայության միջոցով):

Հիմնարար մակարդակում, երբ Calico-ն միացնում է պատը ցանցին (տես ստորև բերված գծապատկերը), այն միացնում է հոսթին, օգտագործելով վիրտուալ Ethernet ինտերֆեյս (veth): Փոդի կողմից ուղարկված տրաֆիկը գալիս է հյուրընկալողին այս վիրտուալ ինտերֆեյսից և մշակվում է այնպես, ինչպես որ այն ստացվել է ֆիզիկական ցանցային ինտերֆեյսից: Լռելյայնորեն, Calico-ն այս միջերեսներն անվանում է caliXXX: Քանի որ երթևեկությունը գալիս է վիրտուալ ինտերֆեյսի միջոցով, այն անցնում է iptables-ի միջով այնպես, ասես պատիճը մեկ թռիչք հեռավորության վրա է: Հետևաբար, երբ երթևեկությունը գալիս է դեպի պատիճ/մուտք, այն փոխանցվում է հյուրընկալողի տեսանկյունից:

Calico-ով աշխատող Kubernetes հանգույցում դուք կարող եք վիրտուալ ինտերֆեյսը (veth) համապատասխանեցնել աշխատանքի ծանրաբեռնվածությանը հետևյալ կերպ. Ստորև բերված օրինակում կարող եք տեսնել, որ veth#10 (calic1cbf1ca0f8) միացված է cnx-manager-*-ին calico-monitoring namespace-ում:

[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-ով (ուղղված է դեպի pod կամ ցանցի մեկ այլ հանգույց): Տեղական գործընթացից փաթեթը անցնում է OUTPUT և այնուհետև POSTROUTING շղթայով, նախքան մալուխով ներքև ուղարկելը:

Նկատի ունեցեք, որ pod-ը նաև արտաքին կառույց է (կապված է veth-ի հետ) iptables-ի մշակման առումով: Ամփոփենք.

• Փոխանցվող երթևեկությունը (նատ, երթուղղված կամ դեպի պատիճ) անցնում է PREROUTING - FORWARD - POSTROUTING շղթաներով:
• Տրաֆիկը դեպի տեղական ընդունող գործընթաց անցնում է PREROUTING - INPUT շղթայով:
• Տեղական հյուրընկալող գործընթացից երթևեկությունը անցնում է OUTPUT - POSTROUTING շղթայով:

Calico-ն տրամադրում է քաղաքականության տարբերակներ, որոնք թույլ են տալիս կիրառել քաղաքականություն բոլոր շղթաներում: Հաշվի առնելով դա՝ եկեք նայենք Calico-ում առկա քաղաքականության կազմաձևման տարբեր տարբերակներին: Ստորև ներկայացված ընտրանքների ցանկում թվերը համապատասխանում են վերը նշված գծապատկերի թվերին:

1. Աշխատանքային ծանրաբեռնվածության վերջնակետի (pod) քաղաքականություն
2. Հյուրընկալողի վերջնական կետի քաղաքականություն
3. ApplyOnForward տարբերակ
4. PreDNAT քաղաքականություն
5. Չհետագծված քաղաքականություն

Եկեք սկսենք նայելով, թե ինչպես են քաղաքականությունները կիրառվում աշխատանքային ծանրաբեռնվածության վերջնակետերի նկատմամբ (Kubernetes pods կամ OpenStack VMs) և այնուհետև դիտարկենք հյուրընկալող վերջնական կետերի քաղաքականության տարբերակները:

Աշխատանքային ծանրաբեռնվածության վերջնակետեր

Աշխատանքային ծանրաբեռնվածության վերջնակետի քաղաքականություն (1)

Սա ձեր kubernetes պատիճները պաշտպանելու տարբերակ է: 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-ն օգտագործելիս)՝ գովազդելով դրանք՝ օգտագործելով Cluster IP-ների կամ External IP-ների տարբերակները: Kube-proxy-ը հավասարակշռում է մուտքային երթևեկը, որը կապված է ծառայությանը դեպի համապատասխան ծառայության բլոկները՝ օգտագործելով DNAT: Հաշվի առնելով դա, ինչպե՞ս եք կիրառում NodePorts-ով եկող տրաֆիկի քաղաքականությունը: Ապահովելու համար, որ այս քաղաքականությունները կիրառվում են նախքան երթևեկի մշակումը DNAT-ի կողմից (որը քարտեզագրում է host:port-ի և համապատասխան ծառայության միջև), Calico-ն տրամադրում է պարամետր globalNetworkPolicy-ի համար, որը կոչվում է «preDNAT: true»:

Երբ pre-DNAT-ը միացված է, այս քաղաքականությունները կիրառվում են (4)-ում` գծապատկերում` PREROUTING շղթայի մառախուղի աղյուսակում, անմիջապես DNAT-ից առաջ: Քաղաքականությունների սովորական կարգն այստեղ չի պահպանվում, քանի որ այդ քաղաքականությունների կիրառումը տեղի է ունենում շատ ավելի վաղ երթևեկության մշակման ճանապարհին: Այնուամենայնիվ, preDNAT քաղաքականությունը հարգում է կիրառման կարգը միմյանց միջև:

ՆախաDNAT-ի հետ քաղաքականություն ստեղծելիս կարևոր է զգույշ լինել երթևեկի նկատմամբ, որը ցանկանում եք մշակել և թույլ տալ, որ մեծամասնությունը մերժվի: ՆախաDNAT քաղաքականության մեջ «թույլատրել» նշված երթևեկությունն այլևս չի ստուգվի հոսթենթակետի քաղաքականության կողմից, մինչդեռ երթևեկությունը, որը չի համապատասխանում նախաDNAT քաղաքականությանը, կշարունակվի մնացած շղթաներով:
Calico-ն պարտադիր է դարձրել preDNAT-ն օգտագործելու ժամանակ applyOnForward տարբերակը միացնելը, քանի որ ըստ սահմանման տրաֆիկի նպատակակետը դեռ ընտրված չէ: Երթևեկությունը կարող է ուղղվել դեպի հյուրընկալող գործընթաց, կամ այն ​​կարող է փոխանցվել դեպի պատիճ կամ մեկ այլ հանգույց:

Չհետևված քաղաքականություն (5)

Ցանցերը և հավելվածները կարող են մեծ տարբերություններ ունենալ վարքի մեջ: Որոշ ծայրահեղ դեպքերում հավելվածները կարող են ստեղծել շատ կարճատև կապեր: Սա կարող է հանգեցնել conntrack-ի (Linux ցանցային ցանցի հիմնական բաղադրիչ) հիշողության սպառման: Ավանդաբար, այս տեսակի հավելվածները Linux-ում գործարկելու համար պետք է ձեռքով կարգավորել կամ անջատել conntrack-ը կամ գրել iptables-ի կանոններ՝ conntrack-ը շրջանցելու համար: Calico-ում չհետևված քաղաքականությունն ավելի պարզ և արդյունավետ տարբերակ է, եթե ցանկանում եք հնարավորինս արագ մշակել կապերը: Օրինակ, եթե դուք օգտագործում եք զանգվածային memcache կամ որպես լրացուցիչ պաշտպանության միջոց DDoS- ը.

Կարդա սա օրագրում Հաղորդագրություն (Կամ մեր թարգմանությունը) լրացուցիչ տեղեկությունների համար, ներառյալ կատարողականի թեստերը՝ օգտագործելով չհետևված քաղաքականությունը:

Երբ Calico globalNetworkPolicy-ում սահմանում եք «doNotTrack: true» տարբերակը, այն դառնում է **չհետևված** քաղաքականություն և կիրառվում է շատ վաղ Linux փաթեթների մշակման խողովակաշարում: Նայելով վերևի գծապատկերին՝ չհետևված քաղաքականությունները կիրառվում են չմշակված աղյուսակի PREROUTING և OUTPUT շղթաներում՝ նախքան կապի հետագծումը (conntrack) սկսելը: Երբ փաթեթը թույլատրվում է չհետևված քաղաքականության կողմից, այն նշվում է որպես անջատված կապի հետևում այդ փաթեթի համար: Դա նշանակում է:

• Չհետագծված քաղաքականությունը կիրառվում է յուրաքանչյուր փաթեթի հիման վրա: Կապի (կամ հոսքի) հասկացություն չկա: Կապերի բացակայությունն ունի մի քանի կարևոր հետևանք.
• Եթե ​​ցանկանում եք թույլատրել և՛ հարցումների, և՛ պատասխանների տրաֆիկը, ձեզ անհրաժեշտ է կանոն և՛ ներգնա, և՛ ելքային (քանի որ Calico-ն սովորաբար օգտագործում է conntrack՝ պատասխան տրաֆիկը որպես թույլատրված նշելու համար):
• Չհետագծված քաղաքականությունը չի գործում Kubernetes-ի աշխատանքային ծանրաբեռնվածության (pods) համար, քանի որ այս դեպքում ելքային կապը pod-ից հետևելու միջոց չկա:
• NAT-ը ճիշտ չի աշխատում չհետևված փաթեթների հետ (քանի որ միջուկը պահում է NAT քարտեզագրումը conntrack-ում):
• Չհետագծված քաղաքականության մեջ «թույլատրել բոլորին» կանոնն անցնելիս բոլոր փաթեթները կնշվեն որպես չհետևված: Գրեթե միշտ դա այն չէ, ինչ ցանկանում եք, ուստի կարևոր է լինել շատ ընտրողական այն փաթեթների նկատմամբ, որոնք թույլատրվում են չհետևված քաղաքականությամբ (և թույլ տալ, որ երթևեկության մեծ մասը անցնի սովորական հետևվող քաղաքականության միջոցով):
• Չհետևված քաղաքականությունները կիրառվում են փաթեթների մշակման խողովակաշարի հենց սկզբում: Սա շատ կարևոր է հասկանալ Calico-ի քաղաքականությունը ստեղծելիս: Դուք կարող եք ունենալ pod քաղաքականություն՝ order:1 և չհետևված քաղաքականություն՝ order:1000: Դա նշանակություն չի ունենա: «Չհետագծված» քաղաքականությունը կկիրառվի նախքան pod-ի քաղաքականությունը: Չհետևված քաղաքականությունները հարգում են կատարման կարգը միայն իրենց միջև:

Քանի որ doNotTrack քաղաքականության նպատակներից մեկը Linux-ի փաթեթների մշակման խողովակաշարում քաղաքականության շատ վաղ կիրառումն է, Calico-ն պարտադիր է դարձնում doNotTrack-ի օգտագործման ժամանակ applicationOnForward տարբերակը նշելը: Անդրադառնալով փաթեթների մշակման դիագրամին՝ նկատի ունեցեք, որ չհետևված(5) քաղաքականությունը կիրառվում է նախքան երթուղային որոշում կայացնելը: Երթևեկությունը կարող է ուղղվել դեպի հյուրընկալող գործընթաց, կամ այն ​​կարող է փոխանցվել դեպի պատիճ կամ մեկ այլ հանգույց:

Արդյունքները

Մենք դիտարկել ենք քաղաքականության տարբեր տարբերակներ (Host endpoint, ApplyOnForward, preDNAT և Untracked) Calico-ում և ինչպես են դրանք կիրառվում փաթեթների մշակման ճանապարհին: Հասկանալը, թե ինչպես են նրանք աշխատում, օգնում է մշակել արդյունավետ և անվտանգ քաղաքականություն: Calico-ի հետ դուք կարող եք օգտագործել գլոբալ ցանցային քաղաքականությունը, որը վերաբերում է պիտակին (հանգույցների և բլոկների խումբ) և կիրառել տարբեր պարամետրերով քաղաքականություն: Սա թույլ է տալիս անվտանգության և ցանցի նախագծման մասնագետներին հեշտությամբ պաշտպանել «ամեն ինչ» (վերջնական կետերի տեսակները) միանգամից՝ օգտագործելով մեկ քաղաքականության լեզու Calico քաղաքականության հետ:

Երախտագիտություն. Կցանկանայի շնորհակալություն հայտնել Շոն Քրեմփթոն и Ալեքսա Պոլլիտա նրանց վերանայման և արժեքավոր տեղեկատվության համար:

Source: www.habr.com