ShĂ«n. pĂ«rkth.: Autori i artikullit â Reuven Harrison â ka mĂ« shumĂ« se 20 vjet pĂ«rvojĂ« nĂ« zhvillimin e software-it dhe aktualisht Ă«shtĂ« drejtori teknik dhe bashkĂ«themelues i kompanisĂ« Tufin, e cila krijon zgjidhje pĂ«r menaxhimin e politikave tĂ« sigurisĂ«. Edhe pse i konsideron politikat e rrjetit nĂ« Kubernetes si njĂ« mjet tĂ« fuqishĂ«m pĂ«r segmentimin e rrjetit nĂ« klaster, ai mendon se ato nuk janĂ« aq tĂ« lehta nĂ« praktikĂ«. Ky material (mjaft i gjerĂ«) ka pĂ«r qĂ«llim tĂ« rrisĂ« ndĂ«rgjegjĂ«simin e profesionistĂ«ve nĂ« kĂ«tĂ« fushĂ« dhe t'i ndihmojĂ« ata nĂ« krijimin e konfigurimeve tĂ« nevojshme.
Sot shumë kompani po zgjedhin gjithnjë e më shumë Kubernetes për të lansuar aplikacionet e tyre. Interesi për këtë software është aq i lartë sa disa e quajnë Kubernetes «sistemin e ri operativ për qendrat e të dhënave». Gradualisht, Kubernetes (ose k8s) fillon të perceptohet si një pjesë kritike e biznesit që kërkon organizimin e proceseve të mira biznesore, përfshirë sigurimin e sigurisë në rrjet.
Për profesionistët e sigurisë, të cilët janë të shqetësuar nga puna me Kubernetes, një zbulim i vërtetë mund të jetë politika e kësaj platforme për default: lejo gjithçka.
Ky udhëzues do t'ju ndihmojë të kuptoni strukturën e brendshme të politikave të rrjetit; të kuptoni si dallohet ato nga rregullat për firewall-et e zakonshëm. Gjithashtu, do të flitet për disa pengesa dhe do të jepen rekomandime që do t'ju ndihmojnë të mbroni aplikacionet në Kubernetes.
Politikat e rrjetit Kubernetes
Mekanizmi i politikave të rrjetit në Kubernetes lejon menaxhimin e ndërveprimeve të aplikacioneve të vendosura në platformë në nivelin e rrjetit (niveli i tretë në modelin OSI). Politikat e rrjetit i mungojnë disa funksione të avancuara të firewall-eve moderne, si kontrolli në nivelin 7 të OSI dhe zbardhja e rrezikut, megjithatë ato ofrojnë një nivel bazik të sigurisë në rrjet, që shërben si një pikë e mirë fillestare.
Politikat e rrjetit 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 alokon çdo pod-i një adresë IP, e cila është e disponueshme nga pod-e të tjerë. Politikat rrjetore të Kubernetes përcaktojnë të drejtat e aksesit për grupe pod-esh në të njëjtën mënyrë siç përdoren grupet e sigurisë në re për menaxhimin e aksesit në instancat e makinave virtuale.
PĂ«rcaktimi i politikave rrjetore
Si të gjitha burimet e tjera të Kubernetes, politikat rrjetore përcaktohen në gjuhën YAML. Në shembullin e mëposhtëm, aplikacionit balance i hapet kyçja për 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ërkth.: ky screenshot, ashtu si të gjithë screenshot-et e ngjashme të mëvonshme, është krijuar jo me mjete të natyrshme të Kubernetes, por me ndihmën e mjetit Tufin Orca, zhvillimi i të cilit mbështetet 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'ju nevojiten njohuri bazike në YAML. Kjo gjuhë bazohet në hapësira (të përcaktuara me hapësira, jo me tabulatorë). Një element me hapësira i përket elementit më të afërt me hapësira mbi të. Një element i ri liste fillon me një defis, të gjitha elementet e tjera kanë pamjen çelës-vlerë.
Pas përshkrimit të politikës në YAML, përdorni , për ta krijuar atë në klaster:
kubectl create -f policy.yamlSpecifikimi i politikës rrjetore
Specifikimi i politikës rrjetore të Kubernetes përfshin katër elemente:
-
podSelector: përcakton pod-et që preken nga kjo politikë (qëllimet) - të detyrueshme; -
policyTypes: tregon se cilat lloje politikash janë të përfshira: ingress dhe/ose egress - e opcional, megjithatë e rekomandoj ta shkruani qartë në të gjitha rastet; -
ingress: përcakton trafikun e lejuar në pod-et e synuara - e opcional; -
egress: përcakton trafikun e lejuar trafiku nga pod-et e synuara - e opcional.
Një shembull, e marrë nga faqja e Kubernetes (unë zëvendësova role në app), tregon se si përdoren të katër elementet:
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 
Vlenni se çdo katër elementë nuk janë të detyrueshëm. E vetëmjaftueshme është podSelector, parametrat e tjerë mund të përdoren sipas dëshirës.
Nëse hiqet policyTypes, politika do të interpretohet si në vijim:
- Me default pranohet se ajo përcakton anën ingress. Nëse në politikë nuk ka udhëzime të qarta për këtë, sistemi do të mendojë se gjithë trafiku është i ndaluar.
- Sjellja në anën e egress do të përkufizohet nga prania ose mungesa e parametrave të përkatshëm të egress.
Për të shmangur gabimet, rekomandoj të specifikoni gjithmonë qartë policyTypes.
Sipas logjikës së mësipërme, në rast se parametrat ingress dhe/ose egress hiqen, politika do të ndalojë gjithë trafikun (shih "Rregulli i pastrimit" më poshtë).
Politika e paracaktuar është lejohet
NĂ«se politikat nuk janĂ« tĂ« pĂ«rcaktuara, Kubernetes automatikisht lejon tĂ« gjithĂ« trafikun. TĂ« gjitha podâĂ«t mund tĂ« shkĂ«mbejnĂ« informacion lirshĂ«m mes tyre. Nga pikĂ«pamja e sigurisĂ«, kjo mund tĂ« duket e paarsyeshme, por mbani mend se Kubernetes Ă«shtĂ« krijuar fillimisht nga zhvilluesit pĂ«r tĂ« siguruar bashkĂ«punimin e aplikacioneve. Politikat rrjetore u shtuan mĂ« vonĂ«.
Hapësirat emrash
Hapësirat emrash (Namespaces) janë mekanizmi i bashkëpunimit në Kubernetes. Ato janë të destinuara për të izoluar ambientet logjike nga njëra-tjetra, ndërsa shkëmbimi i të dhënave mes hapësirave është lejuar automatikisht.
Si shumica e komponentëve të Kubernetes, politikat rrjetore qëndrojnë në një hapësirë emri të caktuar. Në bllokun metadata mund të specifikoni 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 emri në metadata nuk është specifikuar qartë, sistemi do të përdorë hapësirën e caktuar në kubectl (me default namespace=default):
kubectl apply -n my-namespace -f namespace.yamlRekomandoj të specifikoni qartë hapësirën e emrit, përveç nëse po shkruani një politikë që është e destinuar për disa hapësira emri.
Kryesore element podSelector nĂ« politikĂ« do tĂ« zgjedhĂ« podâĂ«t nga hapĂ«sira emri, tĂ« cilĂ«s i pĂ«rket politika (ai nuk ka akses nĂ« podâĂ«t nga hapĂ«sira tĂ« tjera emri).
NĂ« mĂ«nyrĂ« tĂ« ngjashme, podSelectorâĂ«t nĂ« blloqet ingress dhe egress mund tĂ« zgjedhin podâĂ«t vetĂ«m nga hapĂ«sira e tyre emri, pĂ«rveç nĂ«se i kombinoni ato me namespaceSelector (kjo do tĂ« diskutohet nĂ« seksionin "Filtri sipas hapĂ«sirave emri dhe podâĂ«ve").
Rregullat e emërtimeve të politikave
Emrat e politikave janë unikë brenda një hapësire emri. Nuk mund të ketë dy politika me të njëjtin emër në një hapësirë, por mund të ketë politika me emra të njëjtë në hapësira të ndryshme. Kjo është e dobishme kur dëshironi të ripërdorni të njëjtën politikë në disa hapësira.
MĂ« pĂ«lqen veçanĂ«risht njĂ« nga metodat e emĂ«rtesĂ«s. Ajo pĂ«rfshin kombinimin e emrit tĂ« hapĂ«sirĂ«s emri me qĂ«lluar podâĂ«t. PĂ«r shembull:
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
PĂ«r objektet Kubernetes, si podâĂ«t dhe hapĂ«sirat e emrit, mund tĂ« ngjiten etiketat e personalizuara. Etiketat (labels â etiketa) janĂ« ekuivalente tĂ« etiketave nĂ« cloud. Politikat e rrjetit Kubernetes pĂ«rdorin etiketat pĂ«r tĂ« zgjedhur podâĂ«t, pĂ«r tĂ« cilat ato aplikohen:
podSelector:
matchLabels:
role: db⊠ose hapĂ«sirave emri, pĂ«r tĂ« cilat ato aplikohen. NĂ« kĂ«tĂ« shembull, zgjedhen tĂ« gjitha podâĂ«t nĂ« hapĂ«sirat e emrit me etiketat pĂ«rkatĂ«se:
namespaceSelector:
matchLabels:
project: myproject Një paralajmërim: kur përdorni namespaceSelector sigurohuni që hapësirat e zgjedhura të përmbajnë etiketën e nevojshme. Mbani mend se hapësirat e integruara, si default dhe kube-system, sipas parazgjedhjes nuk përmbajnë etiketa.
Një etiketë mund të shtohet në hapësirën e emrit si më poshtë:
kubectl label namespace default namespace=default Në këtë rast, namespace në seksionin metadata duhet të referohet me emrin aktual të hapësirës, jo me etiketën:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default # <<<
spec:
...Burimi dhe adresati
Politikat pĂ«r firewall janĂ« tĂ« pĂ«rbĂ«rĂ« nga rregulla me burime dhe destinacione. Politikat rrjetĂ«sore Kubernetes pĂ«rcaktohen pĂ«r qĂ«llim â njĂ« grup podâash, pĂ«r tĂ« cilat aplicohen ato, dhe pastaj vendosin rregulla pĂ«r trafikun e hyrĂ«s (ingress) dhe/ose tĂ« daljes (egress). NĂ« shembullin tonĂ«, qĂ«llimi i politikĂ«s do tĂ« jenĂ« tĂ« gjitha podâash nĂ« hapĂ«sirĂ«n e emrave default me etiketĂ«n 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 hyrĂ«s pĂ«r podâat e synuar. NĂ« fjalĂ« tĂ« tjera, ingress vepron si burim, dhe qĂ«llimi si destinacion pĂ«rkatĂ«s. Po ashtu, egress Ă«shtĂ« destinacioni, ndĂ«rsa qĂ«llimi Ă«shtĂ« burimi i tij.
Kjo Ă«shtĂ« ekuivalente me dy rregulla pĂ«r firewall: Ingress â QĂ«llimi; QĂ«llimi â Egress.
Egress dhe DNS (e rëndësishme!)
Duke kufizuar trafikun e daljes, 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 lejuat aplikacionin balance tĂ« lidhet me 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 të rregullohet 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 â Ă«shtĂ« i zbrazĂ«t, dhe pĂ«r kĂ«tĂ« arsye ai indirekt zgjedh tĂ« gjitha podâash 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 funksionon nĂ« hapĂ«sirĂ«n kube-system).
Ky qasje funksionon, megjithatë është shumë lejuese dhe e pasigurt, pasi lejon dërgimin e kërkesave DNS jashtë clustrit.
Mund ta përmirësoni atë me tri hapa të radhës.
1. Lejoni kërkesat DNS vetëm brenda në cluster, 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 kërkesat DNS vetëm në hapësirën e emrave kube-system.
PĂ«r kĂ«tĂ«, duhet tĂ« shtoni njĂ« etiketĂ« nĂ« hapĂ«sirĂ«n e emrave kube-system: kubectl label namespace kube-system namespace=kube-system â dhe ta pĂ«rfshini atĂ« nĂ« politikĂ« pĂ«rmes 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Ă« akoma mĂ« tej dhe tĂ« kufizojnĂ« kĂ«rkesat DNS pĂ«r njĂ« shĂ«rbim tĂ« caktuar DNS nĂ« kube-system. NĂ« seksionin "Filtro sipas hapĂ«sirave tĂ« emrave dhe podâave" do tĂ« diskutohet si tĂ« arrihet kjo.
Një opsion tjetër është të lejoni DNS në nivelin e hapësirës së emrave. Në këtë rast nuk do të nevojitet të hapet 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 E zbrazĂ«t podSelector zgjedh tĂ« gjitha podâat nĂ« hapĂ«sirĂ«n e emrave.
Përputhshmëria e parë dhe rendi i rregullave
Në firewall-in e zakonshëm, veprimi ("Lejo" ose "Ndal") në lidhje me një paketë përcaktohet nga rregulli i parë që plotëson. Në Kubernetes, rendi i politikave s'ka asnjë rëndësi.
PĂ«r default, kur politikat nuk janĂ« tĂ« pĂ«rshkruara, komunikimet midis podâave janĂ« tĂ« lejuara dhe ato mund tĂ« ndajnĂ« lirisht informacion. Sapo filloni tĂ« formoni politika, çdo pod i prekur nga tĂ« paktĂ«n njĂ« prej tyre bĂ«het i izoluari sipas disjunkcionit (logjik OR) tĂ« tĂ« gjitha politikave qĂ« e pĂ«rzgjedhin atĂ«. Podâave qĂ« nuk preken nga asnjĂ« politikĂ« mbeten tĂ« hapura.
Mund të ndryshoni një sjellje të tillë përmes një rregulli pastrimi.
Rregulli i pastrimit ("Ndal")
Politikat e firewall-eve zakonisht ndalojnë çdo trafik që nuk lejohet qartë.
NĂ« Kubernetes nuk ka veprimi "ndal" (deny),megjithatĂ«, njĂ« efekt tĂ« ngjashĂ«m mund tĂ« arrihet me njĂ« politikĂ« tĂ« zakonshme (lejuese), duke zgjedhur njĂ« grup tĂ« zbrazĂ«t podâash burimi (ingress):
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: default
spec:
podSelector: {}
policyTypes:
- Ingress 
Kjo politikë zgjidh të gjitha pod'ët në hapësirën e emrit dhe lë ingress të pacaktuar, duke ndaluar të gjithë trafikun që hyn.
Në mënyrë të ngjashme, mund të kufizoni të gjithë trafikun që del nga hapësira e emrit:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-egress
namespace: default
spec:
podSelector: {}
policyTypes:
- Egress 
Kujdes, çdo politikë tjetër që lejon trafikun në pod'ët në hapësirën e emrit do të ketë përparësi mbi këtë rregull (analog si shtimi i një rregulli lehtësues para një ndalues në konfigurimin e firewall-it).
Lejo të gjitha (Any-Any-Any-Allow)
Për të krijuar politikën "Lejo të gjitha", është e nevojshme 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 akses nga të gjitha pod'ët në të gjitha hapësirat e emrit (dhe të gjitha IP-të) në çdo pod në hapësirën e emrit default. Një sjellje e tillë është e aktivizuar si parazgjedhje, prandaj zakonisht nuk është e nevojshme ta përcaktoni sërish. Megjithatë, ndonjëherë mund të jetë e nevojshme të përkohësoni disa leje specifike për diagnostikimin e një problemi.
Rregulli mund të ngushtohet dhe të lejojë akses vetëm në një grup të caktuar pod'ësh (app:balance) në hapësirën e emrit 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 që hyn (ingress) dhe del (egress), duke përfshirë aksesin në çdo IP jashtë klasit:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all
spec:
podSelector: {}
ingress:
- {}
egress:
- {}
policyTypes:
- Ingress
- Egress 
Kombinimi i politikave të shumta
Politikat kombinohen duke përdorur logjikën ORE në tre nivele; lejet e secilit pod përcaktohen në përputhje me disjunksionin e të gjitha politikave që e prekin atë:
1. Në fushat from dhe to mund të përcaktoni tri lloje elementësh (të gjithë këta kombinohen duke përdorur ORE):
-
namespaceSelectorâ zgjedh hapĂ«sirĂ«n e emrit nĂ« tĂ«rĂ«si; -
podSelectorâ zgjedh pod'Ă«t; -
ipBlockâ zgjedh nĂ«nrrjetĂ«n.
Në këtë mënyrë, numri i elementeve (edhe të njëjta) në nënshkrime from/to nuk është i kufizuar. Të gjitha do të kombinohen me logjikën ORE.
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. Brend politikë ndarëse ingress mund të ketë shumë elemente from (duke u kombinuar logjikisht me ORE). Po ashtu, seksioni egress mund të përmbajë shumë elemente to (po ashtu kombinohen me disjunksion):
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 kombinohen logjikisht me ORE
Por, kur ato kombinohen, ekziston një kufizim, për të cilin : Kubernetes mund të kombinojë politika vetëm me të ndryshme policyTypes (Ingress ose Egress). Politikat që përcaktojnë ingress (ose egress) do të mbizotërojnë mbi njëra-tjetrën.
Lidhja midis hapësirave të emrave
NĂ« mĂ«nyrĂ« default, shkĂ«mbimi i informacionit midis hapĂ«sirave tĂ« emrave Ă«shtĂ« i lejuar. Kjo mund tĂ« ndryshohet pĂ«rmes njĂ« politike ndaluese, e cila do tĂ« kufizojĂ« trafikun e dalshĂ«m dhe/ose hyrĂ«s nĂ« hapĂ«sirĂ«n e emrit (shih âRregulli i pastrimitâ mĂ« sipĂ«r).
Duke bllokuar qasjen nĂ« hapĂ«sirĂ«n e emrave (shih âRregulli i pastrimitâ mĂ« sipĂ«r), mund tĂ« bĂ«ni pĂ«rjashtime nga politika ndaluese duke lejuar lidhjet nga njĂ« hapĂ«sirĂ« emri tĂ« caktuar pĂ«rmes 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Ă« gjithĂ« podâĂ«t nĂ« hapĂ«sirĂ«n e emrave default do tĂ« kenĂ« akses nĂ« podâĂ«t postgres nĂ« hapĂ«sirĂ«n e emĂ«rtimit database. Por, çfarĂ« ndodh nĂ«se dĂ«shiron tĂ« hapĂ«sh qasjen nĂ« postgres vetĂ«m podâĂ«t e caktuar nĂ« hapĂ«sirĂ«n e emrave default?
Filtri sipas hapĂ«sirave tĂ« emrave dhe podâĂ«ve
Kubernetes version 1.11 dhe më lart lejon kombinimin e operatorëve namespaceSelector dhe podSelector përmes logjikës AND. 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 interpretohet si AND në vend të zakonshmes ORE?
Vini re se podSelector nuk fillon me një shkronjë të madhe. Në YAML, kjo do të thotë se podSelector dhe ajo që e ndjek namespaceSelector i përkasin të njëjtit element liste. Prandaj, ato kombinohen logjikisht me AND.
Shtimi i një pese para podSelector do të çojë në krijimin e një elementi të ri të listës, i cili do të kombinohet me atë paraprak namespaceSelector nëpërmjet logjikës OORT.
PĂ«r tĂ« zgjedhur podâĂ«t me njĂ« etiketĂ« tĂ« 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 shumëfishe kombinohen me O.
Rregullat për firewall me objekte të shumta (hostname, rrjete, grupe) kombinohen nëpërmjet logjikës O. Rregulli në vijim do të zbatohet 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 | | | |
| ----------------------------------------| PĂ«rkundrazi, nĂ« Kubernetes etiketat e ndryshme nĂ« podSelector ose namespaceSelector kombinohen me logjikĂ«n E. 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Ă« aplikohet 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.
Subnetët dhe IP adresat (IPBlocks)
Për segmentimin e rrjetit, firewall përdorin VLAN, IP adresat dhe subnetet.
NĂ« Kubernetes, IP adresat i caktohen podâĂ«ve automatikisht dhe mund tĂ« ndryshojnĂ« shpesh, prandaj pĂ«rdoren etiketat pĂ«r tĂ« zgjedhur podâĂ«t dhe hapĂ«sirat e emrave nĂ« politikat rrjetĂ«sore.
SubnetĂ«t (ipBlocks) pĂ«rdoren pĂ«r menaxhimin e lidhjeve tĂ« jashtme (ingress) ose tĂ« daljeve (egress) tĂ« jashtme (North-South). PĂ«r shembull, kjo politikĂ« hap qasje pĂ«r tĂ« gjitha podâĂ«t nga hapĂ«sira e emrit default 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 bosh podâĂ«sh nĂ« kĂ«tĂ« shembull do tĂ« thotĂ« «zgjedh tĂ« gjitha podâĂ«t nĂ« hapĂ«sirĂ«n e emrit».
Kjo politikë hap qasje vetëm në 8.8.8.8; qasje në çdo IP tjetër është e ndaluar. Pra, në thelb, keni bllokuar qasjen në shërbimin e brendshëm DNS të Kubernetes. Nëse dëshironi ta hapni aty, shprehni qartë këtë.
Zakonisht ipBlocks dhe podSelectors janĂ« pĂ«rjashtuese, pasi adresat IP tĂ« brendshme tĂ« podâĂ«ve nuk pĂ«rdoren nĂ« ipBlocks. Duke specifikuar adresat IP tĂ« brendshme tĂ« podâĂ«ve, ju faktikisht do tĂ« lejoni lidhjet nga/drejt pod-Ă«ve me kĂ«to adresa. NĂ« praktikĂ«, nuk do tĂ« dini se cilin IP tĂ« pĂ«rdorni, prandaj nuk duhet 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, si pasojë, lejon qasje në të gjitha pod-ët e tjerë:
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 qasje vetëm për IP-të e jashtme, duke përjashtuar IP-të e 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 të mos i specifikoni numrat e portave në politikat dhe të lini gjithçka sipas parazgjedhjes. Megjithatë, politika rekomandohet të jetë sa më e kufizuar, prandaj në disa raste mund të specifikoni portat:
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 
Vëreni, se selektori ports aplikohet për të gjithë elementet në bllokun to ose from, në të cilin ndodhet. Për të specifikuar portat e ndryshme për grupe të ndryshme elementesh, nda një ingress ose egress në disa nënndahje me to ose from dhe në çdo të shkruani portat 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 portave nga parazgjedhja:
- NĂ«se e hidhni plotĂ«sisht pĂ«r ŰȘŰč۱ÙÙin e portave (
ports), kjo do tĂ« thotĂ« tĂ« gjitha protokollet dhe tĂ« gjitha portat; - NĂ«se e hidhni pĂ«r ŰȘŰč۱ÙÙin e protokollit (
protocol), kjo do tĂ« thotĂ« TCP; - NĂ«se e hidhni pĂ«r ŰȘŰč۱ÙÙin e portit (
port), kjo do të thotë të gjitha portat.
Praktika më e mirë: mos u mbështetni në vlerat e parazgjedhura, specifikoni ato që ju nevojiten qartë.
Kujdes, Ă«shtĂ« e nevojshme tĂ« pĂ«rdoren portet e podâave dhe jo ato tĂ« shĂ«rbimeve (mĂ« shumĂ« rreth kĂ«saj nĂ« paragrafin e ardhshĂ«m).
Politikat janĂ« pĂ«rcaktuar pĂ«r podâatĂ« apo shĂ«rbimet?
NĂ« pĂ«rgjithĂ«si, podâĂ«t nĂ« Kubernetes komunikojnĂ« me njĂ«ri-tjetrin pĂ«rmes shĂ«rbimeve â njĂ« balancues virtual ngarkese qĂ« redirigjon trafikun tek podâĂ«t qĂ« implementojnĂ« shĂ«rbimin. Mund tĂ« mendohet se politikat rrjetore kontrollojnĂ« qasjen nĂ« shĂ«rbime, por nuk Ă«shtĂ« kĂ«shtu. Politikat rrjetore tĂ« Kubernetes funksionojnĂ« me portet e podâave dhe jo me shĂ«rbimet.
PĂ«r shembull, nĂ«se njĂ« shĂ«rbim dĂ«gjon nĂ« portin 80, por redirigjon trafikun nĂ« portin 8080 tĂ« podâave tĂ« tij, nĂ« politikĂ«n rrjetore Ă«shtĂ« e nevojshme tĂ« specifikohet saktĂ«sisht 8080.
NjĂ« mekanizĂ«m tĂ« tillĂ« duhet ta quajmĂ« jo optimal: me ndryshimin e strukturĂ«s sĂ« brendshme tĂ« shĂ«rbimit (portet e tĂ« cilit dĂ«gjojnĂ« podâĂ«t), do tĂ« duhet tĂ« pĂ«rditĂ«sojmĂ« politikat rrjetore.
NjĂ« qasje tĂ« re arkitekturore duke pĂ«rdorur Service Mesh (pĂ«r shembull, shihni pĂ«r Istio mĂ« poshtĂ« â vĂ«rejtje e pĂ«rkthyesit) i lejon tĂ« zgjidhĂ« kĂ«tĂ« problem.
A është e nevojshme të specifikohen si Ingress ashtu edhe Egress?
PĂ«rgjigja e shkurtĂ«r Ă«shtĂ« â po, qĂ« pod A tĂ« mund tĂ« lidhet me pod B, Ă«shtĂ« e nevojshme tĂ« lejohet krijimi i njĂ« lidhjeje dalĂ«se (pĂ«r kĂ«tĂ« duhet tĂ« konfigurohet politika e egress), dhe pod B duhet tĂ« ketĂ« mundĂ«si pĂ«r tĂ« pranuar njĂ« lidhje hyrĂ«se (pĂ«r kĂ«tĂ«, sigurisht, nevojitet politika e ingress).
Megjithatë, në praktikë, mund të mbështeteni në politikën e paracaktuar, e cila lejon lidhjet në një ose të dyja drejtimet.
Nëse një pod-burimi do të zgjidhet nga një ose disa egress-politika, kufizimet që i vendosen atij do të përcaktohen nga disjunksioni i tyre. Në këtë rast, do të nevojitet të lejohet qartazi lidhja me pod-in-destinat. Nëse pod-i nuk zgjidhet nga ndonjë politikë, trafiku i tij dalës (egress) lejohet automatikisht.
Po ashtu, fati i pod-it-destinat, i zgjedhur nga një ose disa ingress-politika, do të përcaktohet nga disjunksioni i tyre. Në këtë rast, është e nevojshme të lejohet qartazi të marrë trafik nga pod-i-burim. Nëse pod-i nuk zgjidhet nga ndonjë politikë, e gjithë trafiku hyrës (ingress) për të lejohet automatikisht.
Shihni seksionin "Stateful ose Stateless" më poshtë.
DĂ«gjimet
Politikat rrjetore të Kubernetes nuk kanë kapacitet për të regjistruar trafikun. Kjo e komplikon përcaktimin nëse politika funksionon si duhet dhe e vështirëson analizën në fushën e sigurisë.
Kontrolli i trafikut ndaj shërbimeve të jashtme
Politikat e rrjetit të Kubernetes nuk lejojnë specifikimin e një emri të plotë domeni (DNS) në seksionet e egress. Ky shqetësim çon në shqetësime të konsiderueshme kur përpiqeni të kufizoni trafikun drejt adresave të jashtme që nuk kanë një IP të fiksuar (si aws.com).
Kontrolli i politikës
Firewall-et do t'ju paralajmërojnë ose madje do të refuzojnë të pranoni një politikë të gabuar. Kubernetes gjithashtu bën disa verifikime. Kur definoni politikën e rrjetit përmes kubectl, Kubernetes mund të deklarojë se ajo është e pavlefshme dhe të refuzojë ta pranojë. Në raste të tjera, Kubernetes do ta pranojë politikën dhe do ta plotësojë me detajet që mungojnë. Ato mund të shihen përmes komandës:
kubernetes get networkpolicy -o yamlMbani parasysh se sistemi i kontrollit të Kubernetes nuk është i infallibil dhe mund të kalojë disa lloje gabimesh.
Ekzekutimi
Kubernetes nuk merret me zbatimin e politikave tĂ« rrjetit vetĂ«, por Ă«shtĂ« vetĂ«m njĂ« portĂ« API, e cila i ngarkon punĂ«n e ndĂ«rlikuar tĂ« kontrollit sistemit nĂ«ntokĂ«sor tĂ« quajtur Container Networking Interface (CNI). Definimi i politikave nĂ« klasterin Kubernetes pa pĂ«rcaktimin e CNI pĂ«rkatĂ«s Ă«shtĂ« si tĂ« krijosh politika nĂ« njĂ« server menaxhimi firewall pa i instaluar mĂ« pas ato nĂ« firewall-e. Ju duhet tĂ« siguroheni pĂ«r njĂ« CNI tĂ« denjĂ« ose, nĂ« rastin e platformave Kubernetes qĂ« janĂ« tĂ« vendosura nĂ« cloud, (me njĂ« listĂ« ofruesish mund tĂ« konsultoheni â shĂ«nim i redaktorit), pĂ«r tĂ« angazhuar politikat e rrjetit qĂ« do tĂ« vendosin CNI pĂ«r ju.
Kujdes, Kubernetes nuk do t'ju paralajmërojë nëse definoni një politikë rrjeti pa CNI-në mbështetës përkatës.
Stateful apo Stateless?
Të gjitha CNI-të e Kubernetes me të cilat kam pasur takime ruajnë gjendjen (p.sh., Calico përdor conntrack të Linux). Kjo lejon që pod-i të marrë përgjigje nga lidhja TCP që ka iniciuar pa nevojën për ta rivendosur atë. Megjithatë, nuk di për asnjë standart të Kubernetes që garanton ruajtjen e gjendjes (statefulness).
Menaxhimi i avancuar i politikës së sigurisë
Ja disa mënyra për të rritur efektivitetin e zbatimit të politikës së sigurisë në Kubernetes:
- Shembulli i arkitekturës së pattern-it Service Mesh përdor kontejnerë sidecar për të siguruar telemetri të detajuar dhe kontroll mbi trafikun në nivelin e shërbimeve. Një shembull mund të jetë .
- Disa nga ofruesit e CNI kanë plotësuar mjetet e tyre për t'u shtrirë 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 screenshotet e përmendura më sipër).
Informacione shtesë
- ;
- ;
- ;
- .
PĂ«rfundim
Politikat rrjetore të Kubernetes ofrojnë një set të mirë mjetesh për segmentimin e klasterëve, megjithatë ato janë intuitivisht të paqartë dhe kanë shumë nuanca. Unë besoj 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ërkufizimeve të politikave ose përdorimi i mjeteve të tjera të segmentimit.
Shpresoj se ky udhëzues do të ndihmojë në sqarimin e disa çështjeve dhe në zgjidhjen e problemeve me të cilat mund të përballeni.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- "Kthehu në mikroshërbime me Istio": , , ;
- âUdhĂ«zuesi i Ilustruar pĂ«r StrukturĂ«n e Rrjeteve nĂ« Kubernetesâ: , ;
- «»;
- «»;
- «».
Burimi: habr.com
