Eng Aféierung zu Kubernetes Netzwierkpolitike fir Sécherheetsprofesser

Note. iwwersat.: Den Auteur vum Artikel, Reuven Harrison, huet iwwer 20 Joer Erfahrung an der Softwareentwécklung, an haut ass den CTO a Matgrënner vun Tufin, eng Firma déi Sécherheetspolitik Management Léisunge erstellt. Iwwerdeems hien Kubernetes Reseau Politik als zimlech mächteg Outil fir Reseau Segmentatioun an engem Cluster gesinn, gleeft hien och, datt se net sou einfach sinn an der Praxis ëmzesetzen. Dëst Material (zimmlech voluminös) soll d'Sensibiliséierung vun de Spezialisten iwwer dëst Thema verbesseren an hinnen hëllefen déi néideg Konfiguratiounen ze kreéieren.

Haut wielen vill Firmen ëmmer méi Kubernetes fir hir Uwendungen auszeféieren. D'Interesse an dëser Software ass sou héich datt e puer Kubernetes "den neie Betribssystem fir den Datenzenter" nennen. No an no fänken Kubernetes (oder k8s) als kriteschen Deel vum Geschäft unzefänken, wat d'Organisatioun vu reife Geschäftsprozesser erfuerdert, inklusiv Netzwierksécherheet.

Fir Sécherheetsfachleit déi iwwerrascht sinn andeems se mat Kubernetes schaffen, kann déi richteg Offenbarung d'Standardpolitik vun der Plattform sinn: alles erlaabt.

Dëse Guide hëlleft Dir d'intern Struktur vun Reseau Politiken verstoen; verstoen wéi se vun de Regele fir normal Firewalls ënnerscheeden. Et wäert och e puer Fallen ofdecken a Empfehlungen ubidden fir Applikatiounen op Kubernetes ze sécheren.

Kubernetes Reseau Politiken

De Kubernetes Netzpolitik Mechanismus erlaabt Iech d'Interaktioun vun Uwendungen ze verwalten, déi op der Plattform op der Netzwierkschicht ofgebaut ginn (déi drëtt am OSI Modell). Netzpolitike feelen e puer vun de fortgeschratt Feature vu modernen Firewalls, sou wéi OSI Layer 7 Duerchféierung a Bedrohungserkennung, awer si bidden e Basisniveau vun der Netzsécherheet déi e gudde Startpunkt ass.

Reseau Politik Kontroll Kommunikatioun tëscht pods

Workloads a Kubernetes ginn iwwer Pods verdeelt, déi aus engem oder méi Container besteet, déi zesummen agesat ginn. Kubernetes gëtt all Pod eng IP Adress zou, déi vun anere Pods zougänglech ass. Kubernetes Netzpolitike setzen Zougangsrechter fir Gruppe vu Pods op déiselwecht Manéier wéi Sécherheetsgruppen an der Wollek benotzt gi fir Zougang zu virtuelle Maschinninstanzen ze kontrolléieren.

Definéieren Reseau Politiken

Wéi aner Kubernetes Ressourcen, sinn Netzwierkpolitiken an YAML spezifizéiert. Am Beispill hei ënnen ass d'Applikatioun balance Zougang zu 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

(Note. iwwersat.: Dëse Screenshot, wéi all spéider ähnlechen, gouf erstallt net mat nativen Kubernetes Tools, awer mat dem Tufin Orca Tool, dat vun der Firma vum Auteur vum Originalartikel entwéckelt gouf an deen um Enn vum Material ernimmt gëtt.)

Fir Är eege Reseau Politik ze definéieren, braucht Dir Basis Kenntnisser vun YAML. Dës Sprooch baséiert op Indentatioun (spezifizéiert vu Raum anstatt Tabs). En indentéierten Element gehéiert zum nooste indentéierten Element uewendriwwer. En neit Lëschtelement fänkt mat engem Bindestrich un, all aner Elementer hunn d'Form Schlëssel-Wäert.

Nodeems Dir d'Politik an YAML beschriwwen hutt, benotzt kubectlfir et am Cluster ze kreéieren:

kubectl create -f policy.yaml

Reseau Politik Spezifizéierung

