ShĂ«n. pĂ«rk.: Autori i artikullit â Reuven Harrison â ka mĂ« shumĂ« se 20 vjet pĂ«rvojĂ« nĂ« zhvillimin e softuerit dhe aktualisht Ă«shtĂ« drejtori teknik dhe bashkĂ«themelues i kompanisĂ« Tufin, e cila krijon zgjidhje pĂ«r menaxhimin e politikave tĂ« sigurisĂ«. Duke e parĂ« politikĂ«n rrjetore tĂ« Kubernetes si njĂ« mjet mjaft tĂ« fuqishĂ«m pĂ«r segmentimin e rrjetit brenda njĂ« klasteri, ai gjithashtu beson se ato nuk janĂ« aq tĂ« lehta pĂ«r t'u zbatuar nĂ« praktikĂ«. Ky material (mjaft i gjerĂ«) ka pĂ«r qĂ«llim tĂ« rrisĂ« ndĂ«rgjegjĂ«simin e profesionistĂ«ve mbi kĂ«tĂ« çështje dhe tĂ« ndihmojĂ« ata nĂ« krijimin e konfigurimeve tĂ« nevojshme.
Sot, shumë kompani po e zgjedhin gjithnjë e më shpesh Kubernetes për të ekzekutuar aplikacionet e tyre. Interesi për këtë software është aq i lartë, sa disa e quajnë Kubernetes "sistemi i ri operativ për qendrat e të dhënave". Me kalimin e kohës, Kubernetes (ose k8s) fillon të perceptohet si një pjesë thelbësore e biznesit që kërkon organizimin e proceseve të zhvilluara të biznesit, duke përfshirë sigurimin e sigurisë rrjetore.
Për profesionistët e sigurisë që janë të shqetësuar nga puna me Kubernetes, politika e këtij platforme për parazgjedhje mund të jetë një zgjidhje e vërtetë: të lejohet çdo gjë.
Ky udhëzues do të ndihmojë në kuptimin e brendësisë së politikave rrjetore; do të shpjegojë se si dallohen ato nga rregullat për firewalle të zakonshme. Gjithashtu, do të përmenden disa pengesa dhe do të jepen rekomandime që ndihmojnë në mbrojtjen e aplikacioneve në Kubernetes.
Politikat rrjetore të Kubernetes
Mekanizmi i politikave rrjetore të Kubernetes lejon menaxhimin e ndërveprimeve të aplikacioneve të vendosura në platformë në nivelin rrjetor (nivi i tretë në modelin OSI). Politikat rrjetore nuk kanë disa karakteristika të avancuara të firewalleve moderne, si kontrolli në nivelin 7 të OSI dhe zbulesa e kërcënimeve, megjithatë ato ofrojnë një nivel të bazës së sigurisë rrjetore, që shërben si një pikë e mirë nisjeje.
Politikat rrjetore kontrollojnë komunikimet midis pod'ave
Ngarkesat në Kubernetes shpërndahen në pod-e, të cilat përbëhen nga një ose më shumë kontejnerë të vendosur së bashku. Kubernetes i jep secilit pod një adresë IP, e cila është e disponueshme nga pod-të e tjera. Politikat rrjetore të Kubernetes përcaktojnë të drejtat e aksesit për grupe pod-esh në të njëjtën mënyrë si grupet e sigurisë në re përdoren për të menaxhuar aksesin në instancat e makinave virtuale.
Definimi i politikave rrjetore
Si dhe burimet e tjera të Kubernetes, politikave rrjetore u janë caktuar në gjuhën YAML. Në shembullin më poshtë, aplikacioni balance i jepet akses në postgres:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.postgres
namespace: default
spec:
podSelector:
matchLabels:
app: postgres
ingress:
- from:
- podSelector:
matchLabels:
app: balance
policyTypes:
- Ingress 
(Shën. përk.: ky ekran i kapur, ashtu si të gjithë imazhet e ngjashme që do të pasojnë, është krijuar jo me mjetet native të Kubernetes, por me ndihmën e mjetit Tufin Orca, i cili është zhvilluar nga kompania e autorit të artikullit origjinal dhe përmendet në fund të materialit.
Për të përcaktuar politikën tuaj të rrjetit, do të nevojiten njohuri bazike të YAML. Ky gjuhë është e bazuar në hapësira (të përcaktuara me hapësira, jo me tab). Një element me hapësirë i përket elementit më të afërt me hapësirë në të sipërme. Një element i ri i listës fillon me një defis, të gjithë elementët e tjerë kanë formën çelës-vlerë.
Pasi të keni përshkruar politikën në YAML, përdorni , për ta krijuar atë në klasterin:
kubectl create -f policy.yamlSpecifikimi i politikës së rrjetit
Specifikimi i politikës së rrjetit Kubernetes përfshin katër elemente:
-
podSelector: pĂ«rcakton podâĂ«t e prekur nga kjo politikĂ« (objektet) - obligatorike; -
policyTypes: tregon se cilat lloje politikash janë të përfshira në këtë: ingress dhe/apo egress - opcionale, megjithatë rekomandoj ta shkruani qartë në të gjitha rastet; -
ingress: pĂ«rcakton trafikun e lejuar tĂ« ardhshĂ«m nĂ« podâĂ«t e synuara - opcionale; -
egress: pĂ«rcakton trafikun e lejuar trafiku i daljes nga podâĂ«t e synuara - opcionale.
Një shembull, e marrë nga faqja Kubernetes (unë e zëvendësova role në app), tregon se si përdoren të katër elementët:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector: # <<<<
matchLabels:
app: db
policyTypes: # <<<<
- Ingress
- Egress
ingress: # <<<<
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress: # <<<<
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978 
Kiniçon përshtatni se të katër elementët janë të panevojshme. Të detyrueshëm është vetëm podSelector, parametrat tjerë mund të përdoren sipas dëshirës.
Nëse lihet jashtë policyTypes, politika do të interpretohet si më poshtë:
- Default, supozohet se ajo definon anën e ingress. Nëse në politikë nuk ka udhëzime të qarta për këtë, sistemi do ta konsiderojë se të gjithë trafiku është i ndaluar.
- Sjellja në anën e egress do të përcaktohet nga pranimi ose mungesa e parametrave përkatës të egress.
Për të shmangur gabimet, rekomandoj të citohet gjithmonë qartë policyTypes.
Sipas logjikës së mësipërme, në rast se parametrat ingress dhe/ose egress janë lënë jashtë, politika do të ndalojë të gjithë trafikun (shih "Rregulli i pastrimit" më poshtë).
Politika e parazgjedhur - lejo
NĂ«se politikat nuk janĂ« tĂ« pĂ«rcaktuara, Kubernetes lejon pĂ«r nga default çdo trafik. TĂ« gjitha podâĂ«t mund tĂ« komunikojnĂ« lirisht mes tyre. Nga njĂ« kĂ«ndvĂ«shtrim sigurie, kjo mund tĂ« duket irracionale, por mbani nĂ« mend se Kubernetes Ă«shtĂ« krijuar fillimisht nga zhvilluesit pĂ«r tĂ« siguruar ndĂ«rveprimin e aplikacioneve. Politikat e rrjetit janĂ« shtuar mĂ« vonĂ«.
Hapësirat emërore
Hapësirat emërore (Namespaces) janë mekanizmi i bashkëpunimit në Kubernetes. Ato janë të destinuara për të izoluara ambientet logjike nga njëra-tjetra, ndërkohë që ndarja e të dhënave mes hapësirave nga default lejohet.
Si shumica e komponenteve të Kubernetes, politikat e rrjetit jetojnë në një hapësirë të caktuar emërore. Në bllokun metadata mund të shkruhet se kujt hapësire i përket politika:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: my-namespace # <<<
spec:
... Nëse hapësira emërore në metadata nuk është shprehur qartë, sistemi do të përdorë hapësirën emërore të caktuar në kubectl (nga default namespace=default):
kubectl apply -n my-namespace -f namespace.yamlUnë rekomandoj të specifikohet qartë hapësira emërore, përveç nëse po shkruani një politikë që është e destinuar për disa hapësira emri njëherësh.
Themelor element podSelector nĂ« politikĂ« do tĂ« zgjedhĂ« podâĂ« nga hapĂ«sira emri tĂ« cilĂ«s i pĂ«rket politika (ai nuk ka akses nĂ« podâĂ«t nga hapĂ«sira tjetĂ«r emri).
Po ashtu podSelectorâĂ«t nĂ« blloqet ingress dhe egress mund tĂ« zgjedhin podâĂ« vetĂ«m nga hapĂ«sira e tyre emri, pĂ«rveç nĂ«se nuk i bashkoni ato me namespaceSelector (pĂ«r kĂ«tĂ« do tĂ« flitet nĂ« seksionin 'Filtrimi sipas hapĂ«sirave emri dhe podâĂ«ve').
Rregullat e emërtesës së politikave
Emrat e politikave janë unikë brenda një hapësire emri. Dy politika me të njëjtën emër në një hapësirë nuk mund të ekzistojnë, por mund të ketë politika me emra të njëjtë në hapësira të ndryshme. Kjo është e dobishme kur dëshironi të përsërisni të njëjtën politikë në disa hapësira.
MĂ« pĂ«lqeu veçanĂ«risht njĂ« nga metodat e emĂ«rtesĂ«s. Kjo pĂ«rfshin kombinimin e emrit tĂ« hapĂ«sirĂ«s emri me podâĂ«t target.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.postgres # <<<<
namespace: default
spec:
podSelector:
matchLabels:
app: postgres
ingress:
- from:
- podSelector:
matchLabels:
app: admin
policyTypes:
- Ingress 
Etiketat
Etiketat mund tĂ« bashkĂ«ngjiten objekteve Kubernetes si pod-Ă«t dhe hapĂ«sirat emĂ«rore. Etiketat (etiketat â shenjat) janĂ« ekuivalenti i etiketave nĂ« re. Politikat e rrjetit tĂ« Kubernetes pĂ«rdorin etiketat pĂ«r tĂ« pĂ«rzgjedhur pod'Ă«t, tĂ« cilave ata iu referohen:
podSelector:
matchLabels:
role: db⊠ose hapësirat emërore, të cilave ata iu referohen. Në këtë shembull, përzgjidhen të gjitha pod-ët në hapësirat emërore me etiketat përkatëse:
namespaceSelector:
matchLabels:
project: myproject Një këshillë: gjatë përdorimit namespaceSelector sigurohuni që hapësirat emërore të përzgjedhura përmbajnë etiketën e duhur. Mbani mend se hapësirat emërore të integruara si default dhe kubectl -n kube-system edit cm kubelet-config-1.16, në mënyrë të paracaktuar, nuk përmbajnë etiketa.
Për të shtuar një etiketë në hapësirën emërore, mund ta bëni si më poshtë:
kubectl label namespace default namespace=default Në këtë rast, hapësira në seksionin metadata duhet të referohet në emrin aktual të hapësirës, jo në etiketë:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default # <<<<
spec:
...Burimi dhe adresati
Politikat pĂ«r firewalls pĂ«rbĂ«hen nga rregulla me burime dhe adresat. Politikat rrjetore Kubernetes pĂ«rcaktohen pĂ«r njĂ« qĂ«llim - njĂ« grup tĂ« podâave, tĂ« cilĂ«ve iu aplikohen, dhe pastaj vendosin rregulla pĂ«r trafikun e ardhshĂ«m (ingress) dhe/ose tĂ« dalshĂ«m (egress). NĂ« shembullin tonĂ«, qĂ«llimi i politikĂ«s do tĂ« jetĂ« tĂ« gjitha podâĂ«t nĂ« hapĂ«sirĂ«n emĂ«rore default me etiketĂ« me çelĂ«sin app dhe vlerĂ«n db:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
app: db # <<<
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978 
NĂ«nseksioni ingress nĂ« kĂ«tĂ« politikĂ« hap trafikun e ardhshĂ«m nĂ« podâĂ«t e synuar. Me fjalĂ« tĂ« tjera, ingress vepron si burim, ndĂ«rsa qĂ«llimi Ă«shtĂ« adresati pĂ«rkatĂ«s. Po ashtu, egress Ă«shtĂ« adresati, dhe qĂ«llimi Ă«shtĂ« burimi i tij.
Kjo Ă«shtĂ« ekuivalente me dy rregulla pĂ«r firewalls: Ingress â QĂ«llim; QĂ«llim â Egress.
Egress dhe DNS (është e rëndësishme!)
Duke kufizuar trafikun e dalshĂ«m, kushtojini vĂ«mendje tĂ« veçantĂ« DNS â Kubernetes e pĂ«rdor kĂ«tĂ« shĂ«rbim pĂ«r tĂ« lidhur shĂ«rbimet me adresat IP. PĂ«r shembull, politika e mĂ«poshtme nuk do tĂ« funksionojĂ«, pasi nuk e lejoni aplikacionin balance tĂ« aksesojĂ« DNS:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.balance
namespace: default
spec:
podSelector:
matchLabels:
app: balance
egress:
- to:
- podSelector:
matchLabels:
app: postgres
policyTypes:
- Egress 
Mund ta rregulloni këtë duke hapur aksesin në shërbimin DNS:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.balance
namespace: default
spec:
podSelector:
matchLabels:
app: balance
egress:
- to:
- podSelector:
matchLabels:
app: postgres
- to: # <<<<
ports: # <<<<
- protocol: UDP # <<<<
port: 53 # <<<<
policyTypes:
- Egress 
Elementi i fundit to â bosh, dhe prandaj ai pĂ«rzgjedh nĂ« mĂ«nyrĂ« indirecte tĂ« gjitha podâĂ«t nĂ« tĂ« gjitha hapĂ«sirat e emrave, duke lejuar balance dĂ«rgimin e kĂ«rkesave DNS nĂ« shĂ«rbimin pĂ«rkatĂ«s tĂ« Kubernetes (zakonisht ai funksionon nĂ« hapĂ«sirĂ«n kubectl -n kube-system edit cm kubelet-config-1.16).
Ky qasje funksionon, megjithatë është shumë lehtësues dhe i pasigurt, pasi lejon dërgimin e kërkesave DNS jashtë klasterit.
Mund ta përmirësoni këtë me tri hapa të radhitur.
1. Lejoni kërkesat DNS vetëm brenda për klasterin, duke shtuar namespaceSelector:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.balance
namespace: default
spec:
podSelector:
matchLabels:
app: balance
egress:
- to:
- podSelector:
matchLabels:
app: postgres
- to:
- namespaceSelector: {} # <<<
ports:
- protocol: UDP
port: 53
policyTypes:
- Egress 
2. Lejoni DNS-requests vetëm në hapësirën e emrave kubectl -n kube-system edit cm kubelet-config-1.16.
PĂ«r kĂ«tĂ« duhet tĂ« shtoni njĂ« etiketĂ« nĂ« hapĂ«sirĂ«n e emrave kubectl -n kube-system edit cm kubelet-config-1.16: kubectl label namespace kube-system namespace=kube-system â dhe ta pĂ«rfshini nĂ« politikĂ«n me namespaceSelector:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.balance
namespace: default
spec:
podSelector:
matchLabels:
app: balance
egress:
- to:
- podSelector:
matchLabels:
app: postgres
- to:
- namespaceSelector: # <<<
matchLabels: # <<<
namespace: kube-system # <<<
ports:
- protocol: UDP
port: 53
policyTypes:
- Egress 
3. ParanoikĂ«t mund tĂ« shkojnĂ« edhe mĂ« tej dhe tĂ« kufizojnĂ« DNS-requests pĂ«r njĂ« shĂ«rbim tĂ« caktuar DNS nĂ« kubectl -n kube-system edit cm kubelet-config-1.16. NĂ« seksionin "Filtro sipas hapĂ«sirave tĂ« emrave dhe podâave" do tĂ« flitet pĂ«r mĂ«nyrĂ«n se si mund tĂ« arrini kĂ«tĂ«.
Një alternativë tjetër është të lejoni DNS në nivelin e hapësirës së emrave. Në këtë rast, nuk do të nevojitet që ta hapni për çdo shërbim:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.dns
namespace: default
spec:
podSelector: {} # <<<
egress:
- to:
- namespaceSelector: {}
ports:
- protocol: UDP
port: 53
policyTypes:
- Egress Bosht podSelector zgjedh tĂ« gjithĂ« podâĂ«t nĂ« hapĂ«sirĂ«n e emrave.
Përputhja e parë dhe rendi i rregullave
Në bllokadat e zakonshme, veprimi («Lejo» ose «Ndalo») në lidhje me paketën përcaktohet nga rregulli i parë që plotësohet. Në Kubernetes, rendi i politikave nuk ka rëndësi.
NĂ« mĂ«nyrĂ« default, kur politikatat nuk janĂ« pĂ«rcaktuar, komunikimet midis podâĂ«ve janĂ« tĂ« lejuara dhe ata mund tĂ« shkĂ«mbejnĂ« informacion nĂ« mĂ«nyrĂ« tĂ« lirĂ«. Sa herĂ« qĂ« filloni tĂ« formuloni politika, çdo pod qĂ« preket nga sĂ« paku njĂ«ra prej tyre bĂ«het i izoluar nĂ« pĂ«rputhje me disjunksionin (logjik O) tĂ« tĂ« gjitha politikave qĂ« e pĂ«rfshijnĂ«. PodâĂ«t, qĂ« nuk shqetĂ«sohen nga ndonjĂ« politikĂ«, mbeten tĂ« hapur.
I njëjti sjellje mund të ndryshohet duke përdorur një rregull pastrimi.
Rregulli i pastrimit («Ndalo»)
Politikat e bllokadave zakonisht ndalojnë çdo trafiku që nuk është lejuar në mënyrë të qartë.
NĂ« Kubernetes nuk ka veprimi «ndalo» (deny), megjithatĂ«, njĂ« efekt tĂ« ngjashĂ«m mund tĂ« arrijmĂ« me njĂ« politikĂ« tĂ« zakonshme (lejuese), duke zgjedhur njĂ« grup tĂ« zbrazĂ«t podâĂ«sh-burimi (ingress):
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: default
spec:
podSelector: {}
policyTypes:
- Ingress 
Kjo politikĂ« zgjedh tĂ« gjithĂ« podâĂ«t nĂ« hapĂ«sirĂ«n e emrit dhe lĂ« ingress-in tĂ« pĂ«rcaktuar, duke ndaluar tĂ« gjithĂ« trafikun e hyrĂ«s.
Në mënyrë të ngjashme, mund të kufizoni të gjithë trafikun e dalës nga hapësira e emrit:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-egress
namespace: default
spec:
podSelector: {}
policyTypes:
- Egress 
Mbani parasysh se politikat e tjera tĂ« saja qĂ« lejojnĂ« trafikun nĂ« podâĂ«t e hapĂ«sirĂ«s sĂ« emrit do tĂ« kenĂ« prioritet mbi kĂ«tĂ« rregull (ngjashĂ«m me shtimin e njĂ« rregulli lehtĂ«sues para njĂ« rregulli ndaluese nĂ« konfigurimin e firewall-it).
Lejo të gjitha (Any-Any-Any-Allow)
Për të krijuar politikën "Lejo të gjitha", duhet të plotësoni politikën ndaluese të mësipërme me një element të zbrazët ingress:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all
namespace: default
spec:
podSelector: {}
ingress: # <<<
- {} # <<<
policyTypes:
- Ingress 
Ajo hap aksesin nga tĂ« gjithĂ« podâĂ«t nĂ« tĂ« gjitha hapĂ«sirat e emrit (dhe tĂ« gjitha IP) nĂ« çdo pod nĂ« hapĂ«sirĂ«n e emrit default. NjĂ« sjellje e tillĂ« Ă«shtĂ« e aktivizuar nga default, prandaj zakonisht nuk ka nevojĂ« tĂ« pĂ«rcaktohet mĂ« tej. MegjithatĂ«, ndonjĂ«herĂ« mund tĂ« jetĂ« e nevojshme tĂ« çaktivizoni pĂ«rkohĂ«sisht disa leje specifike pĂ«r tĂ« diagnostikuar njĂ« problem.
Rregulli mund tĂ« ngushtohet dhe tĂ« lejojĂ« akses vetĂ«m nĂ« njĂ« grup tĂ« caktuar podâash (app:balance) nĂ« hapĂ«sirĂ«n e emrave default:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-to-balance
namespace: default
spec:
podSelector:
matchLabels:
app: balance
ingress:
- {}
policyTypes:
- Ingress 
Politika e mëposhtme lejon të gjithë trafikun e ardhshëm (ingress) dhe dalës (egress), duke përfshirë aksesin në çdo IP jashtë grumbullit:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all
spec:
podSelector: {}
ingress:
- {}
egress:
- {}
policyTypes:
- Ingress
- Egress 
Kombinimi i disa politikave
Politikat kombinohen përmes logjikës OREDHE në tri nivele; lejet për çdo pod përcaktohen në përputhje me disjunktivën e të gjitha politikave që e prekin atë:
1. Në fushat from dhe to mund të përcaktohen tre lloje elementësh (të gjithë ata kombinohen përmes OREDHE):
-
namespaceSelectorâ zgjat tĂ«rĂ« hapĂ«sirĂ«n e emrave; -
podSelectorâ zgjat podâash; -
ipBlockâ zgjat nĂ«ndegĂ«n.
Në këtë rast, numri i elementëve (edhe nëse janë të njëjtë) në nënshkrime from/to nuk është i kufizuar. Të gjithë ata do të kombinohen me logjikën OREDHE.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.postgres
namespace: default
spec:
ingress:
- from:
- podSelector:
matchLabels:
app: indexer
- podSelector:
matchLabels:
app: admin
podSelector:
matchLabels:
app: postgres
policyTypes:
- Ingress 
2. Brendi i politikës ingress mund të ketë shumë elemente from (bashkohen me LOGJIKOREN O). Po ashtu, brendi egress mund të përfshijë shumë elemente to (po ashtu bashkohen me DISJUNKSHEN):
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.postgres
namespace: default
spec:
ingress:
- from:
- podSelector:
matchLabels:
app: indexer
- from:
- podSelector:
matchLabels:
app: admin
podSelector:
matchLabels:
app: postgres
policyTypes:
- Ingress 
3. Politikat e ndryshme gjithashtu bashkohen me LOGJIKOREN O
Por kur ato bashkohen, ka një kufizim që : Kubernetes mund të kombinojë politikat vetëm me ndryshme policyTypes (Ingress ose Egress). Politikat që përcaktojnë ingress (ose egress) do të tejkalojnë njëra-tjetrën.
Lidhja ndërmjet hapësirave të emrave
Sipas parazgjedhjes, shkëmbimi i informacionit ndërmjet hapësirave të emrave është i lejuar. Këtë mund ta ndryshoni me një politikë ndaluese që do të kufizojë trafikun dalës dhe/ose hyjës në hapësirën e emrit (shih 'Rregulli i pastrimit' më lart).
Duke bllokuar q ì ê·Œin nĂ« hapĂ«sirĂ«n e emrave (shih âRregullin e pastrimitâ mĂ« lart), mund tĂ« bĂ«ni pĂ«rjashtime nga politika ndaluese duke lejuar lidhjet nga njĂ« hapĂ«sirĂ« emrash tĂ« caktuar me namespaceSelector:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: database.postgres
namespace: database
spec:
podSelector:
matchLabels:
app: postgres
ingress:
- from:
- namespaceSelector: # <<<
matchLabels:
namespace: default
policyTypes:
- Ingress 
Si rezultat, të gjitha pod'ët në hapësirën e emrave default do të kenë akses në pod'ët postgres në hapësirën e emrave database. Por çfarë nëse dëshironi të hapni aksesin në postgres vetëm pod'ë të caktuara në hapësirën e emrave default?
Filtër sipas hapësirave të emrave dhe pod'ëve
Kubernetes version 1.11 dhe më lart lejon kombinimin e operatorëve namespaceSelector dhe podSelector me anë të logjikës AND. Kjo duket kështu:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: database.postgres
namespace: database
spec:
podSelector:
matchLabels:
app: postgres
ingress:
- from:
- namespaceSelector:
matchLabels:
namespace: default
podSelector: # <<<
matchLabels:
app: admin
policyTypes:
- Ingress 
Pse e shikon këtë si AND në vend të zakonshmës OR?
Merrni parasysh se podSelector nuk fillon me një pikë. Në YAML kjo do të thotë që podSelector dhe elementi që i paraprinig namespaceSelector i përkasin të njëjtit element të listës. Prandaj ato bashkohen me logjikën AND.
Shtimi i një hije para podSelector do të sjellë krijimin e një elementi të ri të listës, i cili do të kombinohet me atë që e parakalon namespaceSelector nëpërmjet logjikës ORE.
PĂ«r tĂ« zgjedhur podâĂ«t me njĂ« etikĂ«t e caktuar nĂ« tĂ« gjitha hapĂ«sirat e emrave, shkruani bosh namespaceSelector:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: database.postgres
namespace: database
spec:
podSelector:
matchLabels:
app: postgres
ingress:
- from:
- namespaceSelector: {}
podSelector:
matchLabels:
app: admin
policyTypes:
- Ingress 
Etiketat multiple kombinohen me AND
Rregullat për firewall me shumë objektiva (host, rrjete, grupe) kombinohen me logjikën ORE. Rregulli në vijim do të funksionojë nëse burimi i paketës përputhet me Host_1 OSE Host_2:
| Burimi | Destinacioni | Shërbimi | Veprimi |
| ----------------------------------------|
| Host_1 | Subnet_A | HTTPS | Lejo |
| Host_2 | | | |
| ----------------------------------------| Nga ana tjetĂ«r, nĂ« Kubernetes etiketat e ndryshme nĂ« podSelector ose namespaceSelector kombinohen me logjikĂ«n AND. PĂ«r shembull, rregulli nĂ« vijim do tĂ« zgjedhĂ« podâĂ«t qĂ« kanĂ« tĂ« dy etiketat role=db DHE version=v2:
podSelector:
matchLabels:
role: db
version: v2E njĂ«jta logjikĂ« zbatohet pĂ«r tĂ« gjithĂ« llojet e operatorĂ«ve: selektorĂ«t e qĂ«llimeve tĂ« politikĂ«s, selektorĂ«t e podâĂ«ve dhe selektorĂ«t e hapĂ«sirave tĂ« emrave.
Subnetet dhe IP adresat (IPBlocks)
Për segmentimin e rrjetit, firewall-et përdorin VLAN, adresat IP dhe subnetet.
Në Kubernetes, adresat IP i jepen pod-ave automatikisht dhe mund të ndryshojnë shpesh, prandaj për përzgjedhjen e pod-ave dhe hapësirave të emrave në politikat rrjetore përdoren etiketa.
Subnetet (ipBlocks) përdoren kur menaxhohen lidhjet e jashtme (North-South) për hyrje (ingress) ose dalje (egress). Për shembull, kjo politikë iu jep të gjithë pod-ave nga hapësira e emrit default qasje në shërbimin DNS të Google:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: egress-dns
namespace: default
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 8.8.8.8/32
ports:
- protocol: UDP
port: 53 
Një selektor i zbrazët pod-ash në këtë shembull do të thotë "përzgjidh të gjitha pod-at në hapësirën e emrit".
Kjo politikë hap qasje vetëm në 8.8.8.8; çdo qasje në adresat IP të tjera është e ndaluar. Pra, në thelb, keni bllokuar qasjen në shërbimin e brendshëm DNS të Kubernetes. Nëse gjithsesi dëshironi ta hapni atë, specifikoni këtë në mënyrë të qartë.
Zakonisht ipBlocks dhe podSelectors janĂ« pĂ«rjashtuese, pĂ«r shkak se adresat IP tĂ« brendshme tĂ« pod-ave nuk pĂ«rdoren nĂ« ipBlocks. Duke specifikuar adresat IP tĂ« brendshme tĂ« pod-ave, nĂ« fakt, do tĂ« lejoni lidhjet nĂ«/nga podâĂ«t me kĂ«to adresa. NĂ« praktikĂ«, nuk do tĂ« dini se cila IP adresĂ« tĂ« pĂ«rdorni, prandaj nuk Ă«shtĂ« mirĂ« t'i pĂ«rdorni pĂ«r tĂ« zgjedhur podâĂ«t.
Si njĂ« kundĂ«r-shembull, politika e mĂ«poshtme pĂ«rfshin tĂ« gjitha IP-tĂ« dhe, nĂ« kĂ«tĂ« mĂ«nyrĂ«, lejon aksesin nĂ« tĂ« gjitha podâĂ«t e tjera:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: egress-any
namespace: default
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0 
Mund tĂ« hapni aksesin vetĂ«m pĂ«r IP-tĂ« e jashtme, duke pĂ«rjashtuar adresat IP tĂ« brendshme tĂ« podâĂ«ve. PĂ«r shembull, nĂ«se subneti i podâit tuaj Ă«shtĂ« 10.16.0.0/14:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: egress-any
namespace: default
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 10.16.0.0/14 
Portat dhe protokollet
Zakonisht, podâĂ«t dĂ«gjojnĂ« njĂ« port. Kjo do tĂ« thotĂ« se mund ta lini numrin e porteve nĂ« politika pa specificuar. MegjithatĂ«, rekomandohet qĂ« politikat tĂ« jenĂ« sa mĂ« tĂ« kufizuara, prandaj nĂ« disa raste Ă«shtĂ« e mundur tĂ« specifikoni porte:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.postgres
namespace: default
spec:
ingress:
- from:
- podSelector:
matchLabels:
app: indexer
- podSelector:
matchLabels:
app: admin
ports:
- port: 443
protocol: TCP
- port: 80
protocol: TCP
podSelector:
matchLabels:
app: postgres
policyTypes:
- Ingress 
Vini rehat se selegjini portet aplikohet në të gjitha elementet në bllok to ose from, ku përmban. Nëse dëshironi të përcaktoni porte të ndryshme për grupe të ndryshme elementesh, ndanë ingress ose egress në disa nënndarje me to ose from dhe në secilën shkruani portet tuaja:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default.postgres
namespace: default
spec:
ingress:
- from:
- podSelector:
matchLabels:
app: indexer
ports:
- port: 443
protocol: TCP
- from:
- podSelector:
matchLabels:
app: admin
ports:
- port: 80
protocol: TCP
podSelector:
matchLabels:
app: postgres
policyTypes:
- Ingress 
Funksioni i porteve për herë të parë:
- Nëse e lini plotësisht jashtë përkufizimin e porteve (
portet), kjo do të thotë të gjitha protokollet dhe të gjitha portet; - Nëse e lini jashtë përkufizimin e protokollit (
protokolli), kjo do të thotë TCP; - Nëse e lini jashtë përkufizimin e portit (
port), kjo do të thotë të gjitha portet.
Praktika më e mirë: mos u mbështetni në vlerat e paracaktuar, jepni ato që ju nevojiten qartë.
Kujdes, duhet tĂ« pĂ«rdorni portat e podâave, jo tĂ« shĂ«rbimeve (mĂ« shumĂ« rreth kĂ«saj nĂ« paragrafin e ardhshĂ«m).
Politikat janĂ« tĂ« pĂ«rcaktuara pĂ«r podâava ose shĂ«rbime?
NĂ« pĂ«rgjithĂ«si, podâat nĂ« Kubernetes i qasen njĂ«ri-tjetrit pĂ«rmes shĂ«rbimit â njĂ« balancues virtual ngarkese, qĂ« redirecton trafikun nĂ« podâat qĂ« implementojnĂ« shĂ«rbimin. Mund tĂ« duket se politikat rrjetĂ«rore kontrollojnĂ« aksesin nĂ« shĂ«rbime, por nuk Ă«shtĂ« kĂ«shtu. Politikat rrjetĂ«rore Kubernetes funksionojnĂ« me portat e podâave, jo tĂ« shĂ«rbimeve.
PĂ«r shembull, nĂ«se shĂ«rbimi dĂ«gjon nĂ« portin 80, por redirecton trafikun nĂ« portin 8080 tĂ« podâave tĂ« tij, nĂ« politikĂ«n rrjetĂ«rore duhet tĂ« specifikohet pikĂ«risht 8080.
NjĂ« mekanizĂ«m tĂ« tillĂ« duhet ta pranojmĂ« si jo optimal: kur ndryshon struktura e brendshme e shĂ«rbimit (portet e tĂ« cilit dĂ«gjojnĂ« podâat), do tĂ« duhet tĂ« pĂ«rditĂ«sojmĂ« politikat rrjetĂ«rore.
NjĂ« qasje e re arkitektonike duke pĂ«rdorur Service Mesh (p.sh., shih pĂ«r Istio mĂ« poshtĂ« â shĂ«nimi i pĂ«rkthyesit.) ndihmon pĂ«r tĂ« trajtuar kĂ«tĂ« problem.
A është e nevojshme të përcaktohen si Ingress ashtu edhe Egress?
Përgjigja e shkurtër është po, për të lejuar që pod A të lidhet me pod-in B, duhet të lejohet krijimi i një lidhjeje dërguese (për këtë duhet konfigurimi i politikës egress), dhe pod-i B duhet të ketë aftësinë për të pranuar një lidhje hyrëse (për këtë, përkatësisht, është e nevojshme një politikë ingress).
Megjithatë, në praktikë, mund të mbështetet në politikën e përbashkët që lejon lidhjet në një ose të dyja drejtimet.
Nëse ndonjë pod-burimi zgjidhet nga një ose më shumë egress-politika, kufizimet e vendosura mbi të do të përcaktohen nga disjunksioni i tyre. Në këtë rast, do të jetë e nevojshme të lejohet qartë lidhja me pod-in-destinatar. Nëse pod-i nuk zgjidhet nga ndonjë politikë, trafiku i tij dërgues (egress) lejohet automatikisht.
Në mënyrë të ngjashme, fati i pod-it-destinatar, i zgjedhur nga një ose më shumë ingress-politika, do të përcaktohet nga disjunksioni i tyre. Në këtë rast, është e nevojshme të lejohet qartë që ai të marrë trafik nga pod-i-burim. Nëse pod-i nuk zgjidhet nga ndonjë politikë, gjithë trafiku hyrës (ingress) për të lejohet automatikisht.
Shih pikën "Stateful ose Stateless" më poshtë.
Logjet
Politikat rrjetore Kubernetes nuk kanë kapacitetin për të regjistruar trafikun. Kjo e bën të vështirë të përcaktohet nëse politika po funksionon siç duhet dhe e komplikon shqyrtimin në fushën e sigurisë.
Kontrolli i trafikut ndaj shërbimeve të jashtme
Politikat rrjetore Kubernetes nuk lejojnë përcaktimin e një emri të plotë domeni (DNS) në pjesët e egress. Ky fakt sjell një shqetësim të madh gjatë përpjekjes për të kufizuar trafikun ndaj destinacioneve të jashtme pa një adresë IP fikse (si aws.com).
Verifikimi i politikës
Firewalls do t'ju paralajmërojnë ose madje do të refuzojnë të pranojnë politikën e gabuar. Kubernetes gjithashtu bën disa verifikime. Kur përcaktoni një politikë rrjeti përmes kubectl, Kubernetes mund të deklarojë se ajo është e pasaktë dhe të refuzojë ta pranojë. Në raste të tjera, Kubernetes do ta pranojë politikën dhe do ta plotësojë atë me detajet e humbura. Mund të shihen me komandën:
kubernetes get networkpolicy -o yamlMbani parasysh se sistemi i verifikimit të Kubernetes nuk është i pakapshëm dhe mund të lejojë disa lloje gabimesh.
Ekzekutimi
Kubernetes nuk punon vetĂ« me realizimin e politikave rrjetore, por Ă«shtĂ« veçse njĂ« nyje API qĂ« e ngarkon punĂ«n e kontrollit tek sistemi nĂ«nkuptimor i quajtur Container Networking Interface (CNI). Caktimi i politikave nĂ« klusterin Kubernetes pa caktimin e CNI tĂ« duhur Ă«shtĂ« si tĂ« krijosh politika nĂ« serverin e menaxhimit tĂ« firewall-eve pa i instaluar ato mĂ« pas nĂ« firewall-e. Ju vetĂ« duhet tĂ« siguroheni pĂ«r praninĂ« e njĂ« CNI tĂ« pĂ«rshtatshĂ«m ose, nĂ« rastin e platformave Kubernetes tĂ« vendosura nĂ« cloud, (mund tĂ« konsultoheni me listĂ«n e ofruesve â shĂ«n. pĂ«rk.), angazhoni politika rrjetore qĂ« do tĂ« vendosnin CNI pĂ«r ju.
Kujdes, Kubernetes nuk do t'ju paralajmërojë nëse caktoni një polit të rrjetit pa CNI-në përkatëse ndihmëse.
Stateful apo Stateless?
Të gjithë CNI-të e Kubernetes që kam hasur ruajnë gjendjen (p.sh., Calico përdor Linux conntrack). Kjo lejon që pod-i të marrë përgjigje për TCP-lidhjen që ai ka iniciuar pa nevojën për ta rivendosur atë. Për këtë, nuk di për ndonjë standard Kubernetes që garanton ruajtjen e gjendjes (statefulness).
Menaxhim i avancuar i politikave të sigurisë
Ja disa mënyra për të rritur efikasitetin e zbatimit të politikave të sigurisë në Kubernetes:
- Modeli arkitektonik Service Mesh përdor kontejnerë sidecar për të ofruar telemetri të detajuar dhe kontroll mbi trafikun në nivelin e shërbimeve. Si shembull mund të përmendim .
- Disa nga ofruesit e CNI e kanë zgjeruar mjete e tyre për të shkuar përtej politikave rrjetore të Kubernetes.
- siguron transparencë dhe automatizim të politikave rrjetore të Kubernetes.
Paketa Tufin Orca menaxhon politikat rrjetore të Kubernetes (dhe shërben si burim për ekranet e përmendura më lart).
Informacione shtesë
- ;
- ;
- ;
- .
PĂ«rfundimi
Politikat e rrjetit Kubernetes ofrojnë një grup të mirë mjetesh për segmentimin e klasterëve, megjithatë ato janë intuitivisht të panjohura dhe kanë shumë nuanca. Mendoj se për shkak të kësaj kompleksiteti, politikat e shumë klasterëve ekzistues përmbajnë gabime. Zgjidhjet e mundshme për këtë problem janë automatizimi i përcaktimeve të politikave ose përdorimi i mjeteve të tjera për segmentim.
Shpresoj që ky udhëzues do të ndihmojë në sqarimin e disa pyetjeve dhe në zgjidhjen e problemeve me të cilat mund të përballeni.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «Kthehu te mikroshërbimet me Istio»: , , ;
- «Udhëzuesi ilustruar për ndërtimin e rrjetit në Kubernetes»: , ;
- «»;
- «»;
- «».
Burimi: habr.com
