🥇Enkonduko al Kubernetes-Retaj Politikoj por Sekurecaj Profesiuloj

Notu. transl.: La aŭtoro de la artikolo, Reuven Harrison, havas pli ol 20 jarojn da sperto en programaro, kaj hodiaŭ estas la CTO kaj kunfondinto de Tufin, firmao kiu kreas sekurecpolitikajn administradsolvojn. Dum li rigardas Kubernetes-retajn politikojn kiel sufiĉe potencan ilon por retsegmentado en areto, li ankaŭ kredas, ke ili ne estas tiel facile uzeblaj en la praktiko. Ĉi tiu materialo (sufiĉe ampleksa) celas plibonigi la konscion de specialistoj pri ĉi tiu afero kaj helpi ilin krei la necesajn agordojn.

Hodiaŭ, multaj kompanioj ĉiam pli elektas Kubernetes por funkciigi siajn aplikojn. Intereso pri ĉi tiu programaro estas tiel alta ke iuj nomas Kubernetes "la nova operaciumo por la datumcentro." Iom post iom, Kubernetes (aŭ k8s) komencas esti perceptita kiel kritika parto de la komerco, kiu postulas la organizon de maturaj komercaj procezoj, inkluzive de reto-sekureco.

Por sekurecaj profesiuloj, kiuj konfuziĝas pro laborado kun Kubernetes, la vera revelacio eble estas la defaŭlta politiko de la platformo: permesu ĉion.

Ĉi tiu gvidilo helpos vin kompreni la internan strukturon de retaj politikoj; kompreni kiel ili diferencas de la reguloj por regulaj fajroŝirmiloj. Ĝi ankaŭ kovros kelkajn malfacilaĵojn kaj provizos rekomendojn por helpi sekurigi aplikojn en Kubernetes.

Kubernetes-retaj politikoj

La reta politika mekanismo de Kubernetes permesas al vi administri la interagadon de aplikoj deplojitaj sur la platformo ĉe la retotavolo (la tria en la OSI-modelo). Retaj politikoj mankas iuj el la altnivelaj funkcioj de modernaj fajroŝirmiloj, kiel ekzemple OSI Layer 7-devigo kaj minaco-detekto, sed ili disponigas bazan nivelon de retsekureco kiu estas bona deirpunkto.

Retaj politikoj kontrolas komunikadojn inter podoj

Laborŝarĝoj en Kubernetes estas distribuitaj tra podoj, kiuj konsistas el unu aŭ pluraj ujoj deplojitaj kune. Kubernetes asignas al ĉiu pod IP-adreson alirebla de aliaj podoj. Kubernetes-retaj politikoj starigas alirrajtojn por grupoj de podoj same kiel sekurecaj grupoj en la nubo estas uzataj por kontroli aliron al virtualaj maŝinaj petskriboj.

Difinante Retajn Politikojn

Kiel aliaj rimedoj de Kubernetes, retaj politikoj estas specifitaj en YAML. En la suba ekzemplo, la aplikaĵo balance aliro al 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

(Notu. transl.: ĉi tiu ekrankopio, kiel ĉiuj postaj similaj, estis kreita ne per denaskaj Kubernetes-iloj, sed per la ilo Tufin Orca, kiu estis evoluigita de la firmao de la aŭtoro de la originala artikolo kaj kiu estas menciita ĉe la fino de la materialo.)

Por difini vian propran retan politikon, vi bezonos bazan scion pri YAML. Ĉi tiu lingvo baziĝas sur deŝovo (specifita per spacoj prefere ol per langetoj). Indentita elemento apartenas al la plej proksima indentelemento super ĝi. Nova listelemento komenciĝas per streketo, ĉiuj aliaj elementoj havas la formon ŝlosilvaloro.

Priskribinte la politikon en YAML, uzu kubectlpor krei ĝin en la areto:

kubectl create -f policy.yaml

Specifo pri Reto-Politiko

