Izolacija Kubernetes NetworkPolicy: pred uporabo dokažite, da pravila delujejo

Uredniški termin: 17. 9. 2026. Objavljeno 19. 9. 2026 po pregledu.

Kratek odgovor: manifest NetworkPolicy ni dokaz omrežne izolacije. Preden se nanj zanesete, v ciljni gruči potrdite štiri stvari: da nameščeni omrežni vtičnik uveljavlja Kubernetes NetworkPolicy, da pravila izberejo predvidene Pode, da potrebne povezave delujejo in da so nedovoljene povezave zavrnjene. Za vsako izdajo ali pomembno spremembo politike shranite majhen nabor ponovljivih dokazil. Kubernetes izrecno navaja, da NetworkPolicy brez krmilnika, ki jo izvaja, nima učinka. Kubernetes Network Policies

To je pregled sprejemljivosti pred izdajo za izolacijo aplikacije. Ne nadomešča varnostnih skupin v oblaku, požarnih zidov vozlišč, avtorizacije storitvene mreže, identitete delovne obremenitve, avtorizacije API-jev ali utrjevanja gostiteljev. NetworkPolicy omejuje promet do Podov ali od njih na tretji oziroma četrti plasti. Obseg in vedenje sta odvisna od omrežne izvedbe, zato lahko isti YAML v gruči z drugim CNI ali dodatnimi politikami ponudnika pomeni nekaj drugega.

Uporabite pisno določen obseg in neprodukcijski imenski prostor, ki je po oznakah, načinu CNI, DNS in sprejemnih kontrolah primerljiv s produkcijo. Sintetične delovne obremenitve za odjemalca, API, podatkovno zbirko in zavrnjenega odjemalca ustvarite le z dovoljenjem lastnika gruče. Ne začnite z obsežno politiko privzete zavrnitve v skupnem produkcijskem imenskem prostoru. Blokiran DNS, telemetrija ali odvisnost preverjanja delovanja lahko preverjanje spremeni v motnjo v razpoložljivosti.

Najprej ugotovite, ali izvajanje obstaja

Določite različico gruče, CNI in njegovo različico, nastavitve CNI, način politik in morebitne izvedbeno posebne vire politik. Od lastnika platforme pridobite dokumentirano potrditev, da nameščeni omrežni vtičnik v tej gruči izvaja Kubernetes NetworkPolicy. Samo dejstvo, da Kubernetes API sprejme objekt NetworkPolicy, ni takšno potrdilo. Kubernetes zahteva omrežno rešitev s podporo za NetworkPolicy in navaja, da objekt brez izvajajočega krmilnika nima učinka. Kubernetes Network Policies

Nato popišite vse politike, ki izberejo ciljne Pode. Vključite objekte NetworkPolicy v imenskem prostoru, trenutne oznake Podov, oznake imenskih prostorov, na katere se sklicujejo selektorji, in vse politike CNI, ki lahko dodajo ali omejijo vedenje. Cilium na primer dokumentira podporo za Kubernetes NetworkPolicy in ločen vir CiliumNetworkPolicy. Kadar je ta vir v uporabi, pregled samo Kubernetes YAML-a ni popoln. Cilium Kubernetes Network Policy

Oznake obravnavajte kot varnostno pomembne nastavitve. Politika, ki izbere app: payments-api, ščiti samo Pode s to natančno oznako. Sprememba predloge uvedbe, vrednosti Helm ali selitev v drug imenski prostor lahko delovno obremenitev neopazno postavi izven selektorja. Ob vsakem preizkusu zabeležite imena izbranih Podov, oznake, imenski prostor, storitveni račun in lastnika.

Arhitekturo spremenite v matriko dovoljenj in zavrnitev

Pred preizkusom napišite pričakovane tokove. Kratka matrika ekipo prisili, da navede smer, protokol, vrata, identiteto vira, identiteto cilja in razlog za vsako povezavo. Vključite DNS, telemetrijo, odvisnosti preverjanja delovanja in zunanji izhodni promet, kadar so upravičeni. Stavek »aplikacija potrebuje omrežje« ni merilo za sprejem izdaje.

