La reto-kromaĵo Calico provizas ampleksan gamon de retaj politikoj kun unuigita sintakso por protekti aparatajn gastigantojn, virtualajn maŝinojn kaj podojn. Ĉi tiuj politikoj povas esti aplikataj ene de nomspaco aŭ esti tutmondaj retaj politikoj kiuj validas por (por protekti aplikaĵojn kurantajn rekte sur la gastiganto - la gastiganto povas esti servilo aŭ virtuala maŝino) aŭ (por protekti aplikojn kurantajn en ujoj aŭ gastigitaj virtualaj maŝinoj). Calico-politikoj permesas al vi apliki sekurecajn mezurojn ĉe diversaj punktoj en la vojo de pakaĵeto uzante opciojn kiel preDNAT, unracked, kaj applyOnForward. Kompreni kiel funkcias ĉi tiuj opcioj povas helpi plibonigi la sekurecon kaj agadon de via ĝenerala sistemo. Ĉi tiu artikolo klarigas la esencon de ĉi tiuj Calico-politikaj elektoj (preDNAT, unraracked kaj applyOnForward) aplikataj al gastigaj finpunktoj, kun emfazo pri tio, kio okazas en pakaj pretigaj vojoj (iptabels-ĉenoj).
Ĉi tiu artikolo supozas, ke vi havas bazan komprenon pri kiel funkcias retaj politikoj de Kubernetes kaj Calico. Se ne, ni rekomendas provi ĝin и uzante Calico antaŭ legi ĉi tiun artikolon. Ni ankaŭ atendas, ke vi havu bazan komprenon pri la laboro en linukso.
Kalico permesas vin apliki aron de alirreguloj per etikedoj (al grupoj de gastigantoj kaj laborkvantoj/pods). Ĉi tio estas tre utila se vi uzas heterogenajn sistemojn kune - virtualajn maŝinojn, sistemon rekte sur aparataro aŭ kubernetes-infrastrukturo. Krome, vi povas protekti vian areton (nodojn) uzante aron de deklaraj politikoj kaj apliki retajn politikojn al envenanta trafiko (ekzemple per la servo NodePorts aŭ Eksteraj IP-oj).
Je fundamenta nivelo, kiam Calico ligas pod al la reto (vidu diagramon malsupre), ĝi ligas ĝin al la gastiganto uzante virtualan Ethernet-interfacon (veth). La trafiko sendita de la pod venas al la gastiganto de ĉi tiu virtuala interfaco kaj estas prilaborita en la sama maniero kiel se ĝi venis de fizika retinterfaco. Defaŭlte, Calico nomas ĉi tiujn interfacojn caliXXX. Ĉar la trafiko venas tra la virtuala interfaco, ĝi pasas tra iptables kvazaŭ la pod estus unu salto for. Tial, kiam trafiko venas al/de pod, ĝi estas plusendita de la vidpunkto de la gastiganto.
Sur Kubernetes-nodo funkcianta Calico, vi povas mapi virtualan interfacon (veth) al laborkvanto jene. En la malsupra ekzemplo, vi povas vidi, ke veth#10 (calic1cbf1ca0f8) estas konektita al cnx-manager-* en la nomspaco 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
...
Konsiderante ke Calico kreas vetan interfacon por ĉiu laborŝarĝo, kiel ĝi plenumas politikojn? Por fari tion, Calico kreas hokojn en diversaj ĉenoj de la paka pretiga vojo uzante iptables.
La diagramo malsupre montras la ĉenojn implikitajn en pakaĵpretigo en iptables (aŭ la netfilter-subsistemo). Kiam pakaĵeto alvenas tra reto-interfaco, ĝi unue trairas la PREROUTING-ĉenon. Voja decido tiam estas farita, kaj surbaze de tio, la pakaĵeto pasas tra aŭ INPUT (direktita al gastigaj procezoj) aŭ FORWARD (direktita al balgo aŭ alia nodo sur la reto). De la loka procezo, la pakaĵeto trairas la OUTPUT kaj poste POSTROUTING-ĉenon antaŭ esti sendita laŭ la kablo.
Notu ke la podo ankaŭ estas ekstera ento (ligita al la veth) laŭ iptables-pretigo. Ni resumu:
- Plusendita trafiko (nat, envojigita aŭ al/de pod) pasas tra la ĉenoj PREIROUTING - FORWARD - POSTROUTING.
- Trafiko al la loka gastiga procezo pasas tra la PREROUTING - INPUT-ĉeno.
- Trafiko de la loka gastiga procezo iras tra la OUTPUT - POSTROUTING-ĉeno.
Calico provizas politikajn elektojn, kiuj permesas vin apliki politikojn tra ĉiuj ĉenoj. Konsiderante tion, ni rigardu la malsamajn politikajn agordajn opciojn disponeblajn en Calico. La nombroj en la listo de elektoj sube respondas al la nombroj en la supra diagramo.
- Politiko pri laborŝarĝa finpunkto (pod).
- Politiko pri gastigaj finpunktoj
- Opcio ApplyOnForward
- Politiko de PreDNAT
- Nespurita Politiko
Ni komencu rigardante kiel politikoj estas aplikataj al laborŝarĝaj finpunktoj (Kubernetes pods aŭ OpenStack VMs), kaj poste rigardu la politikajn elektojn por gastigaj finpunktoj.
Laborŝarĝaj Finpunktoj
Politiko pri Finpunkto de Laborŝarĝo (1)
Ĉi tio estas eblo por protekti viajn kubernetes-podojn. Calico subtenas labori kun Kubernetes NetworkPolicy, sed ĝi ankaŭ disponigas kromajn politikojn - Calico NetworkPolicy kaj GlobalNetworkPolicy. Calico kreas ĉenon por ĉiu pod (laborŝarĝo) kaj hokoj en la INPUT kaj OUTPUT ĉenoj por la laborkvanto al la filtrila tablo de la FORWARD ĉeno.
Gastigaj Finpunktoj
Politiko pri Gastiganta Finpunkto (2)
Krom CNI (ujo retinterfaco), Calico-politikoj disponigas la kapablon protekti la gastiganton mem. En Calico, vi povas krei gastigan finpunkton specifante kombinaĵon de la gastiga interfaco kaj, se necese, havennumeroj. Politikdevigo por tiu unuo estas atingita uzante filtriltabelon en la INPUT kaj OUTPUT ĉenoj. Kiel vi povas vidi de la diagramo, (2) ili validas por lokaj procezoj sur la nodo/gastiganto. Tio estas, se vi kreas politikon, kiu validas por la gastiga finpunkto, ĝi ne influos trafikon irantan al/de viaj podoj. Sed ĝi provizas ununuran interfacon/sintakso por bloki trafikon por via gastiganto kaj podoj uzante Calico-politikojn. Ĉi tio multe simpligas la procezon de administrado de politikoj por heterogena reto. Agordo de gastigaj finpunktopolitikoj por plibonigi aretsekurecon estas alia grava uzkazo.
Politiko ApplyOnForward (3)
La opcio ApplyOnForward estas disponebla en la tutmonda retopolitiko de Calico por permesi politikojn esti aplikitaj al ĉiu trafiko trapasanta la gastigan finpunkton, inkluzive de trafiko, kiu estos plusendita de la gastiganto. Ĉi tio inkluzivas trafikon plusendita al la loka pod aŭ aliloke en la reto. Calico postulas, ke ĉi tiu agordo estu ebligita por politikoj uzantaj PreDNAT kaj nespuritaj, vidu la sekvajn sekciojn. Krome, ApplyOnForward povas esti uzata por monitori gastigan trafikon en kazoj kie virtuala enkursigilo aŭ programaro NAT estas uzata.
Notu, ke se vi bezonas apliki la saman retan politikon al ambaŭ gastigaj procezoj kaj podoj, tiam vi ne bezonas uzi la opcion ApplyOnForward. Ĉio, kion vi devas fari, estas krei etikedon por la bezonata gastigpunkto kaj laborŝarĝa finpunkto (pod). Calico estas sufiĉe inteligenta por devigi politikon bazitan sur etikedoj, sendepende de la finpunktotipo (gastiganto aŭ laborkvanto).
PreDNAT-politiko (4)
En Kubernetes, servaj entaj havenoj povas esti elmontritaj ekstere uzante la opcion NodePorts aŭ, laŭvole (dum uzado de Calico), reklamante ilin per la opcioj de Cluster IPs aŭ Eksteraj IPs. Kube-proxy balancas alvenantan trafikon ligitan al servo al la podoj de la responda servo uzante DNAT. Konsiderante ĉi tion, kiel vi plenumas politikojn por trafiko venanta tra NodePorts? Por certigi, ke ĉi tiuj politikoj estas aplikataj antaŭ ol la trafiko estas procesita de DNAT (kiu estas mapado inter gastiganto:haveno kaj responda servo), Calico disponigas parametron por globalNetworkPolicy nomita "preDNAT: true".
Kiam antaŭ-DNAT estas ebligita, ĉi tiuj politikoj estas efektivigitaj en (4) en la diagramo - en la mangle-tabelo de la PREROUTING-ĉeno - tuj antaŭ DNAT. La kutima ordo de politikoj ne estas sekvata ĉi tie, ĉar la aplikado de ĉi tiuj politikoj okazas multe pli frue en la trafika prilaborado. Tamen, preDNAT-politikoj respektas la ordon de apliko inter si.
Kiam vi kreas politikojn kun antaŭ-DNAT, gravas atenti pri la trafiko, kiun vi volas prilabori, kaj permesi al la plimulto esti malakceptita. Trafiko markita kiel "permeso" en la antaŭ-DNAT-politiko ne plu estos kontrolita de la hostendpoint-politiko, dum trafiko kiu malsukcesas la antaŭ-DNAT-politiko daŭros tra la ceteraj ĉenoj.
Calico faris devigan ebligi la opcion applyOnForward kiam vi uzas preDNAT, ĉar laŭdifine la celloko de la trafiko ankoraŭ ne estas elektita. Trafiko povas esti direktita al la gastiga procezo, aŭ ĝi povas esti plusendita al balgo aŭ alia nodo.
Nespurita Politiko (5)
Retoj kaj aplikoj povas havi grandajn diferencojn en konduto. En iuj ekstremaj kazoj, aplikoj povas generi multajn mallongdaŭrajn ligojn. Ĉi tio povas kaŭzi ke conntrack (kernkomponento de la Linukso retstako) elĉerpi memoron. Tradicie, por ruli ĉi tiujn specojn de aplikaĵoj en Linukso, vi devus mane agordi aŭ malŝalti conntrack, aŭ skribi iptables-regulojn por preteriri conntrack. Nespurita politiko en Calico estas pli simpla kaj pli efika opcio se vi volas prilabori konektojn kiel eble plej rapide. Ekzemple, se vi uzas masivan aŭ kiel kroma mezuro de protekto kontraŭ .
Legu ĉi tion (aŭ ) por pliaj informoj, inkluzive de agado-testoj uzante nespuritan politikon.
Kiam vi agordas la opcion "doNotTrack: true" en Calico globalNetworkPolicy, ĝi fariĝas **nespurita** politiko kaj estas aplikata tre frue en la Linukso-pakaĵa prilaborado. Rigardante la supran diagramon, nespuritaj politikoj estas aplikataj en la ĉenoj PREROUTING kaj OUTPUT en la kruda tabelo antaŭ ol konektspurado (conntrack) estas komencita. Kiam pakaĵeto estas permesita de la nespurita politiko, ĝi estas markita por malŝalti konektan spuradon por tiu pako. Ĝi signifas:
- La nespurita politiko estas aplikata po-paka bazo. Ne ekzistas koncepto de ligo (aŭ fluo). Manko de ligoj havas plurajn gravajn sekvojn:
- Se vi volas permesi kaj petan kaj respondan trafikon, vi bezonas regulon por ambaŭ enirantaj kaj elirantaj (ĉar Calico kutime uzas conntrack por marki respondtrafikon kiel permesite).
- La nespurita politiko ne funkcias por Kubernetes laborkvantoj (pods), ĉar ĉi-kaze estas neniu maniero spuri la elirantan konekton de la pod.
- NAT ne funkcias ĝuste kun nespuritaj pakaĵoj (ĉar la kerno stokas la NAT-mapadon en conntrack).
- Kiam vi trapasas la "permesi ĉiujn" regulon en la nespurita politiko, ĉiuj pakaĵoj estos markitaj kiel nespuritaj. Ĉi tio preskaŭ ĉiam ne estas tio, kion vi volas, do gravas esti tre elektema pri la pakaĵoj permesitaj de nespuritaj politikoj (kaj permesi al la plej granda parto de trafiko trairi normalajn spuritajn politikojn).
- Nespuritaj politikoj estas aplikataj ĉe la komenco mem de la pakaĵpretigdukto. Ĉi tio estas tre grave kompreni dum kreado de Calico-politikoj. Vi povas havi podpolitikon kun ordo:1 kaj nespurita politiko kun ordo:1000. Ne gravas. La Nespurita politiko estos aplikata antaŭ la politiko por la pod. Nespuritaj politikoj respektas ekzekutordonon nur inter si.
Ĉar unu el la celoj de la doNotTrack-politiko estas devigi la politikon tre frue en la Linukso-pakaĵ-pretiga dukto, Calico devigas specifi la opcion applyOnForward kiam vi uzas doNotTrack. Rilatante al la pakaĵa prilaborado-diagramo, notu, ke la nespurita(5) politiko estas aplikata antaŭ iuj vojaj decidoj. Trafiko povas esti direktita al la gastiga procezo, aŭ ĝi povas esti plusendita al balgo aŭ alia nodo.
Rezultoj
Ni rigardis la diversajn politikajn elektojn (Gastiganto-finpunkto, ApplyOnForward, preDNAT kaj Untracked) en Calico kaj kiel ili estas aplikataj laŭ la paka pretiga vojo. Kompreni kiel ili funkcias helpas evoluigi efikajn kaj sekurajn politikojn. Kun Calico vi povas uzi tutmondan retan politikon, kiu validas por etikedo (grupo de nodoj kaj podoj) kaj apliki politikojn kun diversaj parametroj. Ĉi tio permesas al profesiuloj pri sekureco kaj reto-dezajno oportune protekti "ĉion" (finpunktotipoj) samtempe uzante ununuran politikan lingvon kun Calico-politikoj.
Agnosko: Mi ŝatus danki и pro ilia recenzo kaj valoraj informoj.
fonto: www.habr.com