La specifo pri reto de Kubernetes inkluzivas kvar elementojn:

podSelector: difinas la podojn trafitaj de ĉi tiu politiko (celoj) - bezonata;
policyTypes: indikas kiajn politikojn estas inkluzivitaj en ĉi tio: eniro kaj/aŭ eliro - nedeviga, sed mi rekomendas eksplicite specifi ĝin en ĉiuj kazoj;
ingress: difinas permesita eniranta traffic to target pods - nedeviga;
egress: difinas permesita eksiĝinta trafiko de celaj podoj estas laŭvola.

Ekzemplo prenita el la retejo de Kubernetes (mi anstataŭigis role sur app), montras kiel ĉiuj kvar elementoj estas uzitaj:

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

Bonvolu noti, ke ĉiuj kvar elementoj ne devas esti inkluzivitaj. Ĝi estas nur deviga podSelector, aliaj parametroj povas esti uzataj laŭdezire.

Se vi preterlasas policyTypes, la politiko estos interpretita jene:

Defaŭlte, oni supozas, ke ĝi difinas la enirflankon. Se la politiko ne eksplicite deklaras tion, la sistemo supozos, ke ĉiu trafiko estas malpermesita.
La konduto ĉe la elirflanko estos determinita de la ĉeesto aŭ foresto de la responda elirparametro.

Por eviti erarojn mi rekomendas ĉiam eksplicitu ĝin policyTypes.

Laŭ la supra logiko, se la parametroj ingress kaj / aŭ egress preterlasita, la politiko malkonfesos ĉian trafikon (vidu "Regulo pri Senigo" malsupre).

Defaŭlta politiko estas Permesi

Se neniuj politikoj estas difinitaj, Kubernetes permesas la tutan trafikon defaŭlte. Ĉiuj balgoj povas libere interŝanĝi informojn inter si. Ĉi tio povas ŝajni kontraŭintuicia de sekureca perspektivo, sed memoru, ke Kubernetes estis origine desegnita de programistoj por ebligi aplikaĵkunfunkcieblecon. Retaj politikoj estis aldonitaj poste.

Nomspacoj

Nomspacoj estas la kunlabora mekanismo de Kubernetes. Ili estas dizajnitaj por izoli logikajn mediojn unu de la alia, dum komunikado inter spacoj estas permesita defaŭlte.

Kiel plej multaj Kubernetes-komponentoj, retaj politikoj vivas en specifa nomspaco. En la bloko metadata vi povas specifi al kiu spaco apartenas la politiko:

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

Se la nomspaco ne estas eksplicite specifita en la metadatenoj, la sistemo uzos la nomspacon specifitan en kubectl (defaŭlte namespace=default):

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

mi rekomendas specifi nomspacon eksplicite, krom se vi verkas politikon, kiu celas plurajn nomspacojn samtempe.

Ĉefa elemento podSelector en la politiko elektos podojn el la nomspaco al kiu apartenas la politiko (ĝi estas rifuzita aliro al podoj de alia nomspaco).

Simile, podSelectors en enir- kaj elirblokoj povas nur elekti podojn el sia propra nomspaco, krom se vi kompreneble kombinas ilin namespaceSelector (ĉi tio estos diskutita en la sekcio "Filtri per nomspacoj kaj podoj").

Reguloj pri Nomado de Politiko

Politiknomoj estas unikaj ene de la sama nomspaco. Ne povas esti du politikoj kun la sama nomo en la sama spaco, sed povas esti politikoj kun la sama nomo en malsamaj spacoj. Ĉi tio estas utila kiam vi volas reapliki la saman politikon tra pluraj spacoj.

Mi precipe ŝatas unu el la nommetodoj. Ĝi konsistas el kombinado de la nomspaca nomo kun la celaj balgoj. Ekzemple:

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

Etikedoj

Vi povas alfiksi kutimajn etikedojn al Kubernetes-objektoj, kiel podoj kaj nomspacoj. Etikedoj (etiketoj - etikedoj) estas la ekvivalento de etikedoj en la nubo. Kubernetes-retaj politikoj uzas etikedojn por elekti balgojal kiu ili aplikas:

podSelector:
  matchLabels:
    role: db

… aŭ nomspacojal kiu ili aplikas. Ĉi tiu ekzemplo elektas ĉiujn podojn en nomspacoj kun la respondaj etikedoj:

namespaceSelector:
  matchLabels:
    project: myproject

Unu singardo: kiam vi uzas namespaceSelector certigu, ke la nomspacoj kiujn vi elektas enhavas la ĝustan etikedon. Konsciu, ke enkonstruitaj nomspacoj kiel ekz default и kube-system, defaŭlte ne enhavas etikedojn.

Vi povas aldoni etikedon al spaco tia:

kubectl label namespace default namespace=default

Samtempe, nomspaco en la sekcio metadata devus rilati al la fakta spacnomo, ne la etikedo:

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

Fonto kaj celo

Firewall-politikoj konsistas el reguloj kun fontoj kaj cellokoj. Kubernetes-retaj politikoj estas difinitaj por celo - aro de podoj al kiuj ili aplikas - kaj poste starigas regulojn por eniro kaj/aŭ elira trafiko. En nia ekzemplo, la celo de la politiko estos ĉiuj balgoj en la nomspaco default kun etikedo kun ŝlosilo app kaj signifo 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

Subsekcio ingress en ĉi tiu politiko, malfermas envenantan trafikon al la celaj podoj. Alivorte, eniro estas la fonto kaj celo estas la responda celloko. Same, eliro estas la celo kaj celo estas ĝia fonto.

Ĉi tio estas ekvivalenta al du fajroŝirmilaj reguloj: Eniro → Celo; Celo → Eliro.

Eliro kaj DNS (grava!)

Limigante elirantan trafikon, atentu specialan al DNS - Kubernetes uzas ĉi tiun servon por mapi servojn al IP-adresoj. Ekzemple, la sekva politiko ne funkcios ĉar vi ne permesis la aplikaĵon balance aliri 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

Vi povas ripari ĝin malfermante aliron al la DNS-servo:

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

Lasta elemento to estas malplena, kaj tial ĝi nerekte elektas ĉiuj podoj en ĉiuj nomspacoj, permesante balance sendu DNS-demandojn al la taŭga Kubernetes-servo (kutime funkcianta en la spaco kube-system).

Ĉi tiu aliro funkcias, tamen ĝi tro cedema kaj nesekura, ĉar ĝi permesas DNS-demandojn esti direktitaj ekster la areto.

Vi povas plibonigi ĝin en tri sinsekvaj paŝoj.

1. Permesu DNS-demandojn nur interne grapolo per aldonado 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. Permesu DNS-demandojn nur ene de nomspaco kube-system.

Por fari tion vi devas aldoni etikedon al la nomspaco kube-system: kubectl label namespace kube-system namespace=kube-system - kaj skribu ĝin en politiko uzante 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. Paranojaj homoj povas iri eĉ plu kaj limigi DNS-demandojn al specifa DNS-servo en kube-system. La sekcio "Filtri per nomspacoj KAJ pods" diros al vi kiel atingi tion.

Alia opcio estas solvi DNS ĉe la nomspaco. En ĉi tiu kazo, ĝi ne bezonos esti malfermita por ĉiu servo:

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

Malplena podSelector elektas ĉiujn podojn en la nomspaco.

Unua matĉo kaj regulordo

En konvenciaj fajroŝirmiloj, la ago (Permesi aŭ Negi) sur pakaĵeto estas determinita per la unua regulo kiun ĝi kontentigas. En Kubernetes, la ordo de politikoj ne gravas.

