🥇Hyrje në politikat e rrjetit Kubernetes për profesionistët e sigurisë

Shënim. përkth.: Autori i artikullit, Reuven Harrison, ka mbi 20 vjet përvojë në zhvillimin e softuerit dhe sot është CTO dhe bashkëthemelues i Tufin, një kompani që krijon zgjidhje për menaxhimin e politikave të sigurisë. Ndërsa ai i sheh politikat e rrjetit Kubernetes si një mjet mjaft të fuqishëm për segmentimin e rrjetit në një grup, ai gjithashtu beson se ato nuk janë aq të lehta për t'u zbatuar në praktikë. Ky material (mjaft voluminoz) synon të përmirësojë ndërgjegjësimin e specialistëve për këtë çështje dhe t'i ndihmojë ata të krijojnë konfigurimet e nevojshme.

Sot, shumë kompani po zgjedhin gjithnjë e më shumë Kubernetes për të ekzekutuar aplikacionet e tyre. Interesi për këtë softuer është aq i lartë sa disa e quajnë Kubernetes "sistemi i ri operativ për qendrën e të dhënave". Gradualisht, Kubernetes (ose k8s) po fillon të perceptohet si një pjesë kritike e biznesit, e cila kërkon organizimin e proceseve të pjekura të biznesit, duke përfshirë sigurinë e rrjetit.

Për profesionistët e sigurisë që janë në mëdyshje duke punuar me Kubernetes, zbulimi i vërtetë mund të jetë politika e paracaktuar e platformës: lejo gjithçka.

Ky udhëzues do t'ju ndihmojë të kuptoni strukturën e brendshme të politikave të rrjetit; kuptoni se si ndryshojnë nga rregullat për muret e rregullta të zjarrit. Ai gjithashtu do të mbulojë disa gracka dhe do të ofrojë rekomandime për të ndihmuar në sigurimin e aplikacioneve në Kubernetes.

Politikat e rrjetit Kubernetes

Mekanizmi i politikës së rrjetit Kubernetes ju lejon të menaxhoni ndërveprimin e aplikacioneve të vendosura në platformë në shtresën e rrjetit (e treta në modelin OSI). Politikave të rrjetit u mungojnë disa nga veçoritë e avancuara të mureve të zjarrit modern, si zbatimi i OSI Layer 7 dhe zbulimi i kërcënimeve, por ato ofrojnë një nivel bazë të sigurisë së rrjetit që është një pikënisje e mirë.

Politikat e rrjetit kontrollojnë komunikimet ndërmjet pods

Ngarkesat e punës në Kubernetes shpërndahen nëpër pods, të cilat përbëhen nga një ose më shumë kontejnerë të vendosur së bashku. Kubernetes i cakton çdo pod një adresë IP që është e aksesueshme nga pods të tjera. Politikat e rrjetit Kubernetes vendosin të drejtat e aksesit për grupet e pod-ve në të njëjtën mënyrë që grupet e sigurisë në renë kompjuterike përdoren për të kontrolluar aksesin në instancat e makinës virtuale.

Përcaktimi i politikave të rrjetit

Ashtu si burimet e tjera të Kubernetes, politikat e rrjetit janë të specifikuara në YAML. Në shembullin më poshtë, aplikacioni balance qasje 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ënim. përkth.: kjo pamje e ekranit, si të gjitha të ngjashmet e mëvonshme, u krijua jo duke përdorur mjete vendase Kubernetes, por duke përdorur mjetin Tufin Orca, i cili u zhvillua nga kompania e autorit të artikullit origjinal dhe i cili përmendet në fund të materialit.)

Për të përcaktuar politikën tuaj të rrjetit, do t'ju duhet njohuri bazë e YAML. Kjo gjuhë bazohet në dhëmbëzim (të specifikuar nga hapësirat dhe jo nga skedat). Një element i dhëmbëzuar i përket elementit më të afërt të dhëmbëzuar mbi të. Një element i ri i listës fillon me vizë, të gjithë elementët e tjerë kanë formën çelës-vlerë.

Pasi të keni përshkruar politikën në YAML, përdorni kubectlpër ta krijuar atë në grup:

kubectl create -f policy.yaml

Specifikimi i politikës së rrjetit

Specifikimi i politikës së rrjetit Kubernetes përfshin katër elementë:

podSelector: përcakton grupet e prekura nga kjo politikë (objektivat) - kërkohet;
policyTypes: tregon se çfarë lloje politikash përfshihen në këtë: hyrje dhe/ose dalje - opsionale, por unë rekomandoj ta specifikoni në mënyrë eksplicite në të gjitha rastet;
ingress: përcakton lejuar hyrëse trafiku në grupet e synuara është fakultativ;
egress: përcakton lejuar dalëse trafiku nga grupet e synuara është fakultativ.

Shembull i marrë nga faqja e internetit Kubernetes (unë zëvendësova role mbi 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

Ju lutemi vini re se të katër elementët nuk duhet të përfshihen. Është vetëm e detyrueshme podSelector, parametrat e tjerë mund të përdoren sipas dëshirës.

Nëse e lëshoni policyTypes, politika do të interpretohet si më poshtë:

Si parazgjedhje, supozohet se ai përcakton anën e hyrjes. Nëse politika nuk e shpreh qartë këtë, sistemi do të supozojë se i gjithë trafiku është i ndaluar.
Sjellja në anën e daljes do të përcaktohet nga prania ose mungesa e parametrit përkatës të daljes.

Për të shmangur gabimet unë rekomandoj bëjeni gjithmonë të qartë policyTypes.

Sipas logjikës së mësipërme, nëse parametrat ingress dhe / ose egress i anashkaluar, politika do të refuzojë të gjithë trafikun (shih "Rregullin e zhveshjes" më poshtë).

Politika e parazgjedhur është Lejo

Nëse nuk përcaktohen politika, Kubernetes lejon të gjithë trafikun si parazgjedhje. Të gjitha pods mund të shkëmbejnë lirisht informacion mes tyre. Kjo mund të duket kundërintuitive nga pikëpamja e sigurisë, por mbani mend se Kubernetes fillimisht u krijua nga zhvilluesit për të mundësuar ndërveprimin e aplikacioneve. Politikat e rrjetit u shtuan më vonë.

Hapësirat e emrave

Hapësirat e emrave janë mekanizmi i bashkëpunimit Kubernetes. Ato janë krijuar për të izoluar mjediset logjike nga njëri-tjetri, ndërsa komunikimi ndërmjet hapësirave lejohet si parazgjedhje.

Ashtu si shumica e komponentëve të Kubernetes, politikat e rrjetit jetojnë në një hapësirë të caktuar emri. Në bllok metadata ju mund të specifikoni se cilës hapësirë i përket politika:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

Nëse hapësira e emrave nuk është specifikuar në mënyrë eksplicite në meta të dhënat, sistemi do të përdorë hapësirën e emrave të specifikuar në kubectl (si parazgjedhje namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

Rekomandoj specifikoni hapësirën e emrave në mënyrë eksplicite, përveç nëse jeni duke shkruar një politikë që synon shumë hapësira emrash në të njëjtën kohë.

Kryesore element podSelector në politikë do të zgjedhë pods nga hapësira e emrave të cilës i përket politika (i mohohet qasja në pods nga një hapësirë tjetër emri).

Në mënyrë të ngjashme, podSelectors në blloqet e hyrjes dhe daljes mund të zgjedhin vetëm pods nga hapësira e tyre e emrave, përveç nëse sigurisht i kombinoni me to namespaceSelector (kjo do të diskutohet në seksionin "Filtro sipas hapësirave të emrave dhe grupeve").

Rregullat e emërtimit të politikave

Emrat e politikave janë unikë brenda të njëjtës hapësirë emri. Nuk mund të ketë dy politika me të njëjtin emër në të njëjtën hapësirë, por mund të ketë politika me të njëjtin emër në hapësira të ndryshme. Kjo është e dobishme kur dëshironi të riaplikoni të njëjtën politikë në hapësira të shumta.

Më pëlqen veçanërisht një nga metodat e emërtimit. Ai konsiston në kombinimin e emrit të hapësirës së emrave me grupet e synuara. 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

Mund t'i bashkëngjitni etiketa të personalizuara objekteve Kubernetes, të tilla si pods dhe hapësirat e emrave. Etiketat (etiketat - etiketat) janë ekuivalente e etiketave në re. Politikat e rrjetit Kubernetes përdorin etiketa për të zgjedhur bishtajatpër të cilat aplikohen:

podSelector:
  matchLabels:
    role: db

… ose hapësirat e emravepër të cilat aplikohen. Ky shembull zgjedh të gjitha pods në hapësirat e emrave me etiketat përkatëse:

namespaceSelector:
  matchLabels:
    project: myproject

Një kujdes: kur përdorni namespaceSelector sigurohuni që hapësirat e emrave që zgjidhni të përmbajnë etiketën e duhur. Kini parasysh se hapësirat e integruara të emrave si p.sh default и kube-system, si parazgjedhje nuk përmbajnë etiketa.

Ju mund të shtoni një etiketë në një hapësirë si kjo:

kubectl label namespace default namespace=default

Në të njëjtën kohë, hapësira e emrit në seksion metadata duhet t'i referohet emrit aktual të hapësirës, jo etiketës:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

Burimi dhe destinacioni

Politikat e mureve të zjarrit përbëhen nga rregulla me burime dhe destinacione. Politikat e rrjetit Kubernetes përcaktohen për një objektiv - një grup pods për të cilat ato zbatohen - dhe më pas vendosin rregulla për trafikun hyrës dhe/ose dalje. Në shembullin tonë, objektivi i politikës do të jenë të gjitha pods në hapësirën e emrave default me etiketë me çelës app dhe kuptimi 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 hyrës në grupet e synuara. Me fjalë të tjera, hyrja është burimi dhe objektivi është destinacioni përkatës. Po kështu, dalja është destinacioni dhe objektivi është burimi i tij.

Kjo është e barabartë me dy rregulla të murit të zjarrit: Ingress → Target; Qëllimi → Dalja.

Egress dhe DNS (e rëndësishme!)

Duke kufizuar trafikun në dalje, kushtojini vëmendje të veçantë DNS - Kubernetes përdor këtë shërbim për të hartuar shërbimet në adresat IP. Për shembull, politika e mëposhtme nuk do të funksionojë sepse nuk e keni lejuar aplikacionin balance hyni në 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 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ë bosh, dhe për këtë arsye zgjedh në mënyrë indirekte të gjitha grupet në të gjitha hapësirat e emrave, duke lejuar balance dërgoni pyetje DNS në shërbimin e duhur Kubernetes (zakonisht funksionon në hapësirë kube-system).

Kjo qasje funksionon, megjithatë tepër lejues dhe i pasigurt, sepse lejon që pyetjet DNS të drejtohen jashtë grupit.

Ju mund ta përmirësoni atë në tre hapa të njëpasnjëshëm.

1. Lejo vetëm pyetje DNS brenda grumbulloni 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. Lejo pyetjet DNS vetëm brenda hapësirës së emrave kube-system.

Për ta bë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 shkruani në përdorimin e politikave 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. Njerëzit paranojakë mund të shkojnë edhe më tej dhe të kufizojnë pyetjet DNS në një shërbim specifik DNS kube-system. Seksioni "Filtro sipas hapësirave të emrave dhe grupeve" do t'ju tregojë se si ta arrini këtë.

Një tjetër mundësi është të zgjidhni DNS në nivelin e hapësirës së emrave. Në këtë rast, nuk do të duhet 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

Bosh podSelector zgjedh të gjitha podet në hapësirën e emrave.

Përputhja e parë dhe renditja e rregullave

Në muret e zjarrit konvencional, veprimi (Lejo ose Refuzo) në një paketë përcaktohet nga rregulli i parë që plotëson. Në Kubernetes, rendi i politikave nuk ka rëndësi.

Si parazgjedhje, kur nuk caktohen politika, komunikimet ndërmjet pods lejohen dhe ato mund të shkëmbejnë lirisht informacion. Pasi të filloni të formuloni politika, çdo pod i prekur nga të paktën njëra prej tyre bëhet i izoluar sipas ndarjes (OR logjike) të të gjitha politikave që e kanë përzgjedhur. Pods që nuk preken nga asnjë politikë mbeten të hapura.

Ju mund ta ndryshoni këtë sjellje duke përdorur një rregull zhveshjeje.

Rregulli i heqjes ("Mohoni")

Politikat e murit të zjarrit zakonisht mohojnë çdo trafik që nuk lejohet në mënyrë eksplicite.

Nuk ka asnjë veprim mohues në Kubernetes, megjithatë, një efekt i ngjashëm mund të arrihet me një politikë të rregullt (lejuese) duke zgjedhur një grup bosh të pods burimore (hyrje):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Kjo politikë zgjedh të gjitha grupet në hapësirën e emrave dhe e lë hyrjen të papërcaktuar, duke mohuar të gjithë trafikun në hyrje.

Në mënyrë të ngjashme, ju mund të kufizoni të gjithë trafikun dalës nga një hapësirë emri:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress

Ju lutem vini re se çdo politikë shtesë që lejon trafikun në pods në hapësirën e emrave do të ketë përparësi ndaj këtij rregulli (e ngjashme me shtimin e një rregulli leje përpara një rregulli të mohimit në një konfigurim të murit të zjarrit).

Lejo gjithçka (Any-Any-Any-Allow)

Për të krijuar një politikë Lejo të gjitha, duhet të plotësoni politikën e mohimit të mësipërm me një element bosh ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

Ai lejon hyrjen nga të gjitha pods në të gjitha hapësirat e emrave (dhe të gjitha IP-të) në çdo pod në hapësirën e emrave default. Kjo sjellje është aktivizuar si parazgjedhje, kështu që zakonisht nuk ka nevojë të përcaktohet më tej. Megjithatë, ndonjëherë mund t'ju duhet të çaktivizoni përkohësisht disa leje specifike për të diagnostikuar problemin.

Rregulli mund të ngushtohet për të lejuar aksesin vetëm në një grup specifik me bishtaja (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 hyrës dhe dalës, duke përfshirë aksesin në çdo IP jashtë grupit:

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 OSE logjike në tre nivele; Lejet e çdo pod janë caktuar në përputhje me ndarjen e të gjitha politikave që e prekin atë:

1. Në fusha from и to Mund të përcaktohen tre lloje elementësh (të cilët të gjithë kombinohen duke përdorur OR):

namespaceSelector — zgjedh të gjithë hapësirën e emrave;
podSelector — zgjedh bishtajat;
ipBlock — zgjedh një nënrrjet.

Për më tepër, numri i elementeve (madje edhe ato identike) në nënseksione from/to jo i kufizuar. Të gjithë ata do të kombinohen me OR logjik.

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. Brenda seksionit të politikave ingress mund të ketë shumë elementë from (të kombinuara me OR logjike). Në mënyrë të ngjashme, seksioni egress mund të përfshijë shumë elementë to (e kombinuar gjithashtu me ndarje):

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. Politika të ndryshme kombinohen gjithashtu me OSE logjike

Por kur i kombinoni ato, ekziston një kufizim mbi të cilin vuri në dukje Chris Cooney: Kubernetes mund të kombinojë politika vetëm me të ndryshme policyTypes (Ingress ose Egress). Politikat që përcaktojnë hyrjen (ose daljen) do të mbishkruajnë njëra-tjetrën.

Marrëdhënia midis hapësirave të emrave

Si parazgjedhje, ndarja e informacionit midis hapësirave të emrave lejohet. Kjo mund të ndryshohet duke përdorur një politikë të refuzimit që do të kufizojë trafikun dalës dhe/ose hyrje në hapësirën e emrave (shih "Rregullin e heqjes" më lart).

Pasi të keni bllokuar hyrjen në një hapësirë emri (shih "Rregullin e zhveshjes" më sipër), mund të bëni përjashtime nga politika e mohimit duke lejuar lidhje nga një hapësirë e caktuar emri duke përdorur 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 pods në hapësirën e emrave default do të ketë akses në pods postgres në hapësirën e emrave database. Por çfarë nëse doni të hapni aksesin në postgres vetëm pods specifike në hapësirën e emrave default?

Filtro sipas hapësirave të emrave dhe grupeve

Versioni i Kubernetes 1.11 dhe më i lartë ju lejon të kombinoni operatorët namespaceSelector и podSelector duke përdorur logjikën 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 kjo interpretohet si DHE në vend të OSE-së së zakonshme?

Vini re se podSelector nuk fillon me vizë. Në YAML kjo do të thotë se podSelector dhe duke qëndruar përballë tij namespaceSelector referojuni të njëjtit element të listës. Prandaj, ato kombinohen me DHE logjike.

Shtimi i një vizë më parë podSelector do të rezultojë në shfaqjen e një elementi të ri të listës, i cili do të kombinohet me atë të mëparshëm namespaceSelector duke përdorur OSE logjike.

Për të zgjedhur pods me një etiketë specifike 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

Etiketa të shumta bashkohen me I

Rregullat për një mur zjarri me objekte të shumta (host, rrjete, grupe) kombinohen duke përdorur OR logjike. Rregulli i mëposhtëm do të funksionojë nëse burimi i paketës përputhet Host_1 OR Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

Përkundrazi, në Kubernetes etiketat e ndryshme në podSelector ose namespaceSelector janë të kombinuara me logjike AND. Për shembull, rregulli i mëposhtëm do të zgjedhë podat që kanë të dyja etiketat, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

E njëjta logjikë vlen për të gjitha llojet e operatorëve: përzgjedhësit e objektivave të politikave, përzgjedhësit e pod dhe përzgjedhësit e hapësirës së emrave.

Nënrrjetet dhe adresat IP (IPBlocks)

Firewall-et përdorin VLAN, adresa IP dhe nënrrjeta për të segmentuar një rrjet.

Në Kubernetes, adresat IP u caktohen podeve automatikisht dhe mund të ndryshojnë shpesh, kështu që etiketat përdoren për të zgjedhur pods dhe hapësirat e emrave në politikat e rrjetit.

Nënrrjetet (ipBlocks) përdoren kur menaxhoni lidhjet hyrëse (hyrje) ose dalëse (dalje) të jashtme (Veri-Jug). Për shembull, kjo politikë hapet për të gjitha pods nga hapësira e emrave default qasja në shërbimin Google DNS:

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

Zgjedhësi i zbrazët i pod në këtë shembull do të thotë "zgjidh të gjitha pods në hapësirën e emrave".

Kjo politikë lejon vetëm aksesin në 8.8.8.8; qasja në çdo IP tjetër është e ndaluar. Pra, në thelb, ju keni bllokuar aksesin në shërbimin e brendshëm Kubernetes DNS. Nëse ende dëshironi ta hapni, tregoni këtë në mënyrë eksplicite.

Zakonisht ipBlocks и podSelectors janë reciprokisht ekskluzive, pasi adresat IP të brendshme të pods nuk përdoren në ipBlocks. Duke treguar pods të brendshëm IP, në fakt do të lejoni lidhjet me/nga pods me këto adresa. Në praktikë, ju nuk do të dini se cilën adresë IP të përdorni, kjo është arsyeja pse ato nuk duhet të përdoren për të zgjedhur pods.

Si kundërshembull, politika e mëposhtme përfshin të gjitha IP-të dhe për këtë arsye lejon aksesin në të gjitha pod-et 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 akses vetëm në IP të jashtme, duke përjashtuar adresat IP të brendshme të pods. Për shembull, nëse nënrrjeti 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

Portet dhe protokollet

Në mënyrë tipike, pods dëgjojnë një port. Kjo do të thotë që thjesht nuk mund të specifikoni numrat e portit në politika dhe të lini gjithçka si parazgjedhje. Megjithatë, rekomandohet që politikat të bëhen sa më kufizuese të jetë e mundur, kështu që në disa raste mund të specifikoni portet:

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 re se zgjedhësi ports vlen për të gjithë elementët në bllok to ose from, i cili përmban. Për të specifikuar porte të ndryshme për grupe të ndryshme elementesh, ndani ingress ose egress në disa nënseksione me to ose from dhe në çdo regjistrim 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

Funksionimi i parazgjedhur i portit:

Nëse e hiqni plotësisht përkufizimin e portit (ports), kjo do të thotë të gjitha protokollet dhe të gjitha portet;
Nëse e lini jashtë përkufizimin e protokollit (protocol), kjo do të thotë TCP;
Nëse e hiqni përkufizimin e portit (port), kjo do të thotë të gjitha portet.

Praktika më e mirë: Mos u mbështetni në vlerat e paracaktuara, specifikoni atë që ju nevojitet në mënyrë eksplicite.

Ju lutemi vini re se duhet të përdorni porte pod, jo porte shërbimi (më shumë për këtë në paragrafin tjetër).

A përcaktohen politika për grupet ose shërbimet?

Në mënyrë tipike, pods në Kubernetes aksesojnë njëri-tjetrin përmes një shërbimi - një balancues virtual i ngarkesës që ridrejton trafikun në pods që zbatojnë shërbimin. Ju mund të mendoni se politikat e rrjetit kontrollojnë aksesin në shërbime, por nuk është kështu. Politikat e rrjetit Kubernetes funksionojnë në porte pod, jo në porte shërbimi.

Për shembull, nëse një shërbim dëgjon portin 80, por ridrejton trafikun në portin 8080 të pod-eve të tij, saktësisht 8080 duhet të specifikohet në politikën e rrjetit.

Një mekanizëm i tillë duhet të konsiderohet jooptimal: nëse struktura e brendshme e shërbimit (portet e të cilave dëgjojnë podet) ndryshon, politikat e rrjetit do të duhet të përditësohen.

Qasje e re arkitekturore duke përdorur Service Mesh (për shembull, shih për Istio më poshtë - përafërsisht përkth.) ju lejon të përballeni me këtë problem.

A është e nevojshme të regjistroheni si Ingress ashtu edhe Egress?

Përgjigja e shkurtër është po, në mënyrë që pod A të komunikojë me pod B, duhet të lejohet të krijojë një lidhje dalëse (për këtë ju duhet të konfiguroni një politikë daljeje), dhe pod B duhet të jetë në gjendje të pranojë një lidhje hyrëse ( për këtë, në përputhje me rrethanat, ju nevojitet një politikë hyrëse).

Sidoqoftë, në praktikë, mund të mbështeteni në politikën e paracaktuar për të lejuar lidhjet në një ose të dy drejtimet.

Nëse disa pod-burim do të përzgjidhet nga një ose më shumë dalje- politikanëve, kufizimet e vendosura ndaj saj do të përcaktohen nga ndarja e tyre. Në këtë rast, do t'ju duhet të lejoni në mënyrë eksplicite lidhjen me pod -tek adresuesi. Nëse një pod nuk zgjidhet nga ndonjë politikë, trafiku i tij në dalje (dalje) lejohet si parazgjedhje.

Në mënyrë të ngjashme, fati i pod ështëadresa, të zgjedhur nga një ose më shumë hyj-politikanët, do të përcaktohen nga ndarja e tyre. Në këtë rast, duhet ta lejoni në mënyrë eksplicite që të marrë trafik nga podi i burimit. Nëse një pod nuk zgjidhet nga ndonjë politikë, i gjithë trafiku hyrës për të lejohet si parazgjedhje.

Shihni Shtet ose pa shtetësi më poshtë.

Regjistrat

Politikat e rrjetit Kubernetes nuk mund të regjistrojnë trafikun. Kjo e bën të vështirë përcaktimin nëse një politikë po funksionon siç synohet dhe e ndërlikon shumë analizën e sigurisë.

Kontrolli i trafikut drejt shërbimeve të jashtme

Politikat e rrjetit Kubernetes nuk ju lejojnë të specifikoni një emër domaini plotësisht të kualifikuar (DNS) në seksionet e daljes. Ky fakt çon në bezdi të konsiderueshme kur përpiqeni të kufizoni trafikun në destinacione të jashtme që nuk kanë një adresë IP fikse (si p.sh. aws.com).

Kontrolli i politikës

Firewall-et do t'ju paralajmërojnë ose madje do të refuzojnë të pranoni politikën e gabuar. Kubernetes gjithashtu bën disa verifikime. Kur vendosni një politikë rrjeti përmes kubectl, Kubernetes mund të deklarojë se është e pasaktë dhe të refuzojë ta pranojë atë. Në raste të tjera, Kubernetes do të marrë politikën dhe do ta plotësojë atë me detajet që mungojnë. Ato mund të shihen duke përdorur komandën:

kubernetes get networkpolicy <policy-name> -o yaml

Mbani në mend se sistemi i vlefshmërisë Kubernetes nuk është i pagabueshëm dhe mund të humbasë disa lloje gabimesh.

Ekzekutim

Kubernetes nuk zbaton vetë politikat e rrjetit, por është thjesht një portë API që delegon barrën e kontrollit tek një sistem themelor i quajtur Ndërfaqja e Rrjetit të Kontejnerëve (CNI). Vendosja e politikave në një grupim Kubernetes pa caktuar CNI-në e duhur është njësoj si krijimi i politikave në një server të menaxhimit të murit të zjarrit pa i instaluar më pas ato në muret e zjarrit. Varet nga ju që të siguroheni që të keni një CNI të mirë ose, në rastin e platformave Kubernetes, të strehuar në renë kompjuterike (mund të shihni listën e ofruesve këtu - përafërsisht. trans.), aktivizoni politikat e rrjetit që do të vendosin CNI për ju.

Vini re se Kubernetes nuk do t'ju paralajmërojë nëse vendosni një politikë rrjeti pa ndihmën e duhur CNI.

Shtet apo pa shtetësi?

Të gjitha CNI-të e Kubernetes që kam hasur janë të statusit (për shembull, Calico përdor Linux conntrack). Kjo lejon podin të marrë përgjigje në lidhjen TCP që ka nisur pa pasur nevojë ta rivendosë atë. Sidoqoftë, nuk jam në dijeni të një standardi Kubernetes që do të garantonte shtetësinë.

Menaxhimi i avancuar i politikave të sigurisë

Këtu janë disa mënyra për të përmirësuar zbatimin e politikave të sigurisë në Kubernetes:

Modeli arkitektonik i Service Mesh përdor kontejnerët e karrigeve anësore për të ofruar telemetri të detajuar dhe kontroll të trafikut në nivel shërbimi. Si shembull mund të marrim Istio.
Disa nga shitësit CNI kanë zgjeruar mjetet e tyre për të shkuar përtej politikave të rrjetit Kubernetes.
Tufin Orca Ofron shikueshmëri dhe automatizim të politikave të rrjetit Kubernetes.

Paketa Tufin Orca menaxhon politikat e rrjetit Kubernetes (dhe është burimi i pamjeve të mësipërme).

Informacion shtesë

Përfundim

Politikat e rrjetit Kubernetes ofrojnë një grup të mirë mjetesh për segmentimin e grupimeve, por ato nuk janë intuitive dhe kanë shumë hollësi. Për shkak të këtij kompleksiteti, unë besoj se shumë politika ekzistuese të grupimeve janë të gabuara. Zgjidhjet e mundshme për këtë problem përfshijnë automatizimin e përkufizimeve të politikave ose përdorimin e mjeteve të tjera të segmentimit.

Shpresoj që ky udhëzues të ndihmojë në sqarimin e disa pyetjeve dhe zgjidhjen e problemeve që mund të hasni.

PS nga përkthyesi

Lexoni edhe në blogun tonë:

"Kthehu te mikroshërbimet me Istio": Pjesa 1 (hyrje në tiparet kryesore), pjesa 2 (drejtimi, kontrolli i trafikut), pjesa 3 (siguria);
"Një udhëzues i ilustruar për rrjetëzimin në Kubernetes": pjesët 1 dhe 2 (modeli i rrjetit, rrjetet e mbivendosjes), pjesa 3 (shërbimet dhe përpunimi i trafikut);
«Docker dhe Kubernetes në mjedise të ndjeshme ndaj sigurisë"?
«9 praktikat më të mira për sigurinë e Kubernetes"?
«11 mënyra për të (të mos) bërë viktimë e një hakimi të Kubernetes'.

Burimi: www.habr.com

Një hyrje në politikat e rrjetit Kubernetes për profesionistët e sigurisë