Kubernetes dohodno in izhodno izolacijo obravnava neodvisno. Pod postane izoliran v posamezni smeri šele, ko ga izbere NetworkPolicy, ki navede to smer. Pri standardnih virih Kubernetes NetworkPolicy so politike aditivne, zato je dejansko dovoljeni promet unija dovoljenj veljavnih standardnih politik. Za povezavo med Podi morata povezavo dovoliti izhodna politika vira in dohodna politika cilja; vrstni red ne določa rezultata standardnih politik. Viri politik CNI in politike na ravni gruče imajo lahko lastno dokumentirano prednost in semantiko zavrnitve, zato njihovega vedenja ne sklepajte iz tega pravila. Kubernetes Network Policies Zato lahko politika, ki je videti omejevalna, še vedno dovoljuje pot prek drugega ujemajočega se pravila.

Preverjajte v varnem zaporedju

Začnite z dokazili o objektih: dokumenti politik, relevantna konfiguracija CNI, natančni selektorji in oznake ciljnih Podov. Preden neuspeh pripišete politiki, preverite, da se storitve razrešijo v predvidene EndpointSlice oziroma Pode v ozadju. Napačno usmerjanje, nedosegljiva končna točka, napačna ciljna vrata ali napaka avtentikacije aplikacije niso dokaz, da je povezavo zavrnila NetworkPolicy.

Nato s sintetičnega izvornega Poda preverite osnovno delovanje DNS. Navodila Kubernetes za odpravljanje težav pri storitvah razlikujejo med razreševanjem imen in povezljivostjo do IP-naslova storitve ter navajajo, da klic čez imenske prostore lahko zahteva ime s prostorom ali polno kvalificirano ime storitve. Kubernetes Debug Services Če DNS ne deluje, najprej preglejte konfiguracijo razreševalnika in pot do storitve DNS; ne odprite vsega izhodnega prometa samo zato, da bi uspela poizvedba po imenu.

Vsako predvideno pot preizkusite posebej z neškodljivim, vnaprej dogovorjenim odzivom preverjanja delovanja. Zapišite identiteto izvornega Poda, ciljno storitev in dejanski Pod v ozadju, čas, protokol in vrata, različico politike ter opaženi rezultat. Nato preizkusite eno zavrnjeno pot s sintetičnim virom, ki s ciljem nima poslovne povezave. Uporaben rezultat je jasen par dovoljenje/zavrnitev za isti cilj in vrata ter dokazila o izbiri Podov, ki rezultat pojasnijo.

Zavrnitev je lahko nedoločna. Časovna prekoračitev je lahko posledica politike, nedosegljive končne točke, DNS, usmerjanja storitve, napake aplikacije ali testnega orodja. Rezultat označite kot nedoločen, dokler ločen varen pregled ne pokaže, da je cilj dosegljiv in delujoč z odobrenega vira. Prav tako en uspešen zahtevek ne dokaže pokritosti vseh replik, imenskih prostorov, protokolov ali izhodnih ciljev. Preverite dogovorjene reprezentativne poti in zapišite omejitve.

Pogoji za ustavitev in omejitve uvedbe

Takoj se ustavite, če odpove pričakovani produkcijsko kritični tok, če postane DNS ali telemetrija nedosegljiva, če preizkus izbere Pode izven obsega ali če postane dosegljiva neodobrena pot. Ustavite se tudi, če stanja CNI ni mogoče določiti, če rezultat za razlago potrebuje produkcijske podatke ali poverilnice, ali če bi politika brez odločitve lastnika potrebovala širši dostop. Ohranite najmanj potrebna dokazila, obnovite odobreno konfiguracijo in eskalirajte po postopku sprememb aplikacije in platforme.

Ne predpostavljajte, da začne politika povsod veljati v istem trenutku. Kubernetes navaja, da vtičnik za obravnavo nove NetworkPolicy lahko potrebuje čas, da Podi začasno vidijo drugačno povezljivost in da Kubernetes API ne ponuja signala za točen trenutek končane obdelave. Kubernetes Network Policies Pri samodejnih preverjanjih zato počakajte na stanje pripravljenosti, ki ga podpira ponudnik, ali na določen čas opazovanja. Po tem obdobju vsak sprejemni preizkus TCP ali UDP izvedite z novo povezavo oziroma novim tokom; za sprejemni rezultat se izognite trajnim sejam odjemalca in skupinam povezav. Kubernetes vpliv spremenjene politike na že vzpostavljene povezave opredeljuje kot odvisen od izvedbe, zato vedenje obstoječih sej ločeno zabeležite, kadar je pomembno za zasnovo. Nato zabeležite dovoljenje in zavrnitev. Prehodni rezultat ni stabilen dokaz uspeha ali napake.

