Calico-verkkolaajennus tarjoaa laajan valikoiman verkkokäytäntöjä yhtenäisellä syntaksilla suojatakseen laitteisto-isäntiä, virtuaalikoneita ja podeja. Näitä käytäntöjä voidaan soveltaa nimiavaruudessa tai niitä voidaan soveltaa maailmanlaajuisiin verkkokäytäntöihin (suoraan isännässä toimivien sovellusten suojaamiseksi - isäntä voi olla palvelin tai virtuaalikone) tai (suojaamaan säiliöissä tai isännöityjen virtuaalikoneiden sovelluksia). Calico-käytäntöjen avulla voit käyttää turvatoimia paketin polun eri kohdissa käyttämällä vaihtoehtoja, kuten preDNAT, unraracked ja applyOnForward. Näiden vaihtoehtojen toiminnan ymmärtäminen voi parantaa koko järjestelmäsi turvallisuutta ja suorituskykyä. Tässä artikkelissa selitetään näiden isäntäpäätepisteisiin sovellettavien Calicon käytäntövaihtoehtojen (preDNAT, unraracked ja applyOnForward) olemus ja painotetaan sitä, mitä tapahtuu paketinkäsittelypoluilla (iptabels-ketjut).
Tässä artikkelissa oletetaan, että sinulla on perustiedot Kubernetesin ja Calicon verkkokäytännöistä. Jos ei, suosittelemme kokeilemaan и käytä Calicoa ennen tämän artikkelin lukemista. Odotamme sinulta myös perusymmärrystä työstä linuxissa.
kalikoo antaa sinun soveltaa joukon käyttöoikeussääntöjä tunnisteiden mukaan (isäntäryhmiin ja työkuormiin/podeihin). Tämä on erittäin hyödyllistä, jos käytät heterogeenisiä järjestelmiä yhdessä - virtuaalikoneita, järjestelmää suoraan laitteistossa tai kubernetes-infrastruktuuria. Lisäksi voit suojata klusterisi (solmujasi) käyttämällä joukko deklaratiivisia käytäntöjä ja soveltaa verkkokäytäntöjä saapuvaan liikenteeseen (esimerkiksi NodePorts- tai External IPs -palvelun kautta).
Perustasolla, kun Calico yhdistää podin verkkoon (katso kaavio alla), se yhdistää sen isäntään käyttämällä virtuaalista Ethernet-liitäntää (veth). Podin lähettämä liikenne tulee isännälle tästä virtuaaliliittymästä ja käsitellään samalla tavalla kuin jos se tulisi fyysisestä verkkorajapinnasta. Oletuksena Calico nimeää nämä liitännät caliXXX. Koska liikenne tulee virtuaalisen käyttöliittymän kautta, se kulkee iptablesin kautta ikään kuin pod olisi yhden hypyn päässä. Siksi, kun liikennettä tulee podiin/podista, se välitetään isännän näkökulmasta.
Calicoa käyttävässä Kubernetes-solmussa voit määrittää virtuaalisen käyttöliittymän (veth) työkuormaan seuraavasti. Alla olevassa esimerkissä voit nähdä, että veth#10 (calic1cbf1ca0f8) on yhdistetty calico-monitoring-nimiavaruuteen cnx-manager-*.
[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
...
Ottaen huomioon, että Calico luo veth-rajapinnan jokaiselle työmäärälle, miten se valvoo käytäntöjä? Tätä varten Calico luo koukkuja paketinkäsittelypolun eri ketjuihin iptablesin avulla.
Alla oleva kaavio näyttää pakettien käsittelyyn osallistuvat ketjut iptablesissa (tai netfilter-alijärjestelmässä). Kun paketti saapuu verkkoliitännän kautta, se kulkee ensin PREROUTING-ketjun läpi. Sitten tehdään reitityspäätös, jonka perusteella paketti kulkee joko INPUT:n (ohjattu isäntäprosesseihin) tai FORWARDin (ohjattu podiin tai toiseen verkon solmuun) kautta. Paikallisesta prosessista paketti kulkee OUTPUT- ja sitten POSTROUTING-ketjun läpi ennen kuin se lähetetään kaapelia pitkin.
Huomaa, että pod on myös ulkoinen kokonaisuus (kytkettynä vethiin) iptables-käsittelyn kannalta. Tehdään yhteenveto:
- Eteenpäin suuntautuva liikenne (nat, reititetty tai koteloon/kodista) kulkee PREROUTING - FORWARD - POSTROUTING -ketjujen läpi.
- Liikenne paikalliseen isäntäprosessiin kulkee PREROUTING - INPUT -ketjun läpi.
- Paikallisen isäntäprosessin liikenne kulkee OUTPUT - POSTROUTING -ketjun läpi.
Calico tarjoaa käytäntövaihtoehtoja, joiden avulla voit soveltaa käytäntöjä kaikissa ketjuissa. Tässä mielessä tarkastellaan Calicon eri käytäntöjen määritysvaihtoehtoja. Alla olevan vaihtoehtoluettelon numerot vastaavat yllä olevan kaavion numeroita.
- Työkuorman päätepisteen (pod) käytäntö
- Isäntäpäätepistekäytäntö
- ApplyOnForward -vaihtoehto
- PreDNAT-käytäntö
- Seuraamaton käytäntö
Aloitetaan tarkastelemalla, kuinka käytäntöjä sovelletaan työkuormituspäätepisteisiin (Kubernetes-podit tai OpenStack-VM:t), ja tarkastellaan sitten isäntäpäätepisteiden käytäntövaihtoehtoja.
Työkuorman päätepisteet
Työkuorman päätepistekäytäntö (1)
Tämä on vaihtoehto kubernetes-palojen suojaamiseen. Calico tukee työskentelyä Kubernetes NetworkPolicyn kanssa, mutta se tarjoaa myös lisäkäytäntöjä - Calico NetworkPolicyn ja GlobalNetworkPolicyn. Calico luo ketjun jokaiselle pod (työkuorma) ja koukut INPUT- ja OUTPUT-ketjuissa työmäärää varten FORWARD-ketjun suodatintaulukkoon.
Isäntäpäätepisteet
Isäntäpäätepistekäytäntö (2)
CNI:n (container network interface) lisäksi Calico-käytännöt tarjoavat mahdollisuuden suojata itse isäntäkonetta. Calicossa voit luoda isäntäpäätepisteen määrittämällä isäntärajapinnan ja tarvittaessa porttinumeroiden yhdistelmän. Käytännön valvonta tälle entiteetille saavutetaan käyttämällä suodatintaulukkoa INPUT- ja OUTPUT-ketjuissa. Kuten kaaviosta näkyy, (2) ne koskevat paikallisia prosesseja solmussa/isäntässä. Eli jos luot käytännön, joka koskee isäntäpäätepistettä, se ei vaikuta koteloihisi menevään tai sieltä lähtevään liikenteeseen. Mutta se tarjoaa yhden käyttöliittymän/syntaksin isäntäsi ja podien liikenteen estämiseksi Calico-käytäntöjen avulla. Tämä yksinkertaistaa huomattavasti heterogeenisen verkon käytäntöjen hallintaa. Toinen tärkeä käyttötapa on isäntäpäätepistekäytäntöjen määrittäminen klusterin suojauksen parantamiseksi.
ApplyOnForward-käytäntö (3)
ApplyOnForward-vaihtoehto on käytettävissä Calicon globaalissa verkkokäytännössä, jotta käytäntöjä voidaan soveltaa kaikkeen isäntäpäätepisteen kautta kulkevaan liikenteeseen, mukaan lukien liikenteeseen, jonka isäntä edelleen lähettää. Tämä sisältää liikenteen, joka välitetään paikalliseen podiin tai mihin tahansa muualle verkossa. Calico edellyttää, että tämä asetus on käytössä PreDNAT:ia käyttäville ja jäljittämättömille käytännöille, katso seuraavat osiot. Lisäksi ApplyOnForwardia voidaan käyttää isäntäliikenteen seuraamiseen tapauksissa, joissa käytetään virtuaalista reititintä tai ohjelmiston NAT:ia.
Huomaa, että jos sinun on sovellettava samaa verkkokäytäntöä sekä isäntäprosesseihin että podeihin, sinun ei tarvitse käyttää ApplyOnForward-vaihtoehtoa. Sinun tarvitsee vain luoda tunniste vaaditulle isäntäpisteelle ja työkuorman päätepisteelle (pod). Calico on riittävän älykäs pakottaakseen käytäntöön nimikkeisiin perustuvan päätepisteen tyypistä (isäntäpiste tai työkuorma) riippumatta.
PreDNAT-käytäntö (4)
Kubernetesissa palvelukokonaisuuksien portit voidaan paljastaa ulkoisesti käyttämällä NodePorts-vaihtoehtoa tai valinnaisesti (käytettäessä Calicoa) mainostamalla niitä Cluster IP- tai External IPs -vaihtoehdoilla. Kube-välityspalvelin tasapainottaa palveluun sidotun saapuvan liikenteen vastaavan palvelun podeihin DNAT:n avulla. Kuinka valvot NodePortien kautta tulevan liikenteen käytäntöjä? Varmistaakseen, että näitä käytäntöjä sovelletaan ennen kuin DNAT (joka on isäntä:portin ja vastaavan palvelun välinen kartoitus) käsittelee liikennettä, Calico tarjoaa globalNetworkPolicylle parametrin nimeltä "preDNAT: true".
Kun esi-DNAT on käytössä, nämä käytännöt toteutetaan kaavion kohdassa (4) - PREROUTING-ketjun mangle-taulukossa - juuri ennen DNAT:tä. Tässä ei noudateta tavallista käytäntöjen järjestystä, koska näiden käytäntöjen soveltaminen tapahtuu paljon aikaisemmin liikenteen käsittelypolulla. PreDNAT-käytännöt kuitenkin kunnioittavat keskinäistä soveltamisjärjestystä.
Kun luot käytäntöjä pre-DNAT:lla, on tärkeää olla varovainen käsiteltävän liikenteen suhteen ja sallia enemmistön hylkäämisen. Isäntäpisteen käytäntö ei enää tarkista liikennettä, joka on merkitty sallituksi pre-DNAT-käytännössä, kun taas liikenne, joka rikkoo esi-DNAT-käytäntöä, jatkuu jäljellä olevien ketjujen läpi.
Calico on tehnyt pakolliseksi applyOnForward-vaihtoehdon sallimisen preDNAT:ia käytettäessä, koska liikenteen kohdetta ei ole määritelmän mukaan vielä valittu. Liikenne voidaan ohjata isäntäprosessiin tai se voidaan välittää podiin tai toiseen solmuun.
Seuraamaton käytäntö (5)
Verkkojen ja sovellusten käyttäytymisessä voi olla suuria eroja. Joissakin ääritapauksissa sovellukset voivat luoda monia lyhytikäisiä yhteyksiä. Tämä voi aiheuttaa conntrackin (Linux-verkkopinon ydinkomponentin) muistin loppumisen. Perinteisesti tämäntyyppisten sovellusten suorittamiseksi Linuxissa sinun on määritettävä conntrack manuaalisesti tai poistettava se käytöstä tai kirjoitettava iptables-säännöt ohittamaan conntrack. Seuraamaton käytäntö Calicossa on yksinkertaisempi ja tehokkaampi vaihtoehto, jos haluat käsitellä yhteydet mahdollisimman nopeasti. Esimerkiksi jos käytät massiivinen tai lisäsuojana .
Lue tämä (tai ) saadaksesi lisätietoja, mukaan lukien suorituskykytestit, joissa käytetään jäljittämätöntä käytäntöä.
Kun asetat "doNotTrack: true" -asetuksen Calicon globalNetworkPolicyssa, siitä tulee **untracked** -käytäntö, ja sitä sovelletaan hyvin varhaisessa vaiheessa Linux-pakettien käsittelyprosessissa. Yllä olevaa kaaviota tarkasteltaessa seuraamattomia käytäntöjä sovelletaan raakataulukon PREROUTING- ja OUTPUT-ketjuissa ennen yhteyden seurannan (conntrack) aloittamista. Kun jäljittämätön käytäntö sallii paketin, se on merkitty poistamaan yhteyden seuranta kyseiseltä paketilta. Se tarkoittaa:
- Seuraamatonta käytäntöä sovelletaan pakettikohtaisesti. Yhteyden (tai virtauksen) käsitettä ei ole olemassa. Yhteyksien puutteella on useita tärkeitä seurauksia:
- Jos haluat sallia sekä pyyntö- että vastausliikenteen, tarvitset säännön sekä saapuvalle että lähtevälle (koska Calico yleensä käyttää conntrackia merkitsemään vastausliikennettä sallituksi).
- Seuraamaton käytäntö ei toimi Kubernetes-työkuormille (podille), koska tässä tapauksessa podista lähtevää yhteyttä ei voi seurata.
- NAT ei toimi oikein jäljittämättömien pakettien kanssa (koska ydin tallentaa NAT-kuvauksen conntrackiin).
- Kun ohitetaan "salli kaikki" -säännön jäljittämättömässä käytännössä, kaikki paketit merkitään jäljittämättömiksi. Tämä ei lähes aina ole sitä, mitä haluat, joten on tärkeää olla erittäin valikoiva seuraamattomien käytäntöjen sallimien pakettien suhteen (ja sallia suurimman osan liikenteestä kulkea normaalien seurattujen käytäntöjen kautta).
- Seuraamattomia käytäntöjä sovelletaan paketinkäsittelyprosessin alussa. Tämä on erittäin tärkeää ymmärtää Calico-käytäntöjä luotaessa. Sinulla voi olla pod-käytäntö tilauksella:1 ja jäljittämätön käytäntö tilauksella:1000. Ei sillä ole väliä. Seuraamaton käytäntö otetaan käyttöön ennen podin käytäntöä. Seuraamattomat käytännöt kunnioittavat täytäntöönpanojärjestystä vain keskenään.
Koska yksi doNotTrack-käytännön tavoitteista on panna käytäntö täytäntöön hyvin varhaisessa Linux-pakettien käsittelyprosessissa, Calico tekee pakolliseksi applyOnForward-vaihtoehdon määrittämisen doNotTrackia käytettäessä. Viitaten paketinkäsittelykaavioon, huomaa, että untracked(5) -käytäntöä sovelletaan ennen reitityspäätöksiä. Liikenne voidaan ohjata isäntäprosessiin tai se voidaan välittää podiin tai toiseen solmuun.
Tulokset
Tarkastelimme eri käytäntövaihtoehtoja (isäntäpäätepiste, ApplyOnForward, preDNAT ja Untracked) Calicossa ja kuinka niitä sovelletaan paketinkäsittelypolulla. Niiden toiminnan ymmärtäminen auttaa kehittämään tehokkaita ja turvallisia politiikkoja. Calicon avulla voit käyttää maailmanlaajuista verkkokäytäntöä, joka koskee etikettiä (ryhmä solmuja ja ryhmiä), ja soveltaa käytäntöjä erilaisilla parametreilla. Tämän ansiosta tietoturva- ja verkkosuunnittelun ammattilaiset voivat kätevästi suojata "kaiken" (päätepistetyypit) kerralla käyttämällä yhtä Calicon käytäntöjen kieltä.
Kiitokset: Haluan kiittää и arvosteluista ja arvokkaasta tiedosta.
Lähde: will.com