Bevezetés a Kubernetes hálózati irányelveibe biztonsági szakembereknek

Jegyzet. ford.: A cikk szerzője, Reuven Harrison több mint 20 éves szoftverfejlesztési tapasztalattal rendelkezik, ma pedig a Tufin, a biztonságpolitikai menedzsment megoldásokat készítő cég CTO-ja és társalapítója. Miközben a Kubernetes hálózati irányelveit meglehetősen hatékony eszköznek tekinti a fürtök hálózati szegmentálására, azt is hiszi, hogy a gyakorlatban nem olyan egyszerű őket megvalósítani. Ennek az anyagnak (meglehetősen terjedelmes) célja, hogy javítsa a szakemberek tudatosságát ebben a kérdésben, és segítse őket a szükséges konfigurációk elkészítésében.

Manapság sok vállalat egyre gyakrabban választja a Kubernetes alkalmazását. A szoftver iránt olyan nagy az érdeklődés, hogy egyesek a Kuberneteset „az adatközpont új operációs rendszerének” nevezik. Fokozatosan a Kubernetes (vagy k8s) az üzlet kritikus részeként fog felfogni, ami kiforrott üzleti folyamatok megszervezését igényli, beleértve a hálózatbiztonságot is.

A Kubernetes-szel való együttműködést zavarba ejtő biztonsági szakemberek számára az igazi kinyilatkoztatás a platform alapértelmezett irányelve lehet: mindent engedélyez.

Ez az útmutató segít megérteni a hálózati házirendek belső szerkezetét; megértse, miben különböznek a hagyományos tűzfalakra vonatkozó szabályoktól. Kitér néhány buktatóra is, és ajánlásokat ad a Kubernetes alkalmazások biztonságosabbá tételéhez.

Kubernetes hálózati házirendek

A Kubernetes hálózati házirend-mechanizmus lehetővé teszi a platformon telepített alkalmazások interakciójának kezelését a hálózati rétegben (a harmadik az OSI modellben). A hálózati házirendekből hiányzik a modern tűzfalak fejlett funkciói közül néhány, például az OSI Layer 7 végrehajtása és a fenyegetésészlelés, de alapvető hálózati biztonságot nyújtanak, ami jó kiindulópont.

A hálózati házirendek szabályozzák a podok közötti kommunikációt

A Kubernetes munkaterhelései egy vagy több együttesen telepített tárolóból állnak. A Kubernetes minden podhoz hozzárendel egy IP-címet, amely elérhető más podokból. A Kubernetes hálózati házirendjei ugyanúgy állítják be a hozzáférési jogokat a pod-csoportokhoz, mint ahogy a felhő biztonsági csoportjai a virtuálisgép-példányokhoz való hozzáférés szabályozására szolgálnak.

Hálózati szabályzatok meghatározása

A többi Kubernetes-erőforráshoz hasonlóan a hálózati házirendek is a YAML-ben vannak megadva. Az alábbi példában az alkalmazás balance hozzáférés 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

(Jegyzet. ford.: ez a képernyőkép, mint minden további hasonló, nem natív Kubernetes eszközökkel készült, hanem a Tufin Orca eszközzel, amelyet az eredeti cikk szerzőjének cége fejlesztett ki, és amelyről az anyag végén említést teszünk.)

Saját hálózati szabályzatának meghatározásához alapvető YAML-ismeretekre lesz szüksége. Ez a nyelv a behúzáson alapul (ezt nem tabulátorok, hanem szóközök határozzák meg). A behúzott elem a felette lévő legközelebbi behúzott elemhez tartozik. Az új listaelem kötőjellel kezdődik, az összes többi elem alakja kulcs érték.

Miután leírta a házirendet YAML-ben, használja a kubectllétrehozásához a fürtben:

kubectl create -f policy.yaml

Hálózati házirend specifikáció

A Kubernetes hálózati házirend-specifikáció négy elemet tartalmaz:

1. podSelector: meghatározza az irányelv által érintett sorokat (célokat) - kötelező;
2. policyTypes: jelzi, hogy milyen típusú házirendek szerepelnek ebben: ingress és/vagy kilépés - nem kötelező, de javaslom minden esetben kifejezetten megadni;
3. ingress: meghatározza az engedélyezettet bejövő forgalom a céldobozokhoz – nem kötelező;
4. egress: meghatározza az engedélyezettet kimenő a célcsoportokból érkező forgalom nem kötelező.

A példa a Kubernetes webhelyről származik (kicseréltem role on app), megmutatja, hogyan használják mind a négy elemet:

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

Kérjük, vegye figyelembe, hogy mind a négy elemnek nem kell szerepelnie. Csak kötelező podSelector, kívánság szerint más paraméterek is használhatók.

Ha kihagyja policyTypes, a szabályzat a következőképpen értelmezendő:

• Alapértelmezés szerint a rendszer azt feltételezi, hogy ez határozza meg a bemeneti oldalt. Ha a házirend ezt kifejezetten nem mondja ki, a rendszer azt feltételezi, hogy minden forgalom tiltott.
• A kilépési oldalon a viselkedést a megfelelő kilépési paraméter megléte vagy hiánya határozza meg.

A hibák elkerülése érdekében ajánlom mindig egyértelművé tegye policyTypes.

A fenti logika szerint, ha a paraméterek ingress и / или egress kihagyva, a házirend megtagad minden forgalmat (lásd lent a „Levonási szabályt”).

Az alapértelmezett házirend az Engedélyezés

Ha nincs meghatározva házirend, a Kubernetes alapértelmezés szerint engedélyezi az összes forgalmat. Minden pod szabadon cserélhet információkat egymás között. Ez biztonsági szempontból ellentmondásosnak tűnhet, de ne feledje, hogy a Kubernetes-et eredetileg a fejlesztők tervezték, hogy lehetővé tegye az alkalmazások együttműködését. A hálózati házirendek később kerültek hozzáadásra.

Névterek

A névterek a Kubernetes együttműködési mechanizmusa. Úgy tervezték, hogy elszigeteljék egymástól a logikai környezeteket, míg a terek közötti kommunikáció alapértelmezés szerint engedélyezett.

A legtöbb Kubernetes-összetevőhöz hasonlóan a hálózati házirendek is egy adott névtérben élnek. A blokkban metadata megadhatja, hogy a házirend melyik területhez tartozik:

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

Ha a névtér nincs kifejezetten megadva a metaadatokban, akkor a rendszer a kubectl-ben megadott névteret fogja használni (alapértelmezés szerint namespace=default):

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

ajánlom kifejezetten adja meg a névteret, kivéve, ha olyan házirendet ír, amely egyszerre több névteret céloz meg.

Elsődleges az elem podSelector a házirendben kiválasztja a sorba rendezéseket abból a névtérből, amelyhez a házirend tartozik (megtagadják a hozzáférést egy másik névtérből származó sorba rendezésekhez).

Hasonlóképpen a podSelectors be- és kilépő blokkokban csak a saját névterükből választhat podokat, hacsak természetesen nem kombinálja őket ezzel namespaceSelector (erről a „Szűrés névterek és sorok alapján” részben lesz szó).

Szabályzat elnevezési szabályok

A házirend nevek egyediek ugyanazon a névtéren belül. Ugyanazon a területen nem lehet két azonos nevű házirend, de lehetnek azonos nevű házirendek különböző helyeken. Ez akkor hasznos, ha ugyanazt a házirendet szeretné újra alkalmazni több területen.

Az egyik névadási mód különösen tetszik. Ez abból áll, hogy a névtér nevét kombinálja a célsorokkal. Például:

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

Címkék

Egyéni címkéket csatolhat a Kubernetes-objektumokhoz, például sorba rendezésekhez és névterekhez. Címkék (címkék - címkék) a felhőben található címkék megfelelői. A Kubernetes hálózati házirendjei címkéket használnak a kiválasztáshoz hüvelyekamelyekre vonatkoznak:

podSelector:
  matchLabels:
    role: db