D'Kubernetes Netzwierkpolitik Spezifikatioun enthält véier Elementer:

1. podSelector: definéiert d'Pods, déi vun dëser Politik betraff sinn (Ziler) - erfuerderlech;
2. policyTypes: weist wéi eng Zorte vu Politiken an dësem abegraff sinn: Ingress an/oder Egress - fakultativ, awer ech recommandéieren et an alle Fäll explizit ze spezifizéieren;
3. ingress: definéiert erlaabt erakommen Traffic op Zilpods - fakultativ;
4. egress: definéiert erlaabt erausginn Traffic vun Zilpods ass fakultativ.

Beispill geholl vun der Kubernetes Websäit (ech ersat role op app), weist wéi all véier Elementer benotzt ginn:

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

Maacht weg datt all véier Elementer net mat abegraff sinn. Et ass nëmmen obligatoresch podSelector, aner Parameteren kënnen wéi gewënscht benotzt ginn.

Wann Dir loosst policyTypes, gëtt d'Politik wéi follegt interpretéiert:

• Par défaut gëtt ugeholl datt et d'Ingress Säit definéiert. Wann d'Politik dëst net explizit seet, wäert de System dovun ausgoen datt all Verkéier verbueden ass.
• D'Verhalen op der Ausgangssäit gëtt duerch d'Präsenz oder d'Feele vum entspriechende Ausgangsparameter bestëmmt.

Fir Feeler ze vermeiden ech recommandéieren maachen et ëmmer explizit policyTypes.

No der uewen Logik, wann d'Parameteren ingress an / oder egress ausgelooss, wäert d'Politik all Traffic ofleenen (kuckt "Strippregel" hei ënnen).

Standardpolitik ass Erlaabt

Wa keng Politiken definéiert sinn, erlaabt Kubernetes all Traffic als Standard. All Pods kënne fräi Informatioun ënner sech austauschen. Dëst kann aus enger Sécherheetsperspektiv kontraintuitiv schéngen, awer erënnert drun datt Kubernetes ursprénglech vun Entwéckler entworf gouf fir Applikatioun Interoperabilitéit z'erméiglechen. Reseau Politiken goufen spéider dobäi.

Nummraim

Namespaces sinn de Kubernetes Zesummenaarbecht Mechanismus. Si sinn entwéckelt fir logesch Ëmfeld vuneneen ze isoléieren, während d'Kommunikatioun tëscht de Raum als Standard erlaabt ass.

Wéi déi meescht Kubernetes Komponenten, liewen Netzwierkpolitiken an engem spezifesche Nummraum. Am Block metadata Dir kënnt uginn zu wéi engem Raum d'Politik gehéiert:

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

Wann den Nummraum net explizit an de Metadaten spezifizéiert ass, benotzt de System den Nummraum, deen am kubectl spezifizéiert ass (par défaut namespace=default):

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

ech recommandéieren Nummraum explizit uginn, ausser Dir schreift eng Politik déi méi Nummraim gläichzäiteg zielt.

Den Haaptset Element podSelector an der Politik wäert Pods aus dem Nummraum auswielen, zu deem d'Politik gehéiert (et gëtt Zougang zu Pods aus engem aneren Nummraum verweigert).

Ähnlech, podSelectors an Ingress- an Ausgangsblocken kann nëmmen Pods aus hirem eegene Nummraum auswielen, ausser Dir selbstverständlech kombinéiere mat namespaceSelector (dëst gëtt an der Rubrik "Filteren no Nummraim a Pods" diskutéiert).

Politik Benennung Regelen

Politik Nimm sinn eenzegaarteg am selwechte Nummraum. Et kënnen net zwou Politiken mam selwechten Numm am selwechte Raum sinn, awer et kann Politik mam selwechten Numm a verschiddene Raum sinn. Dëst ass nëtzlech wann Dir déiselwecht Politik iwwer verschidde Plazen nei ëmsetzen wëllt.

Ech hu besonnesch gär eng vun den Nummmethoden. Et besteet aus der Kombinatioun vum Nummraumnumm mat den Zilpods. Zum Beispill:

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

Etiketten

