In yntroduksje ta Kubernetes netwurkbelied foar befeiligingsprofessionals

Noat. transl.: De skriuwer fan it artikel, Reuven Harrison, hat mear as 20 jier ûnderfining yn softwareûntwikkeling, en hjoed is de CTO en mei-oprjochter fan Tufin, in bedriuw dat oplossings foar befeiligingsbelied makket. Wylst hy Kubernetes netwurkbelied besjocht as in frij krêftich ark foar netwurksegmentaasje yn in kluster, is hy ek fan betinken dat se net sa maklik binne yn 'e praktyk te realisearjen. Dit materiaal (hiel volumineus) is bedoeld om it bewustwêzen fan spesjalisten fan dit probleem te ferbetterjen en har te helpen de nedige konfiguraasjes te meitsjen.

Tsjintwurdich kieze in protte bedriuwen hieltyd mear Kubernetes om har applikaasjes út te fieren. De belangstelling foar dizze software is sa heech dat guon Kubernetes "it nije bestjoeringssysteem foar it datasintrum" neame. Stadichoan, Kubernetes (of k8s) begjint te wurde waarnommen as in kritysk ûnderdiel fan it bedriuw, dat fereasket de organisaasje fan folwoeksen saaklike prosessen, ynklusyf netwurk feiligens.

Foar befeiligingsprofessionals dy't fernuvere binne troch te wurkjen mei Kubernetes, kin de echte iepenbiering it standertbelied fan it platfoarm wêze: alles tastean.

Dizze gids sil jo helpe om de ynterne struktuer fan netwurkbelied te begripen; begripe hoe't se ferskille fan 'e regels foar reguliere firewalls. It sil ek wat falkûlen dekke en oanbefellings leverje om applikaasjes op Kubernetes te befeiligjen.

Kubernetes netwurk belied

It Kubernetes-netwurkbeliedmeganisme lit jo de ynteraksje beheare fan applikaasjes ynset op it platfoarm by de netwurklaach (de tredde yn it OSI-model). Netwurkbelied misse guon fan 'e avansearre funksjes fan moderne firewalls, lykas OSI Layer 7 hanthavenjen en bedrigingsdeteksje, mar se leverje in basisnivo fan netwurkfeiligens dat in goed begjinpunt is.

Netwurkbelied kontrolearret kommunikaasje tusken pods

Wurklêsten yn Kubernetes wurde ferdield oer pods, dy't besteane út ien of mear konteners dy't tegearre ynset binne. Kubernetes jout elke pod in IP-adres ta dat tagonklik is fan oare pods. Kubernetes netwurkbelied set tagongsrjochten foar groepen pods op deselde manier as feiligensgroepen yn 'e wolk wurde brûkt om tagong ta virtuele masine-eksimplaren te kontrolearjen.

It definiearjen fan netwurkbelied

Lykas oare Kubernetes-boarnen wurde netwurkbelied spesifisearre yn YAML. Yn it foarbyld hjirûnder, de applikaasje balance tagong ta 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