… vagy névterekamelyre vonatkoznak. Ez a példa a névterekben lévő összes sorba jelölést választja ki a megfelelő címkékkel:

namespaceSelector:
  matchLabels:
    project: myproject

Egy figyelmeztetés: használat közben namespaceSelector győződjön meg arról, hogy a kiválasztott névterek a megfelelő címkét tartalmazzák. Ügyeljen arra, hogy a beépített névterek, mint pl default и kube-system, alapértelmezés szerint nem tartalmaznak címkéket.

A következőképpen adhat hozzá címkét egy térhez:

kubectl label namespace default namespace=default

Ugyanakkor névtér a szakaszban metadata a hely tényleges nevére kell hivatkoznia, nem a címkére:

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

Forrás és cél

A tűzfalszabályzat forrásokkal és célállomásokkal rendelkező szabályokból áll. A Kubernetes hálózati házirendjeit egy célhoz határozzák meg – egy sor pod-hoz, amelyre vonatkoznak –, majd szabályokat állítanak be a be- és/vagy kilépő forgalomra. Példánkban a házirend célja a névtér összes sorba rendezése lesz default kulcsos címkével app és jelentése 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

alszakasz ingress ebben a házirendben megnyitja a bejövő forgalmat a célcsoportok felé. Más szavakkal, az ingress a forrás, a cél pedig a megfelelő cél. Hasonlóképpen, a kilépés a cél, a cél pedig a forrása.

Ez két tűzfalszabálynak felel meg: Ingress → Target; Gól → Kilépés.

Kilépés és DNS (fontos!)

A kimenő forgalom korlátozásával fordítson különös figyelmet a DNS-re - A Kubernetes ezt a szolgáltatást használja a szolgáltatások IP-címekre való leképezésére. Például a következő házirend nem fog működni, mert nem engedélyezte az alkalmazást balance hozzáférés a DNS-hez:

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

Megjavíthatja a DNS-szolgáltatáshoz való hozzáférés megnyitásával:

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

Utolsó elem to üres, ezért közvetetten kiválaszt minden sorba az összes névtérben, lehetővé téve balance küldjön DNS-lekérdezéseket a megfelelő Kubernetes szolgáltatásnak (általában a térben fut kube-system).

Ez a megközelítés működik, bárhogy is legyen túlságosan megengedő és bizonytalan, mert lehetővé teszi a DNS-lekérdezések fürtön kívülre irányítását.

Három egymást követő lépésben javíthatja.

1. Csak DNS-lekérdezések engedélyezése belső klaszter hozzáadásával 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. Csak névtéren belül engedélyezze a DNS-lekérdezéseket kube-system.

Ehhez hozzá kell adni egy címkét a névtérhez kube-system: kubectl label namespace kube-system namespace=kube-system - és írja le a szabályzatba 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. A paranoiás emberek még tovább mehetnek, és korlátozhatják a DNS-lekérdezéseket egy adott DNS-szolgáltatásra kube-system. A „Szűrés névterek ÉS sorba rendezések alapján” szakasz megmondja, hogyan érheti el ezt.

Egy másik lehetőség a DNS feloldása a névtér szintjén. Ebben az esetben nem kell minden szolgáltatáshoz megnyitni:

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

Üres podSelector kijelöli a névtér összes sorát.

Első meccs és szabályrend

A hagyományos tűzfalakban a csomagon végrehajtott műveletet (Engedélyezés vagy Megtagadás) az első szabály határozza meg, amelynek eleget tesz. A Kubernetesben a házirendek sorrendje nem számít.

Alapértelmezés szerint, ha nincsenek beállítva házirendek, a pod-ok közötti kommunikáció megengedett, és szabadon cserélhetnek információkat. A házirendek megfogalmazásának megkezdése után minden egyes, legalább egyikük által érintett pod izolálódik az azt kiválasztott összes házirend diszjunkciójának (logikai VAGY) megfelelően. A házirendek által nem érintett sorok nyitva maradnak.

Ezt a viselkedést lehúzási szabály segítségével módosíthatja.

Levonási szabály („Elutasítás”)