Dir kënnt personaliséiert Etiketten un Kubernetes Objete befestigen, wéi Pods an Nummraim. Etiketten (Etiketten - Tags) sinn d'Äquivalent vun Tags an der Wollek. Kubernetes Reseau Politik benotzt Etiketten ze wielen podsop déi se gëllen:

podSelector:
  matchLabels:
    role: db

… oder Nummraimop déi se zoutreffen. Dëst Beispill wielt all Pods an Nummraim mat den entspriechende Etiketten:

namespaceSelector:
  matchLabels:
    project: myproject

Eng Opgepasst: wann Dir benotzt namespaceSelector vergewëssert Iech datt d'Nummraim déi Dir gewielt hutt de richtege Label enthalen. Sidd bewosst datt agebaute Nummraim wéi z default и kube-system, Par défaut enthalen keng Etiketten.

Dir kënnt e Label op e Raum wéi dëst addéieren:

kubectl label namespace default namespace=default

Zur selwechter Zäit, Nummraum an der Rubrik metadata sollt op den aktuellen Raumnumm bezéien, net de Label:

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

Quell an Destinatioun

Firewall Politiken besteet aus Regele mat Quellen an Destinatiounen. Kubernetes Reseau Politiken sinn fir en Zil definéiert - eng Rei vu Pods op déi se gëllen - an dann Regele fir Ingress an / oder egress Verkéier festgeluecht. An eisem Beispill wäert d'Zil vun der Politik all Pods am Nummraum sinn default mat Label mat Schlëssel app a Bedeitung 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

Ënnersektioun ingress an dëser Politik, mécht Entréeën Traffic op d'Zil Pods. An anere Wierder, Ingress ass d'Quell an Zil ass déi entspriechend Destinatioun. Och Auswee ass d'Destinatioun an d'Zil ass seng Quell.

Dëst entsprécht zwee Firewall Regelen: Ingress → Target; Zil → Egress.

Egress an DNS (wichteg!)

Andeems Dir den Ausgaende Verkéier limitéiert, besonnesch Opmierksamkeet op DNS bezuelen - Kubernetes benotzt dëse Service fir Servicer op IP Adressen ze mapen. Zum Beispill, déi folgend Politik funktionnéiert net well Dir d'Applikatioun net erlaabt hutt balance Zougang 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

Dir kënnt et fixéieren andeems Dir den Zougang zum DNS Service opmaacht:

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

Lescht Element to ass eidel, an dofir wielt se indirekt all Pods an all Nummraim, erlaabt balance DNS Ufroen un de passenden Kubernetes Service schécken (normalerweis am Raum lafen kube-system).

Dës Approche funktionnéiert awer zevill permissiv an onsécher, well et erlaabt DNS Ufroen ausserhalb vum Cluster ze riichten.

Dir kënnt et an dräi successive Schrëtt verbesseren.

1. Erlaabt nëmmen DNS Ufroen innerhalb Cluster andeems Dir derbäigesat 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. Erlaabt nëmmen DNS Ufroen am Nummraum kube-system.

Fir dëst ze maachen, musst Dir e Label an den Nummraum addéieren kube-system: kubectl label namespace kube-system namespace=kube-system - a schreift et an der Politik benotzt 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. Paranoid Leit kënnen nach méi wäit goen an DNS Ufroen op e spezifeschen DNS Service limitéieren kube-system. D'Sektioun "Filteren no Nummraim AN Pods" wäert Iech soen wéi Dir dëst erreecht.

Eng aner Optioun ass DNS um Nummraumniveau ze léisen. An dësem Fall muss et net fir all Service opgemaach ginn:

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

Eidel podSelector wielt all Pods am Nummraum.

Éischte Match an Regel Uerdnung

A konventionelle Firewalls gëtt d'Aktioun (Erlaabt oder Verleegnen) op engem Paket vun der éischter Regel festgeluegt, déi et entsprécht. A Kubernetes ass d'Uerdnung vun de Politiken egal.

Par défaut, wa keng Politik gesat gëtt, ass Kommunikatioun tëscht Pods erlaabt a si kënne fräi Informatioun austauschen. Wann Dir ufänkt Politiken ze formuléieren, gëtt all Pod, dee vun op d'mannst ee vun hinnen betraff ass, isoléiert no der Disjunktioun (logesch ODER) vun all de Politiken déi se ausgewielt hunn. Pods, déi net vun enger Politik betraff sinn, bleiwen op.