Defaŭlte, kiam neniuj politikoj estas fiksitaj, komunikadoj inter podoj estas permesitaj kaj ili povas libere interŝanĝi informojn. Post kiam vi komencas formuli politikojn, ĉiu pod trafita de almenaŭ unu el ili iĝas izolita laŭ la disjunkcio (logika AŬ) de ĉiuj politikoj kiuj elektis ĝin. Pods ne tuŝitaj de iu politiko restas malfermitaj.

Vi povas ŝanĝi ĉi tiun konduton uzante nudregulon.

Regulo de nudiĝo ("Nei")

Fajrmurpolitikoj tipe neas ajnan trafikon kiu ne estas eksplicite permesita.

Ne estas neagado en Kubernetes, tamen, simila efiko povas esti atingita kun regula (permesema) politiko elektante malplenan grupon de fontpodoj (eniro):

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

Ĉi tiu politiko elektas ĉiujn podojn en la nomspaco kaj lasas eniron nedifinita, neante ĉian envenantan trafikon.

Simile, vi povas limigi la tutan elirantan trafikon de nomspaco:

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

Bonvolu noti tion iuj aldonaj politikoj permesantaj trafikon al podoj en la nomspaco havos prioritaton super ĉi tiu regulo (simila al aldonado de permesi regulo antaŭ rifuza regulo en fajroŝirmilo).

Permesu ĉion (Ajn-Ajn-Ajn-Allow)

Por krei politikon Permesi Ĉion, vi devas kompletigi la supran Neigi politikon per malplena elemento ingress:

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

Ĝi permesas aliron de ĉiuj podoj en ĉiuj nomspacoj (kaj ĉiuj IP) al iu ajn pod en la nomspaco default. Ĉi tiu konduto estas ebligita defaŭlte, do ĝi kutime ne bezonas esti difinita plu. Tamen, foje vi eble bezonos provizore malŝalti iujn specifajn permesojn por diagnozi la problemon.

La regulo povas esti malvastigita por permesi aliron nur al specifa aro de balgoj (app:balance) en la nomspaco default:

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

La sekva politiko permesas ĉiun eniron kaj eliron, inkluzive de aliro al iu IP ekster la areto:

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

Kombinante Multoblaj Politikoj

Politikoj estas kombinitaj uzante logikan AŬ sur tri niveloj; La permesoj de ĉiu pod estas agordita laŭ la disiĝo de ĉiuj politikoj kiuj influas ĝin:

1. En la kampoj from и to Tri specoj de elementoj povas esti difinitaj (ĉiuj el kiuj estas kombinitaj uzante AŬ):

namespaceSelector — elektas la tutan nomspacon;
podSelector — elektas gusojn;
ipBlock — elektas subreton.

Krome, la nombro da elementoj (eĉ identaj) en subsekcioj from/to ne limigita. Ĉiuj ili estos kombinitaj per logika AŬ.

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. Ene de la politika sekcio ingress povas havi multajn elementojn from (kombinita per logika AŬ). Simile, sekcio egress povas inkluzivi multajn elementojn to (ankaŭ kombinita per disjunkcio):

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. Malsamaj politikoj ankaŭ estas kombinitaj kun logika AŬ

Sed kiam ili kombinas, estas unu limigo pri kiu atentigis Chris Cooney: Kubernetes nur povas kombini politikojn kun malsamaj policyTypes (Ingress aŭ Egress). Politikoj difinantaj eniron (aŭ eliron) anstataŭigos unu la alian.

Rilato inter nomspacoj

Defaŭlte, informoj kundivido inter nomspacoj estas permesita. Ĉi tio povas esti ŝanĝita uzante politikon de rifuzo, kiu limigos trafikon elirantan kaj/aŭ envenantan en la nomspacon (vidu "Regulo de Senigo" supre).

Post kiam vi blokis aliron al nomspaco (vidu la "Strip Regulon" supre), vi povas fari esceptojn al la nea politiko permesante konektojn de specifa nomspaco uzante 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

Kiel rezulto, ĉiuj podoj en la nomspaco default havos aliron al podoj postgres en nomspaco database. Sed kio se vi volas malfermi aliron al postgres nur specifaj podoj en la nomspaco default?