A tűzfalszabályzatok általában megtagadnak minden olyan forgalmat, amely nem kifejezetten engedélyezett.

A Kubernetesben nincs tagadás, azonban hasonló hatás érhető el egy normál (megengedő) házirenddel, ha kiválasztunk egy üres forrássor-csoportot (ingress):

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

Ez a házirend kijelöli az összes sorba rendezést a névtérben, és definiálatlanul hagyja a belépést, megtagadva az összes bejövő forgalmat.

Hasonló módon korlátozhatja a névtérből érkező összes kimenő forgalmat:

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

Kérjük, vegye figyelembe, hogy minden további házirend, amely lehetővé teszi a névtérben lévő sorba rendezések forgalmát, elsőbbséget élvez ezzel a szabállyal szemben (hasonlóan egy engedélyezési szabály hozzáadásához a tiltó szabály elé a tűzfalkonfigurációban).

Engedélyezzen mindent (Bármi-Any-Any-Allow)

Minden engedélyezése házirend létrehozásához ki kell egészítenie a fenti Megtagadási szabályzatot egy üres elemmel ingress:

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

Lehetővé teszi a hozzáférést minden sorba az összes névtérben (és az összes IP-címet) a névtér bármely podjára default. Ez a viselkedés alapértelmezés szerint engedélyezve van, így általában nem kell tovább definiálni. Néha azonban előfordulhat, hogy ideiglenesen le kell tiltania bizonyos engedélyeket a probléma diagnosztizálásához.

A szabály szűkíthető, hogy csak a hozzáférést engedélyezze egy adott hüvelykészlet (app:balance) a névtérben default:

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

A következő házirend engedélyezi az összes be- és kimenő forgalmat, beleértve a hozzáférést a fürtön kívüli bármely IP-címhez:

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

Több irányelv kombinálása

A házirendek logikai VAGY három szinten kombinálódnak; Az egyes pod engedélyek beállítása a rájuk ható összes házirend elkülönülése szerint történik:

1. A mezőkön from и to Háromféle elem definiálható (mindegyik az OR használatával kombinálható):

• namespaceSelector — kijelöli a teljes névteret;
• podSelector — kiválasztja a hüvelyeket;
• ipBlock — kiválaszt egy alhálózatot.

Sőt, az elemek száma (akár azonosak is) az alszakaszokban from/to nincs korlátozva. Mindegyiket a logikai VAGY kombinálja.

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. Az irányelv szakaszon belül ingress sok eleme lehet from (logikai VAGY-val kombinálva). Hasonlóképpen szakasz egress sok elemet tartalmazhat to (disjunkcióval is kombinálva):

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. A különböző irányelvek logikai VAGY-val is kombinálódnak

De ezek kombinálásakor van egy korlátozás rámutatott Chris Cooney: A Kubernetes csak különböző házirendekkel tud kombinálni policyTypes (Ingress vagy Egress). A belépést (vagy kilépést) meghatározó házirendek felülírják egymást.

Névterek közötti kapcsolat

Alapértelmezés szerint a névterek közötti információmegosztás engedélyezett. Ez megváltoztatható egy megtagadási házirend használatával, amely korlátozza a névtérbe kimenő és/vagy bejövő forgalmat (lásd fent a „Csupán kivonási szabályt”).

Miután blokkolta a hozzáférést egy névtérhez (lásd fent a „Csupán kivonási szabályt”), kivételeket tehet a megtagadási szabályzat alól, ha engedélyezi a kapcsolatokat egy adott névtérből a 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

Ennek eredményeként a névtérben lévő összes sor default hozzáférhet a hüvelyekhez postgres névtérben database. De mi van akkor, ha meg akarja nyitni a hozzáférést postgres csak bizonyos sorok a névtérben default?

Szűrés névterek és sorok alapján

A Kubernetes 1.11-es és újabb verziói lehetővé teszik az operátorok kombinálását namespaceSelector и podSelector logikai ÉS használatával. Így néz ki:

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

Miért értelmezik ezt ÉS-nek a szokásos VAGY helyett?

