Calico nettverksplugin gir et bredt spekter av nettverkspolicyer med en enhetlig syntaks for å beskytte maskinvareverter, virtuelle maskiner og pods. Disse policyene kan brukes innenfor et navneområde eller være globale nettverkspolicyer som gjelder for (for å beskytte applikasjoner som kjører direkte på verten - verten kan være en server eller en virtuell maskin) eller (for å beskytte applikasjoner som kjører i containere eller vertsbaserte virtuelle maskiner). Calico-policyer lar deg bruke sikkerhetstiltak på forskjellige punkter i en pakkes bane ved å bruke alternativer som preDNAT, unraracked og applicationOnForward. Å forstå hvordan disse alternativene fungerer, kan bidra til å forbedre sikkerheten og ytelsen til det totale systemet. Denne artikkelen forklarer essensen av disse Calico-policyalternativene (preDNAT, unraracked og applicationOnForward) brukt på vertsendepunkter, med vekt på hva som skjer i pakkebehandlingsbaner (iptabels-kjeder).
Denne artikkelen forutsetter at du har en grunnleggende forståelse av hvordan Kubernetes- og Calico-nettverkspolicyer fungerer. Hvis ikke, anbefaler vi å prøve det и bruke Calico før du leser denne artikkelen. Vi forventer også at du har en grunnleggende forståelse for arbeidet i linux.
Calico lar deg bruke et sett med tilgangsregler etter etiketter (på grupper av verter og arbeidsbelastninger/pods). Dette er veldig nyttig hvis du bruker heterogene systemer sammen - virtuelle maskiner, et system direkte på maskinvare eller en kubernetes-infrastruktur. I tillegg kan du beskytte klyngen (nodene) ved å bruke et sett med deklarative policyer og bruke nettverkspolicyer på innkommende trafikk (for eksempel gjennom NodePorts eller External IPs-tjenesten).
På et grunnleggende nivå, når Calico kobler en pod til nettverket (se diagrammet nedenfor), kobler den den til verten ved hjelp av et virtuelt Ethernet-grensesnitt (veth). Trafikken som sendes av poden kommer til verten fra dette virtuelle grensesnittet og behandles på samme måte som om den kom fra et fysisk nettverksgrensesnitt. Som standard navngir Calico disse grensesnittene caliXXX. Siden trafikken kommer gjennom det virtuelle grensesnittet, går den gjennom iptables som om poden var ett hopp unna. Derfor, når trafikk kommer til/fra en pod, videresendes den fra vertens synspunkt.
På en Kubernetes-node som kjører Calico, kan du tilordne et virtuelt grensesnitt (veth) til en arbeidsbelastning som følger. I eksemplet nedenfor kan du se at veth#10 (calic1cbf1ca0f8) er koblet til cnx-manager-* i calico-monitoring navneområdet.
[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
...
Gitt at Calico oppretter et veth-grensesnitt for hver arbeidsbelastning, hvordan håndhever det retningslinjer? For å gjøre dette oppretter Calico kroker i ulike kjeder av pakkebehandlingsbanen ved hjelp av iptables.
Diagrammet nedenfor viser kjedene som er involvert i pakkebehandling i iptables (eller netfilter-delsystemet). Når en pakke kommer gjennom et nettverksgrensesnitt, går den først gjennom PREROUTING-kjeden. En rutingbeslutning blir så tatt, og basert på dette går pakken gjennom enten INPUT (rettet til vertsprosesser) eller FORWARD (rettet til en pod eller en annen node på nettverket). Fra den lokale prosessen går pakken gjennom OUTPUT og deretter POSTROUTING-kjeden før den sendes ned i kabelen.
Merk at poden også er en ekstern enhet (koblet til veth) når det gjelder iptables-behandling. La oss oppsummere:
- Videresendt trafikk (nat, rutet eller til/fra en pod) passerer gjennom PREROUTING - FORWARD - POSTROUTING-kjedene.
- Trafikk til den lokale vertsprosessen går gjennom PREROUTING - INPUT-kjeden.
- Trafikk fra den lokale vertsprosessen går gjennom OUTPUT - POSTROUTING-kjeden.
Calico tilbyr policyalternativer som lar deg bruke policyer på tvers av alle kjeder. Med det i tankene, la oss se på de forskjellige policykonfigurasjonsalternativene som er tilgjengelige i Calico. Tallene i listen over alternativer nedenfor tilsvarer tallene i diagrammet ovenfor.
- Retningslinjer for arbeidsbelastningsendepunkt (pod).
- Retningslinjer for vertsendepunkt
- Alternativet ApplyOnForward
- PreDNAT-policy
- Usporet policy
La oss starte med å se på hvordan policyer brukes på arbeidsbelastningsendepunkter (Kubernetes-poder eller OpenStack VM-er), og så se på policyalternativene for vertsendepunkter.
Arbeidsbelastningsendepunkter
Arbeidsbelastning endepunktpolicy (1)
Dette er et alternativ for å beskytte kubernetes pods. Calico støtter arbeid med Kubernetes NetworkPolicy, men det gir også flere retningslinjer - Calico NetworkPolicy og GlobalNetworkPolicy. Calico oppretter en kjede for hver pod (arbeidsbelastning) og kobler inn INPUT- og OUTPUT-kjedene for arbeidsbelastningen til filtertabellen til FORWARD-kjeden.
Vertsendepunkter
Retningslinjer for vertsendepunkt (2)
I tillegg til CNI (container network interface), gir Calico-policyer muligheten til å beskytte verten selv. I Calico kan du opprette et vertsendepunkt ved å spesifisere en kombinasjon av vertsgrensesnittet og, om nødvendig, portnumre. Retningshåndhevelse for denne enheten oppnås ved å bruke en filtertabell i INPUT- og OUTPUT-kjedene. Som du kan se av diagrammet, (2) gjelder de lokale prosesser på noden/verten. Det vil si at hvis du oppretter en policy som gjelder for vertsendepunktet, vil det ikke påvirke trafikken som går til/fra podene dine. Men det gir et enkelt grensesnitt/syntaks for å blokkere trafikk for verten og podene dine ved å bruke Calico-policyer. Dette forenkler i stor grad prosessen med å administrere retningslinjer for et heterogent nettverk. Konfigurering av vertsendepunktspolicyer for å forbedre klyngesikkerheten er en annen viktig brukssak.
ApplyOnForward Policy (3)
Alternativet ApplyOnForward er tilgjengelig i Calicos globale nettverkspolicy for å tillate at policyer brukes på all trafikk som går gjennom vertens endepunkt, inkludert trafikk som videresendes av verten. Dette inkluderer trafikk videresendt til den lokale poden eller andre steder på nettverket. Calico krever at denne innstillingen er aktivert for policyer som bruker PreDNAT og usporet, se følgende avsnitt. I tillegg kan ApplyOnForward brukes til å overvåke vertstrafikk i tilfeller der en virtuell ruter eller programvare NAT brukes.
Merk at hvis du trenger å bruke samme nettverkspolicy for både vertsprosesser og pods, trenger du ikke bruke alternativet ApplyOnForward. Alt du trenger å gjøre er å lage en etikett for det nødvendige vertsendepunktet og arbeidsbelastningsendepunktet (pod). Calico er smart nok til å håndheve retningslinjer basert på etiketter, uavhengig av endepunkttype (vertsendepunkt eller arbeidsbelastning).
PreDNAT-policy (4)
I Kubernetes kan tjenesteenhetsporter eksponeres eksternt ved å bruke alternativet NodePorts eller, eventuelt (når du bruker Calico), ved å annonsere dem ved å bruke alternativene Cluster IPs eller External IPs. Kube-proxy balanserer innkommende trafikk bundet til en tjeneste til podene til den tilsvarende tjenesten ved hjelp av DNAT. Gitt dette, hvordan håndhever du retningslinjer for trafikk som kommer gjennom NodePorts? For å sikre at disse retningslinjene brukes før trafikken behandles av DNAT (som er en kartlegging mellom vert:port og tilsvarende tjeneste), gir Calico en parameter for globalNetworkPolicy kalt "preDNAT: true".
Når pre-DNAT er aktivert, implementeres disse policyene i (4) i diagrammet - i mangletabellen til PREROUTING-kjeden - rett før DNAT. Den vanlige rekkefølgen av policyer følges ikke her, siden anvendelsen av disse policyene skjer mye tidligere i trafikkbehandlingsbanen. Imidlertid respekterer preDNAT-retningslinjer rekkefølgen på søknaden seg imellom.
Når du oppretter policyer med pre-DNAT, er det viktig å være forsiktig med trafikken du ønsker å behandle og la flertallet bli avvist. Trafikk merket som 'tillat' i pre-DNAT-policyen vil ikke lenger bli sjekket av vertsendepunkt-policyen, mens trafikk som ikke oppfyller pre-DNAT-policyen vil fortsette gjennom de gjenværende kjedene.
Calico har gjort det obligatorisk å aktivere alternativet applyOnForward når du bruker preDNAT, siden destinasjonen for trafikken per definisjon ikke er valgt ennå. Trafikk kan dirigeres til vertsprosessen, eller den kan videresendes til en pod eller en annen node.
Usporede retningslinjer (5)
Nettverk og applikasjoner kan ha store forskjeller i atferd. I noen ekstreme tilfeller kan applikasjoner generere mange kortvarige tilkoblinger. Dette kan føre til at conntrack (en kjernekomponent i Linux-nettverksstakken) går tom for minne. Tradisjonelt, for å kjøre denne typen applikasjoner på Linux, må du manuelt konfigurere eller deaktivere conntrack, eller skrive iptables-regler for å omgå conntrack. Usporet policy i Calico er et enklere og mer effektivt alternativ hvis du ønsker å behandle tilkoblinger så raskt som mulig. For eksempel hvis du bruker massive eller som et ekstra beskyttelsestiltak mot .
Les dette (eller ) for mer informasjon, inkludert ytelsestester som bruker usporede retningslinjer.
Når du angir alternativet "doNotTrack: true" i Calico globalNetworkPolicy, blir det en **usporet** policy og brukes veldig tidlig i Linux-pakkebehandlingspipelinen. Ser vi på diagrammet ovenfor, brukes ikke-sporede policyer i PREROUTING- og OUTPUT-kjedene i råtabellen før tilkoblingssporing (conntrack) startes. Når en pakke tillates av den usporede policyen, er den merket for å deaktivere tilkoblingssporing for den pakken. Det betyr:
- Den usporede policyen brukes på pakkebasis. Det er ikke noe begrep om forbindelse (eller flyt). Mangel på forbindelser har flere viktige konsekvenser:
- Hvis du vil tillate både forespørsels- og responstrafikk, trenger du en regel for både inngående og utgående (siden Calico vanligvis bruker conntrack for å merke responstrafikk som tillatt).
- Den usporede policyen fungerer ikke for Kubernetes-arbeidsbelastninger (pods), fordi i dette tilfellet er det ingen måte å spore den utgående tilkoblingen fra poden.
- NAT fungerer ikke riktig med usporede pakker (siden kjernen lagrer NAT-tilordningen i conntrack).
- Når du går gjennom "tillat alle"-regelen i den usporede policyen, vil alle pakker bli merket som usporede. Dette er nesten alltid ikke det du vil ha, så det er viktig å være veldig selektiv med hensyn til pakkene som tillates av usporede retningslinjer (og la mesteparten av trafikken gå gjennom vanlige sporede retningslinjer).
- Usporede retningslinjer brukes helt i begynnelsen av pakkebehandlingspipelinen. Dette er veldig viktig å forstå når du lager Calico-policyer. Du kan ha en pod-policy med ordre:1 og en usporet policy med ordre:1000. Det spiller ingen rolle. Den usporede policyen vil bli brukt før policyen for poden. Usporede retningslinjer respekterer kun utførelsesordre seg imellom.
Fordi et av formålene med doNotTrack-policyen er å håndheve policyen veldig tidlig i Linux-pakkebehandlingspipelinen, gjør Calico det obligatorisk å spesifisere alternativet applyOnForward når du bruker doNotTrack. Med henvisning til pakkebehandlingsdiagrammet, merk at den usporede(5)-policyen brukes før eventuelle rutingbeslutninger. Trafikk kan dirigeres til vertsprosessen, eller den kan videresendes til en pod eller en annen node.
Resultater av
Vi så på de ulike policyalternativene (vertsendepunkt, ApplyOnForward, preDNAT og Untracked) i Calico og hvordan de brukes langs pakkebehandlingsbanen. Å forstå hvordan de fungerer hjelper med å utvikle effektive og sikre retningslinjer. Med Calico kan du bruke en global nettverkspolicy som gjelder for en etikett (en gruppe med noder og poder) og bruke policyer med ulike parametere. Dette gjør at fagfolk innen sikkerhet og nettverksdesign kan beskytte "alt" (endepunkttyper) på en gang ved å bruke ett enkelt policyspråk med Calico-policyer.
Anerkjennelse: Jeg vil gjerne takke и for deres vurdering og verdifull informasjon.
Kilde: www.habr.com