Dir kënnt dëst Verhalen mat enger Strippregel änneren.

Stripping Regel ("Verleegnen")

Firewall Politiken refuséieren typesch all Traffic deen net explizit erlaabt ass.

Et gëtt keng Oflehnung Aktioun zu KubernetesWéi och ëmmer, en ähnlechen Effekt kann mat enger regulärer (permissiver) Politik erreecht ginn andeems Dir eng eidel Grupp vu Quellpods auswielt (Ingress):

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

Dës Politik wielt all Pods am Nummraum a léisst d'Entrée ondefinéiert, a refuséiert all erakommen Traffic.

Op eng ähnlech Manéier kënnt Dir all erausginn Traffic aus engem Nummraum beschränken:

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

Maacht weg all zousätzlech Politik, déi de Verkéier op Pods am Nummraum erlaabt, wäert Virrang iwwer dës Regel hunn (Ähnlech wéi eng Erlaabnes-Regel bäizefügen ier eng Reegelregel an enger Firewall-Konfiguratioun).

Erlaabt alles (Any-Any-Any-Allow)

Fir eng Allow All Politik ze kreéieren, musst Dir d'Deny Politik uewen mat engem eidelen Element ergänzen ingress:

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

Et erlaabt Zougang vun all Pods an all Nummraim (an all IP) op all Pod am Nummraum default. Dëst Verhalen ass als Standard aktivéiert, sou datt et normalerweis net weider definéiert muss ginn. Wéi och ëmmer, heiansdo musst Dir e puer spezifesch Permissiounen temporär auszeschalten fir de Problem ze diagnostizéieren.

D'Regel kann schmuel ginn Zougang nëmmen ze erlaben e spezifesche Set vu Pods (app:balance) am Nummraum default:

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

Déi folgend Politik erlaabt all Ingress an Egress Traffic, inklusiv Zougang zu all IP ausserhalb vum Cluster:

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

Kombinéiert Multiple Politiken

Politik sinn kombinéiert mat logesch ODER op dräi Niveauen; D'Permissioune vun all Pod ginn am Aklang mat der Disjunctioun vun all Politiken festgeluecht, déi et beaflossen:

1. An de Felder from и to Dräi Aarte vun Elementer kënnen definéiert ginn (déi all kombinéiert mat ODER):

• namespaceSelector - wielt de ganze Nummraum;
• podSelector - wielt Pods;
• ipBlock - wielt e Subnet.

Ausserdeem ass d'Zuel vun den Elementer (och identesch) an Ënnersektiounen from/to net limitéiert. All vun hinnen wäert duerch logesch ODER kombinéiert ginn.

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. Bannen der Politik Rubrik ingress kann vill Elementer hunn from (kombinéiert mat logeschen ODER). Ähnlech, Sektioun egress kann vill Elementer enthalen to (och duerch Disjunktioun kombinéiert):

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. Verschidde Politik sinn och mat logesch ODER kombinéiert

Awer wann Dir se kombinéiert, gëtt et eng Begrenzung op déi uginn Chris Cooney: Kubernetes kann nëmmen Politik mat verschiddene kombinéieren policyTypes (Ingress oder Egress). Politiken déi Ingress (oder Egress) definéieren, iwwerschreiwe géigesäiteg.

Relatioun tëscht Nummraim

Par défaut ass d'Informatiounsdeelung tëscht Nummraim erlaabt. Dëst kann geännert ginn andeems Dir eng Oflehnungspolitik benotzt, déi den Traffic ausginn an/oder erakommen an den Nummraum beschränkt (kuckt "Stripping Regel" uewen).