Kérjük, vegye figyelembe, hogy a podSelector nem kötőjellel kezdődik. A YAML-ben ez azt jelenti podSelector és ott áll előtte namespaceSelector hivatkozik ugyanarra a listaelemre. Ezért ezeket a logikai ÉS-szel kombinálják.

Előtte kötőjel hozzáadása podSelector egy új listaelem megjelenését fogja eredményezni, amely egyesül az előzővel namespaceSelector logikai VAGY használatával.

Adott címkével ellátott hüvelyek kiválasztása minden névtérben, írja be üresen 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

Több kiadó csatlakozik I

A több objektumot (gazdagépeket, hálózatokat, csoportokat) tartalmazó tűzfal szabályait logikai VAGY kombinálja. A következő szabály fog működni, ha a csomagforrás egyezik Host_1 ИЛИ Host_2:

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

Éppen ellenkezőleg, a Kubernetesben a különféle címkék podSelector vagy namespaceSelector a logikai ÉS jelöléssel kombinálódnak. Például a következő szabály olyan sorba válogatást választ, amely mindkét címkével rendelkezik, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Ugyanez a logika vonatkozik minden típusú operátorra: a házirend-célválasztókra, a pod-választókra és a névtér-választókra.

Alhálózatok és IP-címek (IPBlocks)

A tűzfalak VLAN-okat, IP-címeket és alhálózatokat használnak a hálózat szegmentálására.

A Kubernetesben az IP-címek automatikusan hozzá vannak rendelve a podokhoz, és gyakran változhatnak, ezért a címkéket a rendszer a pod-ok és névterek kiválasztására használja a hálózati házirendekben.

Alhálózatok (ipBlocks) bejövő (bemeneti) vagy kimenő (kimeneti) külső (észak-déli) kapcsolatok kezelésére szolgálnak. Például ez a házirend megnyílik a névtér összes sorba rendezése számára default hozzáférés a Google DNS szolgáltatáshoz:

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

Az üres sorválasztó ebben a példában azt jelenti, hogy „a névtér összes sorba válogatása”.

Ez a házirend csak a 8.8.8.8-hoz enged hozzáférést; minden más IP-címhez való hozzáférés tilos. Tehát lényegében letiltotta a belső Kubernetes DNS-szolgáltatáshoz való hozzáférést. Ha továbbra is meg akarja nyitni, ezt kifejezetten jelezze.

Rendszerint ipBlocks и podSelectors kölcsönösen kizárják egymást, mivel a podok belső IP-címeit nem használják ipBlocks. Jelölésével belső IP pod, akkor valójában engedélyezni fogja a kapcsolatokat az ezekkel a címekkel rendelkező pod-okba/dobozokból. A gyakorlatban nem fogja tudni, hogy melyik IP-címet használja, ezért ne használja őket a pod-ok kiválasztásához.

Ellenpéldaként a következő házirend minden IP-t magában foglal, és ezért hozzáférést biztosít az összes többi podhoz:

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

Csak külső IP-címekhez nyithat hozzáférést, kivéve a pod-ok belső IP-címeit. Például, ha a pod alhálózata 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

Portok és protokollok

A podok általában egy portot hallgatnak. Ez azt jelenti, hogy egyszerűen nem adhat meg portszámokat a házirendekben, és mindent alapértelmezettként hagyhat. Javasoljuk azonban, hogy a házirendeket a lehető legszigorúbbá tegye, így bizonyos esetekben továbbra is megadhat portokat:

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

Vegye figyelembe, hogy a választó ports a blokk összes elemére vonatkozik to vagy from, ami tartalmaz. Ha különböző portokat szeretne megadni a különböző elemkészletekhez, bontsa fel ingress vagy egress több alszakaszba to vagy from és mindegyik regisztrálja a portjait:

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

Alapértelmezett port működés:

• Ha teljesen kihagyja a portdefiníciót (ports), ez minden protokollt és portot jelent;
• Ha kihagyja a protokoll definíciót (protocol), ez TCP-t jelent;
• Ha kihagyja a portdefiníciót (port), ez az összes portot jelenti.