Delovne obremenitve hostNetwork zahtevajo ločeno odločitev. Kubernetes njihovo vedenje pri NetworkPolicy opisuje kot nedoločeno; pogoste izvedbe njihov promet obravnavajo kot promet vozlišča. Dokumentirane so tudi izjeme za promet vozlišča. Ne predpostavljajte, da politika imenskega prostora izolira agente vozlišč, Pode z omrežjem gostitelja, poti uravnoteževalnika v oblaku ali vse odvisnosti kontrolne ravnine. Kubernetes Network Policies

Odpravite nejasnosti

Pred izboljševanjem pravil najprej odpravite manjkajoče izvajanje. Če CNI ne izvaja vedenja, ki ga zasnova potrebuje, skupaj z lastnikom platforme izberite in preverite podprto izvedbo. Nato popravite selektorje: oznake delovnih obremenitev naj bodo stabilne, oznake imenskih prostorov namenske, lastništvo politik pa jasno. Osnovno izolacijo dodajte šele po preslikavi odvisnosti DNS, preverjanja delovanja, opazljivosti, storitvene mreže in odobrenega izhodnega prometa.

Pri nepričakovano dovoljeni poti poiščite vse politike, ki izberejo izvor in cilj, nato odstranite ali zožite pravilo, ki pot dovoljuje. Pri standardnih Kubernetes NetworkPolicy dodatna omejevalna politika ne prekliče širokega dovoljenja, ker se te politike seštevajo. Pri politikah CNI ali na ravni gruče preverite dokumentirano prednost in semantiko zavrnitve izvedbe. Pri nepričakovano zavrnjeni poti ločeno preverite izhodno politiko vira in dohodno politiko cilja, vključno s protokolom, imenovanimi ali številskimi vrati, oznakami imenskih prostorov, usmerjanjem storitve in dokumentiranim vedenjem CNI. Varnost spletnih aplikacij je koristna, kadar tok izpostavlja API, vendar NetworkPolicy nikoli ne nadomesti avtentikacije API-ja in preverjanja pravic nad objekti.

Matriko vključite v postopek sprememb. Ob spremembi oznake, imenskega prostora, vrat, ponudnika DNS, različice CNI, storitvene mreže ali zunanje odvisnosti znova izvedite ustrezen par preizkusov. Shranite kratek zapis izdaje: različico politike, izbrane obremenitve, rezultate dovoljenih in zavrnjenih poti, izjeme, pregledovalca ter preostale omejitve. Pri pretvorbi matrike, izjem, odgovornosti in preostalih omejitev v zapis za odločitev o izdaji pomaga poročanje in tveganje.

Pogosta vprašanja

Ali že ustvarjena NetworkPolicy samodejno blokira promet? Ne. Potreben je omrežni vtičnik s podporo, izolacija pa je usmerjena. Podi so privzeto neizolirani za dohodni in izhodni promet, dokler izbrana politika ne navede ustrezne smeri. Kubernetes Network Policies

Zakaj je privzeta zavrnitev prekinila DNS? Pod, ki je izbran za izhodno izolacijo, lahko pošilja promet le prek dovoljenih izhodnih pravil. Če razrešuje imena storitev, v pregledano matriko vključite dejansko pot DNS in protokol, nato ju preverite ločeno od povezljivosti aplikacije. Kubernetes Debug Services

Ali zavrnjen preizkus dokazuje, da politika deluje? Samo kadar je cilj neodvisno potrjeno zdrav in je preizkus omejen na konkreten vir, cilj, vrata in protokol. Sama časovna prekoračitev je nedoločna; povežite jo z uspešnim dostopom z odobrenega vira in dokazili o izbiri Podov.