Wann Dir den Zougang zu engem Nummraum gespaart hutt (kuckt d'"Stripping Regel" hei uewen), kënnt Dir Ausnahmen zu der Oflehnungspolitik maachen andeems Dir Verbindunge vun engem spezifesche Nummraum erlaabt benotzt 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

Als Resultat sinn all Pods am Nummraum default wäert Zougang zu Pods hunn postgres am Nummraum database. Awer wat wann Dir wëllt Zougang zu opmaachen postgres nëmmen spezifesch Pods am Nummraum default?

Filter no Nummraim a Pods

Kubernetes Versioun 1.11 a méi héich erlaabt Iech Betreiber ze kombinéieren namespaceSelector и podSelector mat logeschen AN.Et gesäit esou aus:

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

Firwat gëtt dëst als AN interpretéiert amplaz vum üblechen ODER?

notéiert dat podSelector fänkt net mat engem Bindestrich un. Am YAML heescht dat podSelector a steet virun him namespaceSelector bezitt sech op datselwecht Lëschtelement. Dofir gi se mat logeschen AN kombinéiert.

Füügt en Bindestrich virun podSelector wäert am Entstoe vun engem neie Lëscht Element Resultat, déi mat der viregter kombinéiert ginn namespaceSelector benotzt logesch ODER.

Fir Pods mat engem spezifesche Label ze wielen an all Nummraim, gitt eidel 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

Multiple Etiketten schaffe mat I

Regele fir eng Firewall mat méi Objeten (Hosten, Netzwierker, Gruppen) gi kombinéiert mat logeschen ODER. Déi folgend Regel funktionnéiert wann d'Päckquell entsprécht Host_1 Or Host_2:

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

Am Géigendeel, zu Kubernetes déi verschidde Etiketten an podSelector oder namespaceSelector si mat logeschen AN kombinéiert. Zum Beispill wäert déi folgend Regel Pods auswielen déi béid Etiketten hunn, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Déi selwecht Logik gëlt fir all Zorte vu Betreiber: Politikzielselektoren, Podselektoren an Nummraumselektoren.

Subnets an IP Adressen (IPBlocks)

Firewalls benotzen VLANs, IP Adressen, an Subnets fir en Netzwierk ze segmentéieren.

A Kubernetes ginn IP Adressen automatesch u Pods zougewisen a kënnen dacks änneren, sou datt Etiketten benotzt gi fir Pods an Nummraim an Netzwierkpolitiken ze wielen.

Subnets (ipBlocks) gi benotzt wann Dir Entréeën (Ingress) oder erausginn (Egress) extern (Nord-Süd) Verbindungen verwalten. Zum Beispill mécht dës Politik fir all Pods aus dem Nummraum op default Zougang zum Google DNS Service:

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

Den eidele Pod Selector an dësem Beispill heescht "wielt all Pods am Nummraum."

Dës Politik erlaabt nëmmen Zougang zu 8.8.8.8; Zougang zu all aner IP ass verbueden. Also, am Wesentlechen, hutt Dir den Zougang zum internen Kubernetes DNS Service blockéiert. Wann Dir et nach wëllt opmaachen, gitt dat explizit un.

normalerweis ipBlocks и podSelectors sinn géigesäiteg exklusiv, well déi intern IP Adresse vu Pods net benotzt ginn ipBlocks. Andeems Dir uginn intern IP Pods, Dir wäert tatsächlech Verbindunge mat/vun Pods mat dësen Adressen erlaben. An der Praxis wësst Dir net wéi eng IP Adress ze benotzen, dofir sollten se net benotzt ginn fir Pods ze wielen.

Als Géigebeispill enthält déi folgend Politik all IPen an erlaabt dofir Zougang zu all aner 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

Dir kënnt Zougang nëmmen op extern IPs opmaachen, ausser déi intern IP Adresse vu Pods. Zum Beispill, wann Äre Pod säi Subnet 10.16.0.0/14 ass:

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

Häfen a Protokoller

Typesch Pods lauschteren op engem Hafen. Dëst bedeit datt Dir einfach keng Portnummeren an der Politik spezifizéiere kënnt an alles als Standard léisst. Wéi och ëmmer, et ass recommandéiert d'Politik esou restriktiv wéi méiglech ze maachen, sou datt Dir an e puer Fäll nach ëmmer Ports spezifizéiere kënnt:

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

Bedenkt datt de selector ports gëllt fir all Elementer am Block to oder from, déi enthält. Fir verschidden Häfen fir verschidde Sets vun Elementer ze spezifizéieren, opzedeelen ingress oder egress an e puer Ënnersektiounen mat to oder from an an all registréiert Är Häfen:

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

Standard Port Operatioun:

• Wann Dir d'Portdefinitioun komplett ausléisst (ports), dat heescht all Protokoller an all Häfen;
• Wann Dir d'Protokolldefinitioun ausléisst (protocol), dat heescht TCP;
• Wann Dir d'Portdefinitioun ausléisst (port), dat heescht all Häfen.

Bescht Praxis: Vertrau net op Standardwäerter, spezifizéiert wat Dir explizit braucht.

Maacht weg datt Dir Pod Ports benotze musst, net Service Ports (méi iwwer dëst am nächste Paragraph).

Sinn Politik fir Pods oder Servicer definéiert?

Typesch kréien Pods a Kubernetes sech duerch e Service zougänglech - e virtuelle Lastbalancer deen den Traffic op d'Pods viruleet, déi de Service ëmsetzen. Dir mengt vläicht datt d'Netzpolitik den Zougang zu de Servicer kontrolléiert, awer dëst ass net de Fall. Kubernetes Netzwierkpolitik funktionnéiert op Pod Ports, net Service Ports.

Zum Beispill, wann e Service op den Hafen 80 lauschtert, awer de Verkéier op den Hafen 8080 vu senge Pods ëmgeleet, musst Dir genau 8080 an der Netzpolitik spezifizéieren.

Sou e Mechanismus sollt als suboptimal ugesi ginn: wann d'intern Struktur vum Service (d'Ports vun deenen Pods lauschteren) ännert, muss d'Netzpolitik aktualiséiert ginn.