Bevált gyakorlat: Ne hagyatkozzon az alapértelmezett értékekre, hanem kifejezetten adja meg, mire van szüksége.

Kérjük, vegye figyelembe, hogy pod portokat kell használnia, nem szervizportokat (erről bővebben a következő bekezdésben olvashat).

Meg vannak határozva házirendek a podokra vagy szolgáltatásokra?

A Kubernetesben található pod-ok általában egy szolgáltatáson keresztül érik el egymást – egy virtuális terheléselosztón, amely átirányítja a forgalmat a szolgáltatást megvalósító podokra. Azt gondolhatnánk, hogy a hálózati házirendek szabályozzák a szolgáltatásokhoz való hozzáférést, de ez nem így van. A Kubernetes hálózati házirendek a pod portokon működnek, nem a szolgáltatási portokon.

Például, ha egy szolgáltatás figyeli a 80-as portot, de a forgalmat a 8080-as portjára irányítja át, pontosan 8080-at kell megadnia a hálózati házirendben.

Egy ilyen mechanizmust szuboptimálisnak kell tekinteni: ha a szolgáltatás belső struktúrája (amelyek portjai hallgatnak) megváltozik, a hálózati házirendeket frissíteni kell.

Új építészeti megközelítés a Service Mesh használatával (Istioról lásd például lent – ​​kb. fordítás.) lehetővé teszi, hogy megbirkózzon ezzel a problémával.

Kell-e regisztrálni az Ingress-t és az Egress-t is?

A rövid válasz igen, ahhoz, hogy az A pod kommunikáljon a pod B-vel, engedélyezni kell egy kimenő kapcsolat létrehozását (ehhez be kell állítani egy kilépési szabályzatot), és a pod B-nek képesnek kell lennie fogadni a bejövő kapcsolatot ( ehhez ennek megfelelően behatolási politika kell).

A gyakorlatban azonban az alapértelmezett házirendre hagyatkozhat az egyik vagy mindkét irányú kapcsolatok engedélyezéséhez.

Ha néhány pod-forrás egy vagy több választja ki kijárat-politikusok, a vele szemben támasztott korlátozásokat az ő diszjunkciójuk fogja meghatározni. Ebben az esetben kifejezetten engedélyeznie kell a podhoz való csatlakozást -címzett. Ha egy pod-ot egyetlen házirend sem jelöl ki, a kimenő (kimeneti) forgalma alapértelmezés szerint engedélyezett.

Hasonlóképpen a hüvely sorsa is azcímzett, amelyet egy vagy több kiválasztott behatolás-politikusok, az elkülönülésük határozza meg. Ebben az esetben kifejezetten engedélyeznie kell neki, hogy forgalmat fogadjon a forrássorból. Ha a sorba rendezést egyetlen házirend sem választja ki, akkor alapértelmezés szerint a hozzá tartozó összes bejövő forgalom engedélyezett.

Lásd alább a Stateful vagy Stateless.

Naplók

A Kubernetes hálózati házirendjei nem naplózhatják a forgalmat. Ez megnehezíti annak megállapítását, hogy egy házirend a tervezettnek megfelelően működik-e, és nagymértékben megnehezíti a biztonsági elemzést.

A külső szolgáltatások felé irányuló forgalom szabályozása

A Kubernetes hálózati házirendjei nem teszik lehetővé teljesen minősített tartománynév (DNS) megadását a kilépési szakaszokban. Ez a tény jelentős kényelmetlenséghez vezet, amikor a forgalmat olyan külső célállomásokra próbálják korlátozni, amelyek nem rendelkeznek rögzített IP-címmel (például az aws.com).

Házirend ellenőrzése

A tűzfalak figyelmeztetik, vagy akár megtagadják a rossz szabályzat elfogadását. A Kubernetes bizonyos ellenőrzéseket is végez. Amikor hálózati házirendet állít be a kubectl segítségével, a Kubernetes kijelentheti, hogy az helytelen, és megtagadhatja annak elfogadását. Más esetekben a Kubernetes átveszi a szabályzatot, és kitölti a hiányzó adatokkal. Megtekinthetők a következő paranccsal:

kubernetes get networkpolicy <policy-name> -o yaml

Ne feledje, hogy a Kubernetes érvényesítési rendszere nem tévedhetetlen, és bizonyos típusú hibákat kihagyhat.

Исполнение

A Kubernetes nem saját maga hajtja végre a hálózati házirendeket, hanem csupán egy API-átjáró, amely az irányítás terhét a Container Networking Interface (CNI) nevű mögöttes rendszerre ruházza át. A házirendek beállítása egy Kubernetes-fürtön a megfelelő CNI hozzárendelése nélkül ugyanaz, mint a házirendek létrehozása a tűzfalfelügyeleti kiszolgálón anélkül, hogy ezeket a tűzfalakra telepítené. Önön múlik, hogy megfelelő CNI-vel rendelkezik-e, vagy Kubernetes platformok esetén a felhőben tárolja-e. (láthatja a szolgáltatók listáját itt — kb. ford.), engedélyezze a hálózati házirendeket, amelyek beállítják a CNI-t.

Vegye figyelembe, hogy a Kubernetes nem figyelmezteti Önt, ha hálózati házirendet állít be a megfelelő segítő CNI nélkül.

Állami vagy hontalan?

Minden Kubernetes CNI, amellyel találkoztam, állapottartó (például a Calico Linux conntrack-et használ). Ez lehetővé teszi a pod számára, hogy válaszokat kapjon az általa kezdeményezett TCP-kapcsolaton anélkül, hogy újra létre kellene hoznia azt. Nem tudok azonban olyan Kubernetes szabványról, amely garantálná az állapotszerűséget.

Speciális biztonsági házirend-kezelés

Íme néhány módszer a biztonsági szabályzat betartatásának javítására a Kubernetesben:

1. A Service Mesh architektúra minta oldalkocsis konténereket használ a részletes telemetria és a forgalomirányítás szolgáltatási szintjén. Példaként vehetjük Azonos.
2. Egyes CNI-szállítók kiterjesztették eszközeiket, hogy túlmutassák a Kubernetes hálózati házirendjeit.
3. Tufin Orca Biztosítja a Kubernetes hálózati házirendek láthatóságát és automatizálását.

A Tufin Orca csomag kezeli a Kubernetes hálózati házirendeket (és a fenti képernyőképek forrása).

további információk

• Példák hálózati irányelvekre, amelyeket Ahmet Alp Balkan készített a GKE-től;
• Dokumentáció a Kubernetes hivatalos webhelyéről;
• Útmutató a Kubernetes hálózati modellhez;
• Szkript a hálózati házirendek ellenőrzéséhez.

Következtetés

A Kubernetes hálózati házirendek jó eszközkészletet kínálnak a fürtök szegmentálásához, de nem intuitívak, és sok finomsággal rendelkeznek. Emiatt az összetettség miatt úgy gondolom, hogy sok meglévő fürtszabályzat hibás. A probléma lehetséges megoldásai közé tartozik a házirend-definíciók automatizálása vagy más szegmentáló eszközök használata.

Remélem, ez az útmutató segít tisztázni néhány kérdést és megoldani az esetleges problémákat.

PS a fordítótól

Olvassa el blogunkon is:

• "Vissza a mikroszolgáltatásokhoz az Istióval": 1. rész (bevezetés a főbb jellemzőkbe), 2. rész (útválasztás, forgalomirányítás), 3. rész (biztonság);
• "Illusztrált útmutató a Kubernetes hálózatépítéshez": 1. és 2. rész (hálózati modell, átfedő hálózatok), 3. rész (szolgáltatások és forgalomfeldolgozás);
• «Docker és Kubernetes a biztonságra érzékeny környezetekben";
• «9 bevált gyakorlat a Kubernetes biztonsághoz";
• «11 módja annak, hogy (ne) váljon a Kubernetes-hack áldozatává".

Forrás: will.com