Filtru laŭ nomspacoj kaj podoj

Kubernetes versio 1.11 kaj pli alta permesas vin kombini funkciigistojn namespaceSelector и podSelector uzante logikan AND. Ĝi aspektas jene:

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

Kial ĉi tio estas interpretata kiel KAJ anstataŭ la kutima AŬ?

notu tion podSelector ne komenciĝas per streketo. En YAML tio signifas tion podSelector kaj starante antaŭ li namespaceSelector raportu al la sama listelemento. Tial, ili estas kombinitaj kun logika KAJ.

Aldonante streketon antaŭe podSelector rezultos en la apero de nova listelemento, kiu estos kombinita kun la antaŭa namespaceSelector uzante logikan AŬ.

Elekti podojn kun specifa etikedo en ĉiuj nomspacoj, enigu malplenan 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

Multoblaj etikedoj formas teamon kun I

Reguloj por fajroŝirmilo kun pluraj objektoj (gastigantoj, retoj, grupoj) estas kombinitaj uzante logikan AŬ. La sekva regulo funkcios se la paka fonto kongruas Host_1 Aŭ Host_2:

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

Male, en Kubernetes la diversaj etikedoj en podSelector aŭ namespaceSelector estas kombinitaj kun logika AND. Ekzemple, la sekva regulo elektos podojn kiuj havas ambaŭ etikedojn, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

La sama logiko validas por ĉiuj specoj de funkciigistoj: politikaj celelektiloj, podselektiloj, kaj nomspacelektiloj.

Subretoj kaj IP-adresoj (IPBlocks)

Fajromuroj uzas VLANojn, IP-adresojn kaj subretojn por segmenti reton.

En Kubernetes, IP-adresoj estas asignitaj al podoj aŭtomate kaj povas ŝanĝiĝi ofte, do etikedoj estas uzataj por elekti podojn kaj nomspacojn en retaj politikoj.

Subretoj (ipBlocks) estas uzataj dum administrado de enirantaj (eniro) aŭ elirantaj (eliro) eksteraj (Norda-Suda) konektoj. Ekzemple, ĉi tiu politiko malfermiĝas al ĉiuj podoj de la nomspaco default aliro al Google DNS-servo:

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

La malplena podselektilo en ĉi tiu ekzemplo signifas "elektu ĉiujn podojn en la nomspaco."

Ĉi tiu politiko nur permesas aliron al 8.8.8.8; aliro al iu ajn alia IP estas malpermesita. Do, esence, vi blokis aliron al la interna Kubernetes DNS-servo. Se vi ankoraŭ volas malfermi ĝin, indiku tion eksplicite.

Kutime ipBlocks и podSelectors estas reciproke ekskluzivaj, ĉar la internaj IP-adresoj de podoj ne estas uzataj ipBlocks. Per indikado internaj IP-podoj, vi efektive permesos konektojn al/de podoj kun ĉi tiuj adresoj. En la praktiko, vi ne scios kiun IP-adreson uzi, tial ili ne devus esti uzataj por elekti podojn.

Kiel kontraŭekzemplo, la sekva politiko inkluzivas ĉiujn IP-ojn kaj tial permesas aliron al ĉiuj aliaj podoj:

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

Vi povas malfermi aliron nur al eksteraj IP-oj, krom la internaj IP-adresoj de podoj. Ekzemple, se la subreto de via pod estas 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

Havenoj kaj protokoloj

Tipe balgoj aŭskultas al unu haveno. Ĉi tio signifas, ke vi simple ne povas specifi havennumerojn en politikoj kaj lasi ĉion defaŭlte. Tamen, oni rekomendas fari politikojn kiel eble plej restriktajn, do en iuj kazoj vi ankoraŭ povas specifi pordojn:

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