Nei architektonesch Approche mat Service Mesh (zum Beispill, kuckt iwwer Istio hei ënnen - ongeféier Iwwersetzung) erlaabt Iech mat dësem Problem eens.

Ass et néideg souwuel Ingress an Egress ze registréieren?

Déi kuerz Äntwert ass jo, fir datt de Pod A mam Pod B kommunizéiere kann, muss et erlaabt sinn eng erausgaang Verbindung ze kreéieren (fir dëst musst Dir eng Ausgangspolitik konfiguréieren), an de Pod B muss eng erakommen Verbindung akzeptéieren ( fir dës, deementspriechend, Dir braucht eng Ingress Politik).

Wéi och ëmmer, an der Praxis kënnt Dir op d'Standardpolitik vertrauen fir Verbindungen an eng oder zwou Richtungen z'erméiglechen.

Wann e puer Pod-Quell gëtt vun engem oder méi ausgewielt ginn Ausgang-Politiker, d'Restriktiounen, déi et opgesat ginn, ginn duerch hir Disjunktioun bestëmmt. An dësem Fall musst Dir explizit d'Verbindung mam Pod erlaben -adresséiert. Wann e Pod net vun enger Politik ausgewielt gëtt, ass säin ausgaangenen (Egress) Traffic als Standard erlaabt.

Ähnlech ass d'Schicksal vum Podadresséiert, ausgewielt vun engem oder méi erakommen-Politiker, gëtt duerch hir Disjunction bestëmmt. An dësem Fall musst Dir et explizit erlaben de Traffic vum Quellpod ze kréien. Wann e Pod net vun enger Politik ausgewielt gëtt, ass all Ingressverkéier dofir als Standard erlaabt.

Gesinn Stateful oder Stateless ënnert.

Logbicher

Kubernetes Reseau Politik kann Traffic net aloggen. Dëst mécht et schwéier ze bestëmmen ob eng Politik funktionnéiert wéi virgesinn a komplizéiert d'Sécherheetsanalyse staark.

Kontroll vum Verkéier op extern Servicer

Kubernetes Reseau Politiken erlaben Iech net e voll qualifizéiert Domain Numm (DNS) an egress Rubriken ze uginn. Dës Tatsaach féiert zu bedeitend Onbequemlechkeet wann Dir probéiert de Traffic op extern Destinatiounen ze beschränken déi keng fix IP Adress hunn (wéi aws.com).

Politik Check

Firewalls wäerten Iech warnen oder souguer refuséieren déi falsch Politik ze akzeptéieren. Kubernetes mécht och e puer Verifizéierung. Wann Dir eng Netzwierkpolitik duerch kubectl setzt, kann Kubernetes deklaréieren datt et falsch ass a refuséieren se ze akzeptéieren. An anere Fäll wäert Kubernetes d'Politik huelen an se mat de fehlenden Detailer ausfëllen. Si kënne mat dem Kommando gesi ginn:

kubernetes get networkpolicy <policy-name> -o yaml

Denkt drun datt de Kubernetes Validatiounssystem net onfehlbar ass a vläicht e puer Aarte vu Feeler verpassen.

Ausféierung

Kubernetes implementéiert keng Netzwierkpolitik selwer, awer ass just en API Paart deen d'Belaaschtung vun der Kontroll un en ënnerierdesche System delegéiert de Container Networking Interface (CNI) genannt. D'Politik op engem Kubernetes-Cluster setzen ouni de passenden CNI ze zouzeweisen ass d'selwecht wéi d'Politik op engem Firewall Management Server ze kreéieren ouni se dann op Firewalls z'installéieren. Et ass un Iech fir sécherzestellen datt Dir en anstännege CNI hutt oder, am Fall vu Kubernetes Plattformen, an der Wollek gehost (Dir kënnt d'Lëscht vun den Ubidder gesinn hei — ca. trans.), aktivéiert Reseau Politik datt CNI fir Iech setzen.

Bedenkt datt Kubernetes Iech net warnen wann Dir eng Netzpolitik setzt ouni de passenden Helfer CNI.

Staatlech oder Staatslos?

All Kubernetes CNIs ech begéint sinn statesch (Zum Beispill, Calico benotzt Linux conntrack). Dëst erlaabt de Pod Äntwerten op der TCP Verbindung ze kréien déi se initiéiert huet ouni se nei opzebauen. Wéi och ëmmer, ech sinn net bewosst vun engem Kubernetes Standard deen Statefulness garantéiert.

Fortgeschratt Sécherheetspolitik Management

Hei sinn e puer Weeër fir d'Sécherheetspolitik Duerchféierung a Kubernetes ze verbesseren:

1. De Service Mesh architektonescht Muster benotzt Sidecar Container fir detailléiert Telemetrie a Verkéierskontroll um Serviceniveau ze bidden. Als Beispill kënne mir huelen Istio.
2. E puer vun den CNI Ubidder hunn hir Tools verlängert fir iwwer d'Kubernetes Netzwierkpolitik ze goen.
3. Tufin Orca Bitt Visibilitéit an Automatiséierung vu Kubernetes Netzwierkpolitiken.

Den Tufin Orca Package geréiert Kubernetes Netzwierkpolitik (an ass d'Quell vun den Screenshots hei uewen).

zousätzlech Informatioune

• Beispiller vun Reseau Politik virbereet vum Ahmet Alp Balkan aus GKE;
• Dokumentatioun vun der offizieller Kubernetes Websäit;
• E Guide zum Kubernetes Networking Model;
• Skript fir d'Netzpolitik ze kontrolléieren.

Konklusioun

Kubernetes Netzwierkpolitik bitt e gudde Set vun Tools fir Cluster ze segmentéieren, awer si sinn net intuitiv an hu vill Subtletien. Wéinst dëser Komplexitéit gleewen ech datt vill existent Clusterpolitike buggy sinn. Méiglech Léisunge fir dëse Problem enthalen d'Automatiséierung vun der Politikdefinitioun oder d'Benotzung vun anere Segmentéierungsinstrumenter.

Ech hoffen dëse Guide hëlleft e puer Froen ze klären an Themen ze léisen déi Dir kënnt stousse.

PS vum Iwwersetzer

Liest och op eisem Blog:

• "Zréck op Mikroservicer mat Istio": Deel 1 (Aféierung an d'Haaptmerkmale), Deel 2 (Routing, Verkéierskontroll), Deel 3 (Sécherheet);
• "En Illustréierte Guide fir Netzwierker a Kubernetes": Deeler 1 an 2 (Netzmodell, Overlay Netzwierker), Deel 3 (Servicer a Verkéiersveraarbechtung);
• «Docker a Kubernetes a Sécherheetsempfindlech Ëmfeld";
• «9 Beschte Praktiken fir Kubernetes Sécherheet";
• «11 Weeër fir (net) Affer vun engem Kubernetes Hack ze ginn".

Source: will.com