(Noat. transl.: dit skermôfbylding, lykas alle folgjende ferlykbere, is makke net mei native Kubernetes-ark, mar mei it Tufin Orca-ark, dat is ûntwikkele troch it bedriuw fan de skriuwer fan it orizjinele artikel en dat wurdt neamd oan 'e ein fan it materiaal.)

Om jo eigen netwurkbelied te definiearjen, sille jo basiskennis fan YAML nedich wêze. Dizze taal is basearre op ynspringen (oantsjutte troch spaasjes ynstee fan ljeppers). In ynspringe elemint heart by it tichtst ynkeard elemint dêrboppe. In nij list elemint begjint mei in koppelteken, alle oare eleminten hawwe de foarm kaai-wearde.

Nei it beskriuwen fan it belied yn YAML, brûke kubectlom it yn it kluster te meitsjen:

kubectl create -f policy.yaml

Netwurk Policy Specification

De spesifikaasje fan Kubernetes netwurkbelied omfettet fjouwer eleminten:

1. podSelector: definiearret de pods beynfloede troch dit belied (doelen) - fereaske;
2. policyTypes: jout oan hokker soarten belied dêryn opnommen binne: yn- en/of útgong - opsjoneel, mar ik advisearje it yn alle gefallen eksplisyt oan te jaan;
3. ingress: definiearret tastien ynkommende ferkear nei doelpods - opsjoneel;
4. egress: definiearret tastien útgeande ferkear fan doelpods is opsjoneel.

Foarbyld nommen fan 'e webside fan Kubernetes (ik ferfong role op app), lit sjen hoe't alle fjouwer eleminten wurde brûkt:

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

Tink derom dat alle fjouwer eleminten net moatte wurde opnommen. It is allinnich ferplichte podSelector, kinne oare parameters brûkt wurde as winske.

As wy wegerje policyTypes, sil it belied as folget wurde ynterpretearre:

• Standert wurdt oannommen dat it de yngongside definiearret. As yn it belied dat net eksplisyt stiet, giet it systeem derfan út dat alle ferkear ferbean is.
• It gedrach oan 'e útgongskant sil wurde bepaald troch de oanwêzigens of ôfwêzigens fan' e oerienkommende útgongsparameter.

Om flaters te foarkommen advisearje ik meitsje it altyd eksplisyt policyTypes.

Neffens de boppesteande logika, as de parameters ingress en / of egress weilitten, sil it belied alle ferkear wegerje (sjoch "Stripregel" hjirûnder).

Standert belied is Tastean

As der gjin belied is definiearre, lit Kubernetes standert alle ferkear ta. Alle podden kinne frij ûnderling ynformaasje útwikselje. Dit kin tsjinoer yntuïtyf lykje út in feiligensperspektyf, mar tink derom dat Kubernetes oarspronklik waard ûntworpen troch ûntwikkelders om applikaasje ynteroperabiliteit mooglik te meitsjen. Netwurkbelied waard letter tafoege.

Nammeromten

Nammeromten binne it Kubernetes-gearwurkingsmeganisme. Se binne ûntworpen om logyske omjouwings fan elkoar te isolearjen, wylst kommunikaasje tusken romten standert tastien is.

Lykas de measte Kubernetes-komponinten, libje netwurkbelied yn in spesifike nammeromte. Yn it blok metadata jo kinne oanjaan hokker romte it belied heart by:

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

As de nammeromte net eksplisyt oantsjutte is yn de metadata, sil it systeem de nammeromte brûke opjûn yn kubectl (standert namespace=default):

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

ik advisearje spesifisearje nammeromte eksplisyt, útsein as jo in belied skriuwe dat op meardere nammeromten tagelyk rjochtet.

Main elemint podSelector yn it belied sil selektearje pods út de nammeromte dêr't it belied heart (it wurdt wegere tagong ta pods út in oare nammeromte).

Lykwols, podSelectors yn yn- en útgongsblokken kin allinnich selektearje pods út harren eigen nammeromte, útsein as jo fansels kombinearje se mei namespaceSelector (dit sil besprutsen wurde yn 'e seksje "Filterearje op nammeromten en pods").

Belied Namme regels

Beliedsnammen binne unyk binnen deselde nammeromte. Der kinne net twa belied mei deselde namme yn deselde romte, mar der kin wêze belied mei deselde namme yn ferskillende romten. Dit is handich as jo itselde belied opnij wolle tapasse oer meardere romten.

Ik hâld benammen fan ien fan 'e nammemetoaden. It bestiet út it kombinearjen fan de nammeromte mei de doelpods. Bygelyks:

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

Labels

Jo kinne oanpaste labels heakje oan Kubernetes-objekten, lykas pods en nammeromten. Labels (kaartsjes - tags) binne it ekwivalint fan tags yn 'e wolk. Kubernetes netwurkbelied brûke labels om te selektearjen poddestuollenwêrop se jilde:

podSelector:
  matchLabels:
    role: db

… of nammeromtendêr't se fan oanfreegje. Dit foarbyld selekteart alle pods yn nammeromten mei de oerienkommende labels:

namespaceSelector:
  matchLabels:
    project: myproject

Ien warskôging: by it brûken namespaceSelector soargje derfoar dat de nammeromten dy't jo selektearje it juste label befetsje. Wês bewust dat ynboude nammeromten lykas default и kube-system, befetsje standert gjin labels.

Jo kinne in label tafoegje oan in romte lykas dit:

kubectl label namespace default namespace=default

Tagelyk, nammeromte yn 'e seksje metadata moat ferwize nei de eigentlike romtenamme, net it label:

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

Boarne en bestimming

Firewall-belied bestiet út regels mei boarnen en bestimmingen. Kubernetes netwurk belied wurdt definiearre foar in doel - in set fan pods dêr't se fan tapassing - en dan set regels foar yngong en / of útgong ferkear. Yn ús foarbyld sil it doel fan it belied alle pods yn 'e nammeromte wêze default mei label mei kaai app en betsjutting 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

Underdiel ingress yn dit belied, iepenet ynkommende ferkear nei de doelpods. Mei oare wurden, yngong is de boarne en doel is de oerienkommende bestimming. Likemin is egress de bestimming en doel is de boarne.

Dit is lykweardich oan twa firewall regels: Ingress → Doel; Doel → Egress.

Egress en DNS (wichtich!)

Troch it beheinen fan útgeand ferkear, spesjaal omtinken jaan oan DNS - Kubernetes brûkt dizze tsjinst om tsjinsten yn kaart te bringen nei IP-adressen. Bygelyks, it folgjende belied sil net wurkje om't jo de applikaasje net hawwe tastien balance tagong ta 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

Jo kinne it reparearje troch tagong te iepenjen nei de DNS-tsjinst:

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

Lêste elemint to is leech, en dêrom selektearret it yndirekt alle pods yn alle nammeromten, talitte balance stjoer DNS-fragen nei de passende Kubernetes-tsjinst (meastentiids rint yn 'e romte kube-system).

Dizze oanpak wurket, lykwols te permissive en ûnfeilich, om't it mooglik makket dat DNS-fragen bûten it kluster rjochte wurde.

Jo kinne it ferbetterje yn trije opienfolgjende stappen.

1. Allinne DNS-fragen tastean binnen kluster troch tafoegjen 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. Allinne DNS-fragen tastean binnen nammeromte kube-system.

Om dit te dwaan moatte jo in label tafoegje oan de nammeromte kube-system: kubectl label namespace kube-system namespace=kube-system - en skriuw it op yn belied mei help 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. Paranoïde minsken kinne noch fierder gean en DNS-fragen beheine ta in spesifike DNS-tsjinst yn kube-system. De seksje "Filterearje op nammeromten EN pods" sil jo fertelle hoe't jo dit berikke.

In oare opsje is om DNS op it nammeromtenivo op te lossen. Yn dit gefal hoecht it net te iepenjen foar elke tsjinst:

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

Leech podSelector selektearje alle pods yn de nammeromte.

Earste wedstriid en regel folchoarder

Yn konvinsjonele firewalls wurdt de aksje (Tastean of wegerje) op in pakket bepaald troch de earste regel dy't it foldocht. Yn Kubernetes makket de folchoarder fan belied net út.

Standert, as der gjin belied ynsteld is, binne kommunikaasje tusken pods tastien en kinne se frij ynformaasje útwikselje. Sadree't jo begjinne te formulearjen belied, elke pod beynfloede troch op syn minst ien fan harren wurdt isolearre neffens de disjunction (logyske OR) fan al it belied dat selekteare. Pods dy't net beynfloede binne troch belied bliuwe iepen.

Jo kinne dit gedrach feroarje mei in stripregel.

Stripregel ("ôfwize")

Firewall-belied wegerje typysk elk ferkear dat net eksplisyt tastien is.

Der is gjin ûntkenning aksje yn Kubernetes, lykwols, in ferlykber effekt kin berikt wurde mei in reguliere (permissive) belied troch it selektearjen fan in lege groep boarne pods (yngong):

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

Dit belied selekteart alle pods yn 'e nammeromte en lit yngong ûndefinieare, wêrtroch alle ynkommende ferkear wegere wurdt.

Op in fergelykbere manier kinne jo alle útgeande ferkear fan in nammeromte beheine:

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

Tink derom dat elk ekstra belied dat ferkear tastiet nei pods yn 'e nammeromte sil foarrang krije boppe dizze regel (fergelykber mei it tafoegjen fan in tastean regel foar in wegerje regel yn in firewall konfiguraasje).

Alles tastean (Any-Any-Any-Allow)

Om in Allow All-belied te meitsjen, moatte jo it Deny-belied hjirboppe oanfolje mei in leech elemint ingress:

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

It jout tagong fan alle pods yn alle nammeromten (en alle IP) nei elke pod yn de nammeromte default. Dit gedrach is standert ynskeakele, dus it hoecht normaal net fierder te definieare. Soms moatte jo lykwols wat spesifike tagongsrjochten tydlik útskeakelje om it probleem te diagnostearjen.

De regel kin beheind wurde om allinnich tagong ta in spesifike set fan pods (app:balance) yn de nammeromte default:

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

It folgjende belied lit alle yn- en útgongsferkear ta, ynklusyf tagong ta elke IP bûten it kluster:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

Kombinearje Meardere Policies

Belieden wurde kombinearre mei logyske OR op trije nivo's; De tagongsrjochten fan elke pod binne ynsteld yn oerienstimming mei de disjunksje fan alle belied dy't it beynfloedzje:

1. Yn 'e fjilden from и to Trije soarten eleminten kinne wurde definiearre (allegear wurde kombinearre mei OR):

• namespaceSelector - selektearje de folsleine nammeromte;
• podSelector - selektearje pods;
• ipBlock - selektearje in subnet.

Boppedat, it oantal eleminten (sels identike) yn subseksjes from/to net beheind. Allegear sille wurde kombinearre troch logyske OR.

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. Binnen it belied seksje ingress kin in protte eleminten hawwe from (kombinearre troch logyske OR). Lykwols, seksje egress kin in protte eleminten befetsje to (ek kombinearre troch disjunction):

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. Ferskillende belied wurde ek kombinearre mei logyske OR

Mar as se kombinearje, is d'r ien beheining op hokker wiisde op Chris Cooney: Kubernetes kin allinnich kombinearje belied mei ferskillende policyTypes (Ingress of Egress). Belieden dy't ingress (of egress) definiearje, sille inoar oerskriuwe.

Relaasje tusken nammeromten

Standert is it dielen fan ynformaasje tusken nammeromten tastien. Dit kin wizige wurde troch in wegeringsbelied te brûken dat útgeande en/of ynkommende ferkear yn de nammeromte beheine (sjoch "Stripregel" hjirboppe).

Sadree't jo tagong ta in nammeromte blokkearre hawwe (sjoch de "Stripregel" hjirboppe), kinne jo útsûnderingen meitsje op it wegerjen fan belied troch ferbiningen fan in spesifike nammeromte ta te stean mei 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

As gefolch, alle pods yn de nammeromte default sil tagong hawwe ta pods postgres yn nammeromte database. Mar wat as jo tagong wolle iepenje ta postgres allinnich spesifike pods yn de nammeromte default?

Filterje op nammeromten en pods

Kubernetes ferzje 1.11 en heger kinne jo kombinearje operators namespaceSelector и podSelector mei logyske EN. It sjocht der sa út:

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

Wêrom wurdt dit ynterpretearre as EN ynstee fan de gewoane OR?

notysje dat podSelector begjint net mei in koppelteken. Yn YAML betsjut dit dat podSelector en stean foar him namespaceSelector ferwize nei itselde list elemint. Dêrom wurde se kombinearre mei logyske EN.

It tafoegjen fan in koppelteken foar podSelector sil resultearje yn it ûntstean fan in nij list elemint, dat wurdt kombinearre mei de foarige namespaceSelector mei help fan logyske OR.

Om pods te selektearjen mei in spesifyk label yn alle nammeromten, enter blank 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

Meardere labels wurkje gear mei I

Regels foar in brânmuorre mei meardere objekten (hosts, netwurken, groepen) wurde kombinearre mei logyske OR. De folgjende regel sil wurkje as de pakketboarne oerienkomt Host_1 Or Host_2:

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

Krektoarsom, yn Kubernetes de ferskate labels yn podSelector of namespaceSelector wurde kombinearre mei logyske EN. De folgjende regel sil bygelyks pods selektearje dy't beide labels hawwe, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Deselde logika jildt foar alle soarten operators: beliedsdoelselektors, podselektors en nammeromteselektors.

Subnetten en IP-adressen (IPBlocks)

Firewalls brûke VLAN's, IP-adressen en subnetten om in netwurk te segmentearjen.

Yn Kubernetes wurde IP-adressen automatysk oan pods tawiisd en kinne faak feroarje, sadat labels wurde brûkt om pods en nammeromten te selektearjen yn netwurkbelied.

Subnetten (ipBlocks) wurde brûkt by it behearen fan ynkommende (ynkommende) of útgeande (útgeande) eksterne (Noard-Súd) ferbiningen. Dit belied iepenet bygelyks foar alle pods út de nammeromte default tagong ta Google DNS-tsjinst:

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

De lege podselektor yn dit foarbyld betsjut "selektearje alle pods yn 'e nammeromte."

Dit belied jout allinnich tagong ta 8.8.8.8; tagong ta elke oare IP is ferbean. Dat, yn essinsje, hawwe jo tagong blokkearre ta de ynterne Kubernetes DNS-tsjinst. As jo ​​it noch iepenje wolle, geef dit dan eksplisyt oan.

meastentiids ipBlocks и podSelectors binne ûnderling eksklusyf, om't de ynterne IP-adressen fan pods net brûkt wurde yn ipBlocks. Troch oan te jaan ynterne IP pods, jo sille feitlik ferbinings nei/fan pods mei dizze adressen tastean. Yn 'e praktyk sille jo net witte hokker IP-adres jo moatte brûke, en dêrom moatte se net brûkt wurde om pods te selektearjen.

As tsjinfoarbyld omfettet it folgjende belied alle IP's en jout dêrom tagong ta alle oare pods:

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

Jo kinne tagong allinich iepenje foar eksterne IP's, útsein de ynterne IP-adressen fan pods. Bygelyks, as it subnet fan jo pod 10.16.0.0/14 is:

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

Havens en protokollen

Typysk harkje pods nei ien haven. Dit betsjut dat jo gewoan gjin poartenûmers kinne opjaan yn belied en alles as standert litte. It is lykwols oan te rieden om belied sa beheinend mooglik te meitsjen, sadat jo yn guon gefallen noch havens kinne opjaan:

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

Tink derom dat de selector ports jildt foar alle eleminten yn it blok to of from, dy't befettet. Om ferskillende havens oan te jaan foar ferskate sets fan eleminten, splitst ingress of egress yn ferskate subseksjes mei to of from en yn elk register jo havens:

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

Standert haven operaasje:

• As jo ​​de poartedefinysje folslein weilitte (ports), dit betsjut alle protokollen en alle havens;
• As jo ​​de protokoldefinysje weilitte (protocol), dit betsjut TCP;
• As jo ​​de poarte definysje weilitte (port), dit betsjut alle havens.

Bêste praktyk: Fertrouwe net op standertwearden, spesifisearje wat jo eksplisyt nedich binne.

Tink derom dat jo pod-poarten moatte brûke, net tsjinsthavens (mear oer dit yn 'e folgjende paragraaf).

Binne belied definiearre foar pods of tsjinsten?

Typysk hawwe pods yn Kubernetes inoar tagong fia in tsjinst - in firtuele loadbalancer dy't ferkear omliedt nei de pods dy't de tsjinst ymplementearje. Jo kinne tinke dat netwurkbelied tagong ta tsjinsten kontrolearret, mar dit is net it gefal. Kubernetes netwurkbelied wurket op pod-poarten, net tsjinsthavens.

Bygelyks, as in tsjinst harket nei poarte 80, mar omliedt ferkear nei poarte 8080 fan syn pods, moatte jo presys 8080 opjaan yn it netwurkbelied.

Sa'n meganisme moat as suboptimaal beskôge wurde: as de ynterne struktuer fan 'e tsjinst (de havens wêrfan pods harkje) feroaret, sil it netwurkbelied bywurke wurde moatte.

Nije arsjitektoanyske oanpak mei Service Mesh (Sjoch bygelyks oer Istio hjirûnder - sawat oerset.) kinne jo omgean mei dit probleem.

Is it nedich om sawol Ingress as Egress te registrearjen?

It koarte antwurd is ja, om pod A te kommunisearjen mei pod B, moat it tastien wêze om in útgeande ferbining te meitsjen (dêrfoar moatte jo in útgongsbelied konfigurearje), en pod B moat in ynkommende ferbining kinne akseptearje ( dêrfoar hawwe jo dus in yngongsbelied nedich).

Yn 'e praktyk kinne jo lykwols fertrouwe op it standertbelied om ferbiningen yn ien of beide rjochtingen te tastean.

As guon pod-boarne sil wurde selektearre troch ien of mear útkomst-politisy, de beheinings dy't oplein wurde, wurde bepaald troch har disjunction. Yn dit gefal moatte jo ferbining mei de pod eksplisyt tastean -adressearre. As in pod net selektearre is troch in belied, is it útgeande (útgean) ferkear standert tastien.

Likegoed is it lot fan 'e podadressearre, selektearre troch ien of mear ingress-politisy, sil wurde bepaald troch harren disjunction. Yn dit gefal moatte jo it eksplisyt tastean om ferkear te ûntfangen fan 'e boarne pod. As in pod net selektearre is troch in belied, is alle ynkommende ferkear dêrfoar standert tastien.

Sjoch Stateful of Stateless hjirûnder.

Logs

Kubernetes netwurk belied kin net oanmelde ferkear. Dit makket it lestich om te bepalen oft in belied wurket as bedoeld en makket de befeiligingsanalyse in soad komplisearre.

Kontrôle fan ferkear nei eksterne tsjinsten

Kubernetes netwurkbelied lit jo net in folslein kwalifisearre domeinnamme (DNS) opjaan yn útgongsseksjes. Dit feit liedt ta signifikante oerlêst by it besykjen om ferkear te beheinen nei eksterne bestimmingen dy't gjin fêst IP-adres hawwe (lykas aws.com).

Belied Check

Firewalls sille jo warskôgje of sels wegerje it ferkearde belied te akseptearjen. Kubernetes docht ek wat ferifikaasje. By it ynstellen fan in netwurkbelied fia kubectl, kin Kubernetes ferklearje dat it ferkeard is en wegerje it te akseptearjen. Yn oare gefallen sil Kubernetes it belied nimme en it ynfolje mei de ûntbrekkende details. Se kinne sjoen wurde mei it kommando:

kubernetes get networkpolicy <policy-name> -o yaml

Hâld der rekken mei dat it Kubernetes-validaasjesysteem net ûnfeilber is en guon soarten flaters misse kin.

Utfiering

Kubernetes ymplemintearret sels gjin netwurkbelied, mar is gewoan in API-poarte dy't de lêst fan kontrôle delegearret oan in ûnderlizzend systeem neamd de Container Networking Interface (CNI). It ynstellen fan belied op in Kubernetes-kluster sûnder it tawizen fan de passende CNI is itselde as it meitsjen fan belied op in firewallbeheartsjinner sûnder se dan te ynstallearjen op firewalls. It is oan jo om te soargjen dat jo in fatsoenlike CNI hawwe of, yn it gefal fan Kubernetes-platfoarms, hosted yn 'e wolk (jo kinne de list mei providers sjen hjir — ca. trans.), ynskeakelje netwurk belied dat sil ynstelle CNI foar dy.

Tink derom dat Kubernetes jo net warskôgje sil as jo in netwurkbelied ynstelle sûnder de passende helper CNI.

Steateleas of Steateleas?

Alle Kubernetes CNIs Ik haw tsjinkaam binne stateful (Bygelyks, Calico brûkt Linux conntrack). Hjirmei kin de pod antwurden ûntfange op 'e TCP-ferbining dy't it is inisjearre sûnder it opnij te meitsjen. Ik bin my lykwols net bewust fan in Kubernetes-standert dy't statefulness garandearje soe.

Avansearre Feiligensbelied Management

Hjir binne wat manieren om hanthavenjen fan feiligensbelied yn Kubernetes te ferbetterjen:

1. It Service Mesh-arsjitektoanysk patroan brûkt sidecar-konteners om detaillearre telemetry en ferkearskontrôle te leverjen op it tsjinstnivo. As foarbyld kinne wy ​​nimme Istio.
2. Guon fan 'e CNI-leveransiers hawwe har ark útwreide om fierder te gean as Kubernetes netwurkbelied.
3. Tufin Orca Biedt sichtberens en automatisearring fan Kubernetes netwurkbelied.

It Tufin Orca-pakket beheart Kubernetes netwurkbelied (en is de boarne fan 'e skermôfbyldings hjirboppe).

oanfoljende ynformaasje

• Foarbylden fan netwurkbelied taret troch Ahmet Alp Balkan fan GKE;
• Dokumintaasje fan 'e offisjele Kubernetes-webside;
• In gids foar it Kubernetes Networking Model;
• Skript foar it kontrolearjen fan netwurkbelied.

konklúzje

Kubernetes netwurkbelied biedt in goede set ark foar it segmentearjen fan klusters, mar se binne net yntuïtyf en hawwe in protte subtiliteiten. Fanwegen dizze kompleksiteit leau ik dat in protte besteande klusterbelied buggy binne. Mooglike oplossingen foar dit probleem omfetsje it automatisearjen fan beliedsdefinysjes of it brûken fan oare segmenteringsark.

Ik hoopje dat dizze hantlieding helpt wat fragen op te heljen en problemen op te lossen dy't jo kinne tsjinkomme.

PS fan oersetter

Lês ek op ús blog:

• "Werom nei mikrotsjinsten mei Istio": diel 1 (ynlieding ta de haadfunksjes), diel 2 (routing, ferkearskontrôle), diel 3 (feiligens);
• "In yllustrearre gids foar netwurken yn Kubernetes": dielen 1 en 2 (netwurkmodel, overlay netwurken), diel 3 (tsjinsten en ferkearsferwurking);
• «Docker en Kubernetes yn feiligensgefoelige omjouwings";
• «9 Kubernetes Feiligens Best Practices";
• «11 manieren om (net) in slachtoffer te wurden fan in Kubernetes-hack".

Boarne: www.habr.com