Notu ke la elektilo ports validas por ĉiuj elementoj en la bloko to aŭ from, kiu enhavas. Por specifi malsamajn havenojn por malsamaj aroj de elementoj, disigu ingress aŭ egress en plurajn subfakojn kun to aŭ from kaj en ĉiu registri viajn havenojn:

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

Defaŭlta havenoperacio:

Se vi tute preterlasas la havendifinon (ports), ĉi tio signifas ĉiujn protokolojn kaj ĉiujn havenojn;
Se vi preterlasas la protokolan difinon (protocol), ĉi tio signifas TCP;
Se vi preterlasas la havendifinon (port), ĉi tio signifas ĉiujn havenojn.

Plej bona praktiko: Ne fidu defaŭltajn valorojn, specifu tion, kion vi bezonas eksplicite.

Bonvolu noti, ke vi devas uzi pod-havenojn, ne servajn havenojn (pli pri tio en la sekva alineo).

Ĉu politikoj estas difinitaj por podoj aŭ servoj?

Tipe, podoj en Kubernetes aliras unu la alian per servo - virtuala ŝarĝbalancilo, kiu redirektas trafikon al la podoj kiuj efektivigas la servon. Vi povus pensi, ke retaj politikoj kontrolas aliron al servoj, sed ĉi tio ne estas la kazo. Kubernetes-retaj politikoj funkcias sur pod-havenoj, ne servaj havenoj.

Ekzemple, se servo aŭskultas al haveno 80, sed alidirektas trafikon al haveno 8080 de ĝiaj podoj, vi devas specifi ekzakte 8080 en la retopolitiko.

Tia mekanismo devus esti konsiderata suboptimuma: se la interna strukturo de la servo (kies havenoj aŭskultas podoj) ŝanĝiĝas, retaj politikoj devos esti ĝisdatigitaj.

Nova arkitektura aliro uzante Service Mesh (ekzemple, vidu pri Istio malsupre - ĉ. trad.) permesas vin trakti ĉi tiun problemon.

Ĉu necesas registri kaj Eniro kaj Eliro?

La mallonga respondo estas jes, por ke pod A komunikiĝu kun pod B, ĝi devas esti permesita krei elirkonekton (por tio vi devas agordi elirpolitikon), kaj pod B devas povi akcepti envenantan konekton ( por tio, sekve, vi bezonas enirpolitikon).politiko).

Tamen, praktike, vi povas fidi la defaŭltan politikon por permesi konektojn en unu aŭ ambaŭ direktoj.

Se iu pod-fonto estos elektita de unu aŭ pli eliro-politikistoj, la limigoj truditaj al ĝi estos determinitaj de ilia disjunkcio. En ĉi tiu kazo, vi devos eksplicite permesi konekton al la pod -adresato. Se podo ne estas elektita de iu politiko, ĝia elira (eliro) trafiko estas permesita defaŭlte.

Simile, la sorto de la balgo estasadresato, elektita de unu aŭ pli eniro-politikistoj, estos determinita de ilia disjunkcio. En ĉi tiu kazo, vi devas eksplicite permesi al ĝi ricevi trafikon de la fontpodo. Se podo ne estas elektita de iu politiko, ĉiuj enirtrafiko por ĝi estas permesita defaŭlte.

Vidu Ŝtata aŭ Sennacia malsupre.

Ŝtipoj

Kubernetes-retaj politikoj ne povas registri trafikon. Ĉi tio malfaciligas determini ĉu politiko funkcias kiel celite kaj tre malfaciligas sekurecan analizon.

Kontrolo de trafiko al eksteraj servoj

Kubernetes-retaj politikoj ne permesas al vi specifi plene kvalifikitan domajnan nomon (DNS) en elirsekcioj. Ĉi tiu fakto kondukas al grava ĝeno kiam oni provas limigi trafikon al eksteraj cellokoj, kiuj ne havas fiksan IP-adreson (kiel ekzemple aws.com).

Politika Kontrolo

