Kubernetes default-deny prekine tudi DNS: izjemo dodajte pred uvedbo

Privzeta zavrnitev izhodnega prometa podom zapre tudi pot do DNS. Izjemo za dejanski razreševalnik zato pripravite pred zaporo, skupaj z dovoljenji za povezave, ki jih aplikacija potrebuje. Dokumentacija Kubernetes o NetworkPolicy izrecno opozarja, da zapora vsega izhodnega prometa blokira DNS in da pravil brez ustreznega omrežnega vtičnika ni mogoče uveljaviti.

Zaporedje najprej preizkusite v ločenem imenskem območju. Posebna previdnost velja že pri dodajanju izjeme: pravilo tipa Egress, ki dovoli samo DNS, samo po sebi omeji ves drugi izhodni promet izbranih podov. Med pripravo ozkih dovoljenj zato povezljivost ohranite z začasnim širokim dovoljenjem, nato ga odstranite po posameznih smereh in preverite rezultat.

Najprej preverite uveljavljanje pravil

Ustvarjen objekt NetworkPolicy še ne dokazuje, da vtičnik filtrira promet. V testnem imenskem območju zaženite izvorni in ciljni pod ter potrdite, da se lahko povežeta na znana vrata. Nato dodajte začasno pravilo, ki izbere samo ciljnega poda, vsebuje policyTypes: [Ingress] in nima seznama ingress. Ponovljen poskus povezave iz izvornega poda mora biti zavrnjen.

Če povezava še deluje, pred nadaljevanjem preverite podporo vtičnika in izbirnik oznak. Preizkus opravite med običajnima podoma: promet med vozliščem in podom ima posebno obravnavo, zato bi lahko dal zavajajoč rezultat. Po preizkusu začasno pravilo odstranite in preverite, ali se povezava znova vzpostavi. Tako ločite napako v pravilih od težave, ki je obstajala že pred spremembo.

Popišite poti, ki morajo ostati odprte

Za testno imensko območje določite izvorni pod, cilj, smer in vrata vsake potrebne povezave. Posebej popišite promet do DNS, klice med aplikacijskimi podi in promet iz drugih imenskih območij. Razrešitev imena storitve ter povezava do storitve sta ločena koraka: uspešna poizvedba DNS še ne odpre aplikacijskih vrat.

Pri povezavi med podoma preverite obe strani. Če pravila omejujejo izvorni in ciljni pod, morata povezavo dovoljevati izhodno pravilo izvora in vhodno pravilo cilja. Obstoječa dovoljenja se seštevajo; že prisotno pravilo, ki dopušča ves promet, lahko zato prikrije učinek načrtovane zapore. Pred posegom preglejte pravila v prizadetih imenskih območjih in shranite njihove manifeste za povrnitev.

Izjemo DNS prilagodite dejanskemu razreševalniku

V testnem podu preglejte /etc/resolv.conf, nato v kube-system preverite storitev DNS, njene končne točke in oznake ciljnih podov. V običajni postavitvi s CoreDNS lahko izjema v testnem imenskem območju z izbirnikom podSelector: {} izbere vse lokalne pode. V enem vnosu egress.to združite namespaceSelector za oznako kubernetes.io/metadata.name=kube-system in podSelector za k8s-app=kube-dns; ločena vnosa bi dovolila širši nabor ciljev.

Ciliumov primer privzete zapore ohrani promet UDP na vratih 53 do podov kube-dns v kube-system. Primer uporablja CiliumClusterwideNetworkPolicy, zato njegovih polj ni mogoče neposredno prepisati v običajni Kubernetes NetworkPolicy. Kubernetesova navodila za diagnostiko DNS prikazujejo storitev kube-dns z vrati 53 za UDP in TCP ter preverjanje oznake k8s-app=kube-dns pri podih CoreDNS.

Za opisano postavitev v izjemi dovolite UDP in TCP na vratih 53 do izbranih podov DNS. Če pod uporablja drug razreševalnik ali drugačno pot do njega, izbirnik za kube-dns ni zanesljiva izjema; cilj določite po dejanski konfiguraciji in preverite s poizvedbo iz poda. To je posebej pomembno tam, kjer se pot do naslova storitve med omrežnimi izvedbami razlikuje.

Zaporo uvajajte po smereh

Začasno široko dovoljenje je varovalka med pripravo ozkih pravil. Za izhodni promet ustvarite NetworkPolicy z istim podSelector: {}, policyTypes: [Egress] in enim praznim pravilom v seznamu egress. Takšno pravilo za izbrane pode ohrani ves izhodni promet. Zatem dodajte izjemo DNS in dovoljenja za potrebne aplikacijske cilje; samo dodajanje ozke izjeme brez širokega dovoljenja bi promet že omejilo.

Za vhodni promet lahko enako pripravite začasno pravilo s policyTypes: [Ingress] in enim praznim pravilom ingress. Dodajte ozka vhodna dovoljenja za predvidene odjemalce. Nato ustvarite privzeto zaporo: apiVersion: networking.k8s.io/v1, kind: NetworkPolicy, metadata.namespace nastavljen na testno območje, spec.podSelector: {} in policyTypes: [Ingress, Egress], brez seznamov ingress in egress. Sama zapora ob začasnih širokih dovoljenjih še ne spremeni dosegljivosti, saj se dovoljenja seštevajo.

Najprej odstranite široko vhodno dovoljenje. Potrdite, da odobren odjemalec doseže aplikacijo, neodobren pa ne. Šele nato odstranite široko izhodno dovoljenje in preverite DNS ter vsako potrebno aplikacijsko pot. Uspešno ustvarjen objekt v API še ni potrditev trenutka uveljavitve: vtičnik lahko spremembe obdela z zamikom, zato povezave preverite po obdelavi in ponovite poskuse z novimi povezavami.

Preverite rezultat in pripravite povrnitev

Iz testnega poda poizvedite po kubernetes.default in po imenu storitve, ki jo aplikacija uporablja. Nato ločeno vzpostavite povezavo do dovoljene storitve na njenih aplikacijskih vratih. Dodajte poskus do cilja brez dovoljenja: uspeh tega poskusa pomeni, da je nekje še odprta pot, čeprav DNS in aplikacija delujeta.

Če po odstranitvi širokega dovoljenja odpove DNS ali nujna aplikacijska povezava, ponovno uporabite shranjeno široko dovoljenje za prizadeto smer in po uveljavitvi preverite dosegljivost. Zgolj odstranitev objekta privzete zapore morda ne zadošča: ozka dovoljenja tipa Egress ali Ingress že sama izolirajo pode. V produkcijsko območje prenesite preverjeno zaporedje, vendar izbirnike in pot do DNS določite po tamkajšnjih podih, oznakah ter razreševalniku.

Preberite tudi:

• Docker Compose ali Kubernetes: visoka razpoložljivost ima strošek upravljanja
• Pomodoro ali časovni bloki: 25 minut lahko prekine globoko delo
• Confluence ali Slite: več nadzora pomeni tudi več administracije