Fajromuroj avertos vin aŭ eĉ rifuzos akcepti la malĝustan politikon. Kubernetes ankaŭ faras iun konfirmon. Kiam fiksas retan politikon per kubectl, Kubernetes povas deklari, ke ĝi estas malĝusta kaj rifuzi akcepti ĝin. En aliaj kazoj, Kubernetes prenos la politikon kaj plenigos ĝin per la mankantaj detaloj. Ili povas esti viditaj uzante la komandon:

kubernetes get networkpolicy <policy-name> -o yaml

Memoru, ke la valida sistemo de Kubernetes ne estas senerara kaj eble mankas iuj specoj de eraroj.

Ekzekuto

Kubernetes ne efektivigas retajn politikojn mem, sed estas nur API-enirejo, kiu delegas la ŝarĝon de kontrolo al subesta sistemo nomata Container Networking Interface (CNI). Agordi politikojn sur Kubernetes-areo sen atribui la taŭgan CNI estas la sama kiel krei politikojn sur fajroŝirmila administra servilo sen tiam instali ilin sur fajroŝirmiloj. Dependas de vi certigi, ke vi havas decan CNI aŭ, en la kazo de Kubernetes-platformoj, gastigita en la nubo. (vi povas vidi la liston de provizantoj tie — ĉ. trad.), ebligu retajn politikojn, kiuj starigos CNI por vi.

Notu, ke Kubernetes ne avertos vin se vi fiksas retan politikon sen la taŭga helpanto CNI.

Ŝtata aŭ Sennacia?

Ĉiuj Kubernetes CNI-oj kiujn mi renkontis estas ŝtataj (ekzemple, Calico uzas Linuksan kontrokon). Tio permesas al la balgo ricevi respondojn sur la TCP-konekto kiun ĝi iniciatas sen devi reestabli ĝin. Tamen mi ne konscias pri Kubernetes-normo, kiu garantius staton.

Altnivela Sekureca Politika Administrado

Jen kelkaj manieroj plibonigi sekurecan politikon en Kubernetes:

La arkitektura ŝablono Service Mesh uzas kromĉarujojn por disponigi detalan telemetrion kaj trafikkontrolon ĉe la serva nivelo. Kiel ekzemplon ni povas preni Istio.
Kelkaj el la CNI-vendistoj etendis siajn ilojn por iri preter Kubernetes-retaj politikoj.
Tufina Orko Provizas videblecon kaj aŭtomatigon de retaj politikoj de Kubernetes.

La pako Tufin Orca administras retajn politikojn de Kubernetes (kaj estas la fonto de la supraj ekrankopioj).

aldona informo

konkludo

Kubernetes-retaj politikoj ofertas bonan aron da iloj por segmenti aretojn, sed ili ne estas intuiciaj kaj havas multajn subtilaĵojn. Pro ĉi tiu komplekseco, mi kredas ke multaj ekzistantaj clusterpolitikoj estas fuŝaj. Eblaj solvoj al ĉi tiu problemo inkluzivas aŭtomatigi politikajn difinojn aŭ uzi aliajn segmentigajn ilojn.

Mi esperas, ke ĉi tiu gvidilo helpos klarigi kelkajn demandojn kaj solvi problemojn, kiujn vi eble renkontos.

PS de tradukisto

Legu ankaŭ en nia blogo:

"Reen al mikroservoj kun Istio": parto 1 (enkonduko al la ĉefaj trajtoj), parto 2 (vojigo, trafikkontrolo), parto 3 (sekureco);
"Ilustrita Gvidilo pri Retoj en Kubernetes": partoj 1 kaj 2 (retmodelo, tegmentaj retoj), parto 3 (servoj kaj trafika prilaborado);
«Docker kaj Kubernetes en sekurec-sentemaj medioj»;
«9 Plej bonaj Praktikoj pri Sekureco de Kubernetes»;
«11 Manieroj (Ne) Fariĝi Viktimo de Kubernetes Hako".

fonto: www.habr.com

Enkonduko al Kubernetes Retaj Politikoj por Sekurecaj Profesiuloj