Destpêkek Polîtîkayên Tora Kubernetes ji bo Pisporên Ewlekariyê

Not. werger.: Nivîskarê gotarê, Reuven Harrison, xwedan ezmûna 20 salan e di pêşkeftina nermalavê de, û îro CTO û hev-avakarê Tufin e, pargîdaniyek ku çareseriyên rêveberiya siyaseta ewlehiyê diafirîne. Dema ku ew polîtîkayên torê yên Kubernetes wekî amûrek pir bi hêz ji bo dabeşkirina torê di komekê de dibîne, ew di heman demê de bawer dike ku ew di pratîkê de ne ew qas hêsan in ku werin bicîh kirin. Vê materyalê (pir berbelav) mebest e ku hişmendiya pisporan li ser vê pirsgirêkê baştir bike û ji wan re bibe alîkar ku konfigurasyonên pêwîst biafirînin.

Îro, gelek pargîdanî her ku diçe Kubernetes hilbijêrin ku serîlêdanên xwe bimeşînin. Eleqeya vê nermalavê ew qas zêde ye ku hin kes Kubernetes dibêjin "pergala xebitandina nû ya navenda daneyê." Gav bi gav, Kubernetes (an k8s) dest pê dike ku wekî beşek krîtîk a karsaziyê were dîtin, ku pêdivî bi rêxistinkirina pêvajoyên karsaziya gihîştî, tevî ewlehiya torê heye.

Ji bo pisporên ewlehiyê yên ku ji xebata bi Kubernetes re matmayî ne, dibe ku eşkerebûna rastîn polîtîkaya xwerû ya platformê be: destûr bide her tiştî.

Ev rêber dê ji we re bibe alîkar ku hûn strukturên hundurîn ên polîtîkayên torê fam bikin; fêm bikin ka ew çawa ji qaîdeyên ji bo dîwarên agir ên birêkûpêk cûda dibin. Ew ê di heman demê de hin xeletiyan veşêre û pêşniyaran peyda bike da ku ji bo sepanên ewledar ên li ser Kubernetes bibe alîkar.

Polîtîkayên torê yên Kubernetes

Mekanîzmaya polîtîkaya torê ya Kubernetes dihêle hûn danûstendina serîlêdanên ku li ser platformê di qata torê de hatine bicîh kirin (ya sêyem di modela OSI de) birêve bibin. Polîtîkayên torê nebûna hin taybetmendiyên pêşkeftî yên dîwarên agir ên nûjen, wekî OSI Layer 7 û tespîtkirina xetereyê, lê ew astek bingehîn a ewlehiya torê peyda dikin ku xalek destpêkek baş e.

Polîtîkayên torê danûstandinên di navbera pods de kontrol dikin

Karên di Kubernetes de li ser podan têne belav kirin, ku ji yek an çend konteyneran pêk tên ku bi hev re hatine bicîh kirin. Kubernetes ji her podek navnîşek IP-ya ku ji podên din ve tê gihîştin destnîşan dike. Polîtîkayên torê yên Kubernetes mafên gihîştinê ji bo komên podan destnîşan dikin bi heman rengî ku komên ewlehiyê yên di ewr de têne bikar anîn da ku gihîştina mînakên makîneya virtual kontrol bikin.

Diyarkirina Polîtîkayên Tora

Mîna çavkaniyên din ên Kubernetes, polîtîkayên torê di YAML de têne destnîşan kirin. Di nimûneya jêrîn de, serîlêdanê balance tê gihîştin 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

(Not. werger.: ev dîmen, mîna hemî yên paşîn ên mîna hev, ne bi karanîna amûrên xwemalî yên Kubernetes, lê bi karanîna amûra Tufin Orca, ku ji hêla pargîdaniya nivîskarê gotara orjînal ve hatî pêşve xistin û ku di dawiya materyalê de hatî destnîşan kirin, hate afirandin.)

Ji bo ku hûn polîtîkaya torê ya xwe diyar bikin, hûn ê hewceyê zanîna bingehîn a YAML bibin. Ev ziman li ser bingeha dakêşanê ye (li şûna tabloyan ji hêla cîhan ve hatî destnîşan kirin). Hêmanek binavkirî girêdayî hêmana herî nêzik a li jora wê ye. Hêmanek navnîşek nû bi defek dest pê dike, hemî hêmanên din xwedî form in key-nirx.

Siyaseta di YAML de diyar kir, bikar bînin kubectlji bo afirandina wê di komê de:

kubectl create -f policy.yaml

Specification Policy Network

Taybetmendiya polîtîkaya torê ya Kubernetes çar hêman pêk tîne:

1. podSelector: podên ku ji vê siyasetê bandor bûne diyar dike (armanc) - pêdivî ye;
2. policyTypes: destnîşan dike ka çi cûreyên polîtîkayan di vê yekê de hene: ketin û/an derketin - vebijarkî, lê ez pêşniyar dikim ku di hemî rewşan de bi eşkere diyar bike;
3. ingress: destûr diyar dike hatin seyrûsefera ku li ser podên armanckirî - vebijarkî;
4. egress: destûr diyar dike derketin trafîkê ji pods hedef vebijarkî ye.

Mînak ji malpera Kubernetes hatî girtin (min veguherand role li ser app), nîşan dide ku çawa her çar hêman têne bikar anîn:

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

Ji kerema xwe not bikin ku her çar hêman ne hewce ne ku bêne nav kirin. Tenê mecbûrî ye podSelector, Parametreyên din dikarin wekî ku tê xwestin bêne bikar anîn.

Ger hûn nehêlin policyTypesSiyaset dê wiha were şîrove kirin:

• Ji hêla xwerû ve, tê texmîn kirin ku ew alîyê ketinê diyar dike. Ger sîyaset bi eşkere vê yekê nebêje, pergal dê texmîn bike ku hemî seyrûsefer qedexe ye.
• Tevgera li aliyê derketinê dê ji hêla hebûn an nebûna pîvana derketinê ya têkildar ve were destnîşankirin.

Ji bo ku ji xeletiyan dûr nekevin ez pêşniyar dikim her tim eşkere bike policyTypes.

Li gor mantiqa jorîn, eger parametre ingress û / an egress ji holê rabe, sîyaset dê hemî seyrûseferê red bike (li jêr "Qanûna Teqandinê" binêre).

Siyaseta xwerû Destûr e

Ger sîyasetek neyê diyarkirin, Kubernetes ji hêla xwerû ve destûrê dide hemî seyrûseferê. Hemî pod dikarin bi azadî di nav xwe de agahdarî biguhezînin. Dibe ku ev ji perspektîfek ewlehiyê berevajî xuya bike, lê ji bîr mekin ku Kubernetes bi eslê xwe ji hêla pêşdebiran ve hatî sêwirandin da ku hevberdana serîlêdanê çalak bike. Polîtîkayên torê paşê hatin zêdekirin.

Navên navan

Navên navan mekanîzmaya hevkariya Kubernetes in. Ew ji bo veqetandina hawîrdorên mentiqî ji hev hatine sêwirandin, dema ku ragihandina di navbera cîhan de ji hêla xwerû ve hatî destûr kirin.

Mîna piraniya pêkhateyên Kubernetes, polîtîkayên torê di nav cîhek taybetî de dijîn. Di blokê de metadata hûn dikarin diyar bikin ka polîtîka girêdayî kîjan cîhê ye:

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

Ger cîhê navan bi eşkereyî di metadata de nehatibe diyar kirin, pergal dê cîhê navên ku di kubectl de hatî destnîşan kirin (bi xwerû namespace=default):

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

Ez pêşniyar dikim cîhê navan bi eşkere diyar bike, heya ku hûn sîyasetek ku bi yekcarî gelek cîhên navan dike armanc nenivîsin.

Sereke pêve podSelector di sîyasetê de dê ji cîha navan a ku polîtîka jê re girêdayî ye podan hilbijêrin (ji cîhê navekî din gihandina podan tê red kirin).

Bi heman awayî, podSelectors di blokên ketin û derketinê de dikare tenê ji cîhê navên xwe potan hilbijêrin, heya ku bê guman hûn wan bi hev re nekin namespaceSelector (ev ê di beşa "Parzkirin li gorî nav û pelan" de were nîqaş kirin).

Rêbazên Namekirina Siyasetê

Navên polîtîkayê di nav heman navan de yekta ne. Di heman mekan de du polîtîkayên bi heman navî nikarin hebin, lê di mekanên cihê de polîtîkayên bi heman navî hene. Dema ku hûn dixwazin heman polîtîkayê li gelek cîhan ji nû ve bicîh bikin ev bikêr e.

Ez bi taybetî ji yek ji awayên navkirinê hez dikim. Ew ji berhevkirina navê cîhê navan bi pêlên armancê re pêk tê. Bo nimûne:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

Labels

Hûn dikarin etîketên xwerû bi hêmanên Kubernetes ve girêbidin, wek pod û navan. Labels (etîket - etîket) hevwateya tagên di ewr de ne. Polîtîkayên torê yên Kubernetes ji bo hilbijartina etîketan bikar tînin podsku ew serî lê didin:

podSelector:
  matchLabels:
    role: db

… an cîhên navanku ew serî lê didin. Ev nimûne di nav navan de hemî podên bi etîketên têkildar hildibijêre:

namespaceSelector:
  matchLabels:
    project: myproject

Yek hişyarî: dema ku bikar bînin namespaceSelector Piştrast bike ku navên ku hûn hildibijêrin etîketa rast dihewîne. Hay jê hebin ku navên çêkirî yên wekî default и kube-system, bi xweber etîketan nagirin.

Hûn dikarin etîketek li cîhek weha lê zêde bikin:

kubectl label namespace default namespace=default

Di heman demê de, qada navan di beşê de metadata Divê navê cîhê rastîn, ne labelê:

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

Çavkanî û cîh

Polîtîkayên Firewall ji qaîdeyên bi çavkanî û mebestan pêk tê. Polîtîkayên torê yên Kubernetes ji bo armancekê têne destnîşan kirin - komek podên ku ew lê sepandine - û dûv re ji bo seyrûsefera ketin û / an derketinê qaîdeyên destnîşan dikin. Di mînaka me de, armanca siyasetê dê hemî podên di nav qada navan de bin default bi labelê bi key app û wateya 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

Binbeş ingress di vê siyasetê de, seyrûsefera hatinê ber bi podên armancê vedike. Bi gotinek din, ketin çavkanî ye û armanc jî cîhê têkildar e. Her wusa, derketin meqsed û armanc jêderka wê ye.

Ev hevwateya du qaîdeyên firewallê ye: Ingress → Target; Armanc → Derketin.

Egress û DNS (girîng!)

Bi sînorkirina seyrûsefera derketinê, bala taybetî bidin DNS - Kubernetes vê karûbarê bikar tîne da ku karûbaran li navnîşanên IP-yê nexşîne. Mînakî, polîtîkaya jêrîn dê nexebite ji ber ku we destûr nedaye serîlêdanê balance gihîştina 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

Hûn dikarin wê bi vekirina gihîştina karûbarê DNS rast bikin:

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

Hêmana dawî to vala ye, û ji ber vê yekê ew nerasterast hildibijêre di hemî navan de hemî pod, destûr dide balance pirsên DNS-ê ji karûbarê guncan a Kubernetes re bişînin (bi gelemperî li cîhê dixebite kube-system).

Ev nêzîkatî dixebite, lê belê zêde destûrdar û bêbawer, ji ber ku ew dihêle ku pirsên DNS-ê li derveyî komê bêne rêve kirin.

Hûn dikarin wê di sê gavên li pey hev de çêtir bikin.

1. Destûrê bide pirsên DNS tenê hundur bi zêdekirinê kom bikin 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. Destûrê bide pirsên DNS tenê di nav cîhê navan de kube-system.

Ji bo vê yekê hûn hewce ne ku etîketek li cîhê navan zêde bikin kube-system: kubectl label namespace kube-system namespace=kube-system - û wê di karanîna siyasetê de binivîsin 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. Mirovên paranoîd dikarin hîn bêtir biçin û pirsên DNS-ê li ser karûbarek DNS-ya taybetî ya tê de sînordar bikin kube-system. Beşa "Parzkirin li gorî navan Û pods" dê ji we re vebêje ka meriv çawa wiya bi dest dixe.

Vebijarkek din jî çareserkirina DNS-ê di asta navan de ye. Di vê rewşê de, ew ê ne hewce ye ku ji bo her karûbarê vekin:

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

Vala podSelector di nav qada navan de hemî podan hildibijêre.

Yekem rêz û rêzika rêzê

Di dîwarên agir ên kevneşopî de, çalakiya (Destûr an Înkarkirin) li ser pakêtê bi qaîdeya yekem a ku ew têr dike tê destnîşankirin. Di Kubernetes de, rêza polîtîkayan ne girîng e.

Ji hêla xwerû ve, gava ku ti polîtîkayek nayê danîn, danûstandinên di navbera pods de destûr têne dayîn û ew dikarin bi serbestî agahdarî biguhezînin. Gava ku hûn dest bi formulekirina polîtîkayan dikin, her podek ku bi kêmî ve yek ji wan bandor dibe li gorî veqetandina (OR mentiqî) ya hemî polîtîkayên ku ew hilbijartiye veqetandî dibe. Podên ku ji ti siyasetê bandor nebin vekirî dimînin.

Hûn dikarin vê tevgerê bi karanîna qaîdeyek jêbirinê biguhezînin.

Rêbaza derxistinê ("Inkar")

Polîtîkayên Firewall bi gelemperî her seyrûsefera ku bi eşkere nayê destûr kirin red dike.

Di Kubernetes de çalakiya înkarkirinê tune, lêbelê, bi bijartina komek vala ji podên çavkaniyê (derketin) re bandorek wusa bi siyasetek birêkûpêk (destûr) dikare were bidestxistin:

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

Ev polîtîka hemî podên di nav qada navan de hildibijêre û têketinê nediyar dihêle, hemî seyrûsefera hatinê red dike.

Bi vî rengî, hûn dikarin hemî seyrûsefera derketinê ji cîhek navekî sînordar bikin:

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

Ji kerema xwe bibînin her polîtîkayên din ên ku destûrê dide seyrûsefera li ser podên di cîhê navan de dê pêşî li vê qaîdeyê bigire (wek mîna lê zêdekirina qaîdeyek destûr berî qaîdeyek înkarê di veavakirina dîwarê agir de).

Destûrê bide her tiştî (Any-Any-Any-Allow)

Ji bo afirandina polîtîkayek Destûrê bide Hemî, hûn hewce ne ku polîtîkaya Înkarkirinê ya li jor bi hêmanek vala temam bikin ingress:

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

Ew destûrê dide gihîştina ji hemî pod di hemî navan de (û hemî IP) ji her podek di nav qada navan de default. Ev tevger ji hêla xwerû ve hatî çalak kirin, ji ber vê yekê bi gelemperî hewce nake ku bêtir were destnîşankirin. Lêbelê, carinan dibe ku hûn hewce ne ku ji bo tespîtkirina pirsgirêkê hin destûrên taybetî bi demkî neçalak bikin.

Rêbaz dikare were teng kirin da ku tenê destûr bide gihîştinê komek taybetî ya pelan (app:balance) di qada navan de default:

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

Siyaseta jêrîn destûrê dide hemî seyrûsefera ketin û derketinê, tevî gihîştina her IP-ya li derveyî komê:

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

Têkelkirina Polîtîkayên Pirjimar

Siyaset bi karanîna OR mentiqî di sê astan de têne hev kirin; Destûrên her pod li gorî veqetandina hemî polîtîkayên ku bandorê li wê dikin têne destnîşan kirin:

1. Li zeviyan from и to Sê celeb hêman dikarin bêne destnîşankirin (ku hemî jî bi karanîna OR têne hev kirin):

• namespaceSelector - tevahiya navan hilbijêre;
• podSelector - pelan hildibijêre;
• ipBlock - subnetek hildibijêre.

Wekî din, hejmara hêmanan (tewra yên wekhev) di binbeşan de from/to ne sînorkirî ne. Hemî ew ê ji hêla OR-ya mantiqî ve bêne hev kirin.

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. Di hundurê beşa polîtîkayê de ingress dikare gelek hêman hebin from (ji hêla OR mentiqî ve tê hev kirin). Bi heman awayî, beş egress dibe ku gelek hêmanan bihewîne to (ji hêla veqetandinê ve jî tê hev kirin):

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. Siyasetên cihêreng jî bi OR mentiqî re têne hev kirin

Lê dema berhevkirina wan, li ser yek sînorek heye destnîşan kir Chris Cooney: Kubernetes tenê dikarin polîtîkayên bi cûda re hev bikin policyTypes (Ingress an Egress). Polîtîkayên ku ketin (an derketin) diyar dikin dê hevûdu binivîsînin.

Têkiliya di navbera navan de

Bi xwerû, parvekirina agahdarî di navbera cîhên navan de destûr e. Ev dikare bi karanîna polîtîkaya înkarkirinê ya ku dê seyrûsefera derketin û/an hatina nav qada navan sînordar bike (li jor "Qanûna Teqandinê" binêre).

Gava ku we gihandina cîhek navekî asteng kir (li jor li "Rêbaza Veqetandinê" binêre), hûn dikarin îstîsnayan ji polîtîkaya înkarkirinê re bikin û rê bidin girêdanên ji cîhek navek taybetî ku bikar bînin. 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

Wekî encamek, hemî pod di nav navan de default dê bigihîje podan postgres di navan de database. Lê heke hûn bixwazin gihîştina vekin çi ye postgres di cîhê navan de tenê pêlên taybetî default?

Li gorî nav û pelan parzûn bikin

Guhertoya Kubernetes 1.11 û jortir dihêle hûn operatoran bi hev re bikin namespaceSelector и podSelector AND-ya mentiqî bi kar tîne. Bi vî rengî xuya dike:

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

Çima ev li şûna OR-ya asayî wekî Û tê şîrove kirin?

not bikin ku podSelector bi daçekê dest pê nake. Di YAML de ev tê vê wateyê podSelector û li ber wî sekinî namespaceSelector serî li heman hêmana navnîşê bidin. Ji ber vê yekê, ew bi AND mentiqî re têne hev kirin.

Berê daçek lê zêde kirin podSelector dê bibe sedema derketina hêmanek navnîşek nû, ku dê bi ya berê re were berhev kirin namespaceSelector bikaranîna OR mantiqî.

Hilbijartina podên bi etîketek taybetî di hemû navan de, vala binivîse 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

Gelek etîket bi I-yê re hev dikin

Rêgezên ji bo dîwarek dîwarê bi gelek tiştan re (mêvandar, toran, kom) bi karanîna OR-ya mentiqî têne hev kirin. Rêbaza jêrîn dê bixebite ger çavkaniya pakêtê li hev bike Host_1 An Host_2:

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

Berevajî vê, di Kubernetes de etîketên cihêreng tê de hene podSelector an namespaceSelector bi AND-ya mantiqî re têne hev kirin. Mînakî, qaîdeya jêrîn dê pelên ku her du etîket hene hilbijêrin, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Heman mantiq ji bo her cûre operatoran derbas dibe: Hilbijêrên armanca siyasetê, hilbijêrên pod, û hilbijêrên cîhê navan.

Subnet û navnîşanên IP (IPBlocks)

Firewall VLAN, navnîşanên IP-yê, û subnetan bikar tînin da ku torê parçe bikin.

Di Kubernetes de, navnîşanên IP-ê bixweber ji podan re têne destnîşan kirin û dikarin pir caran biguhezin, ji ber vê yekê etîket têne bikar anîn ku di polîtîkayên torê de pod û cîhên navan hilbijêrin.

Subnets (ipBlocks) dema ku peywendiyên hatinî (derketin) an derketin (derketin) yên derve (Bakur-Başûr) têne rêvebirin têne bikar anîn. Mînakî, ev polîtîka ji cîhê navan re ji hemî podan re vedike default gihîştina karûbarê Google DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

Hilbijêra podê ya vala di vê nimûneyê de tê wateya "hemû podên di cîhê navan de hilbijêrin."

Ev polîtîka tenê destûrê dide gihîştina 8.8.8.8; gihîştina IP-ya din qedexe ye. Ji ber vê yekê, di eslê xwe de, we gihîştina karûbarê navxweyî ya Kubernetes DNS asteng kiriye. Ger hûn hîn jî dixwazin wê vekin, vê yekê bi eşkere destnîşan bikin.

Fêrane ipBlocks и podSelectors ji hev veqetandî ne, ji ber ku navnîşanên IP-ya hundurîn ên podan nayên bikar anîn ipBlocks. Bi nîşankirin podên IP yên navxweyî, hûn ê bi rastî bi van navnîşanan rê bidin girêdanên ji/ji podan re. Di pratîkê de, hûn ê nizanin kîjan navnîşana IP-ê bikar bînin, ji ber vê yekê divê ew ji bo hilbijartina podan neyên bikar anîn.

Wekî mînakek dijber, polîtîkaya jêrîn hemî IP-yan digire û ji ber vê yekê destûrê dide gihîştina hemî podên din:

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

Hûn dikarin gihîştina tenê IP-yên derveyî vekin, ji bilî navnîşanên IP-ya hundurîn ên podan. Mînakî, heke subneta podê we 10.16.0.0/14 be:

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

Port û protokol

Bi gelemperî pod li yek portê guhdarî dikin. Ev tê vê wateyê ku hûn nekarin di polîtîkayan de hejmarên portê diyar bikin û her tiştî wekî xwerû bihêlin. Lêbelê, tê pêşniyar kirin ku polîtîkayên bi qasî ku gengaz be sînordar bikin, ji ber vê yekê di hin rewşan de hûn hîn jî dikarin portan diyar bikin:

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

Têbînî ku hilbijêr ports ji bo hemû hêmanên di blokê de derbas dibe to an from, ku dihewîne. Ji bo destnîşankirina portên cihêreng ên ji bo komên cûda yên hêmanan, dabeş bikin ingress an egress nav çend beşan bi to an from û di her tomarkirinê de portên xwe:

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

Operasyona porta xwerû:

• Ger hûn pênaseya portê bi tevahî ji holê rakin (ports), ev tê wateya hemî protokol û hemî port;
• Ger hûn pênaseya protokolê derxînin (protocol), ev tê wateya TCP;
• Ger hûn pênaseya portê derxînin (port), ev tê wateya hemî port.

Pratîka çêtirîn: Pişta xwe nedin nirxên xwerû, tiştê ku hûn hewce ne bi eşkere diyar bikin.

Ji kerema xwe not bikin ku divê hûn portên pod bikar bînin, ne portên karûbarê (li ser vê yekê di paragrafa paşîn de bêtir).

Polîtîkayên ji bo pods an karûbaran têne diyar kirin?

Bi gelemperî, podên li Kubernetes bi karûbarek xwe digihînin hev - hevsengek barkirina virtual ya ku seyrûseferê beralî dike li ser podên ku karûbarê bicîh dikin. Hûn dikarin bifikirin ku polîtîkayên torê gihîştina karûbaran kontrol dikin, lê ev ne wusa ye. Polîtîkayên torê yên Kubernetes li ser portên pod dixebitin, ne li portên karûbarê.

Mînakî, heke karûbarek li porta 80-ê guhdarî bike, lê seyrûseferê berbi porta 8080-ê ya podên xwe vegerîne, divê hûn di polîtîkaya torê de tam 8080 diyar bikin.

Pêdivî ye ku mekanîzmayek wusa nebaş were hesibandin: heke strukturên hundurîn ên karûbar (portên ku pod lê guhdarî dikin) biguhezîne, pêdivî ye ku polîtîkayên torê bêne nûve kirin.

Nêzîkatiya mîmariya nû ya ku bi karûbarê Mesh bikar tîne (mînak, li ser Istio li jêr binêre - nêzîkê werger.) destûrê dide te ku bi vê pirsgirêkê re mijûl bibin.

Ma pêdivî ye ku hem Ingress û hem jî Egress qeyd bikin?

Bersiva kurt erê ye, ji bo ku pod A bi pod B re danûstendinê bike, pêdivî ye ku destûr were dayîn ku têkiliyek derketinê biafirîne (ji bo vê yekê hûn hewce ne ku polîtîkayek derketinê mîheng bikin), û pod B pêdivî ye ku pêwendiyek dahatî qebûl bike ( Ji bo vê yekê, li gorî vê yekê, hûn hewceyê siyasetek ketinê ye).

Lêbelê, di pratîkê de, hûn dikarin xwe bispêrin polîtîkaya xwerû ku destûrê bide girêdanan di yek an her du rêgezan de.

Heger hindek pod-çavkaniyê dê ji aliyê yek an jî zêdetir bên hilbijartin derketin- Siyasetmedar, qedexeyên li ser wê têne danîn dê bi jihevketina wan diyar bibe. Di vê rewşê de, hûn ê hewce bikin ku bi eşkere destûr bidin girêdana bi pod -muxatab. Ger podek ji hêla ti polîtîkayê ve neyê hilbijartin, seyrûsefera wê ya derketinê (derketinê) ji hêla xwerû ve tê destûr kirin.

Bi heman awayî, çarenûsa pod emuxatab, ji hêla yek an bêtir ve hatî hilbijartin ketin- Siyasetmedar, dê bi jihevketina xwe diyar bibin. Di vê rewşê de, divê hûn bi eşkere destûr bidin ku ew seyrûseferê ji podê çavkaniyê werbigire. Ger podek ji hêla ti polîtîkayê ve neyê hilbijartin, hemî seyrûsefera têketinê ji bo wê ji hêla xwerû ve tê destûr kirin.

Li jêrê Dewlet an Bêwelatî bibînin.

Logs

Polîtîkayên torê yên Kubernetes nikarin seyrûseferê têkevin. Ev yek dijwar dike ku meriv diyar bike ka siyasetek wekî ku tê xwestin dixebite û analîza ewlehiyê pir tevlihev dike.

Kontrolkirina seyrûsefera karûbarên derveyî

Polîtîkayên torê yên Kubernetes nahêlin ku hûn di beşên derketinê de navek domainek bi tevahî jêhatî (DNS) diyar bikin. Ev rastî dibe sedema nerehetiyek girîng dema ku hewl didin ku seyrûseferê li cîhên derveyî yên ku xwedan navnîşek IP-ya sabît nînin sînordar bikin (wek aws.com).

Check Policy

Firewall dê we hişyar bikin an tewra jî red bikin ku hûn siyaseta xelet qebûl bikin. Kubernetes jî hin verastkirinê dike. Dema ku bi kubectl re polîtîkaya torê saz dike, dibe ku Kubernetes diyar bike ku ew nerast e û qebûl neke. Di rewşên din de, Kubernetes dê siyasetê bigire û wê bi hûrguliyên winda tije bike. Ew dikarin bi karanîna fermanê werin dîtin:

kubernetes get networkpolicy <policy-name> -o yaml

Bînin bîra xwe ku pergala pejirandina Kubernetes ne xelet e û dibe ku hin celeb xeletiyan winda bike.

Rêvekirin

Kubernetes bi xwe polîtîkayên torê bicîh nayîne, lê tenê dergehek API-yê ye ku barê kontrolê dide pergalek bingehîn a bi navê Navbera Torgiloka Konteyner (CNI). Sazkirina polîtîkayên li ser komek Kubernetes bêyî destnîşankirina CNI-ya guncav eynî wekî afirandina polîtîkayên li ser serverek rêveberiya dîwarê agir e bêyî ku dûv re wan li ser dîwaran saz bike. Ew li ser we ye ku hûn pê ewle bibin ku we CNIyek maqûl heye an, di doza platformên Kubernetes de, di ewr de mêvandar e. (hûn dikarin navnîşa pêşkêşkeran bibînin vir - nêzîkî. trans.), polîtîkayên torê yên ku dê CNI ji we re saz bikin çalak bikin.

Bala xwe bidinê ku Kubernetes dê we hişyar neke ger hûn siyasetek torê bêyî alîkarê guncan CNI saz bikin.

Dewlet an bê dewlet?

Hemî CNI-yên Kubernetes ên ku min pê re rû bi rû ne dewletparêz in (mînakek, Calico girêdana Linux-ê bikar tîne). Ev dihêle ku pod li ser pêwendiya TCP-ê ya ku dest pê kiriye bersivan bistîne bêyî ku ew ji nû ve saz bike. Lêbelê, haya min ji standardek Kubernetes tune ku dê dewletbûnê garantî bike.

Rêvebiriya Polîtîkaya Ewlekariyê ya Pêşkeftî

Li vir çend awayên çêtirkirina sepandina siyaseta ewlehiyê li Kubernetes hene:

1. Nimûneya mîmarî ya Service Mesh konteynerên kêlekê bikar tîne da ku di asta karûbarê de telemetrî û kontrolkirina trafîkê ya berfireh peyda bike. Wek mînak em dikarin bînin Istio.
2. Hin firoşkarên CNI amûrên xwe dirêj kirine ku ji polîtîkayên tora Kubernetes wêdetir biçin.
3. Tufin Orca Dîtin û otomasyona polîtîkayên torê yên Kubernetes peyda dike.

Pakêta Tufin Orca polîtîkayên tora Kubernetes birêve dibe (û çavkaniya dîmenên li jor e).

Ð "опол ниÑ, ÐμÐ »ÑŒÐ½Ð ° Ñ Ð¸Ð½Ñ" Ð¾Ñ € Ñ † мРli DN

• Nimûneyên polîtîkayên torê yên ku Ahmet Alp Balkan ji GKE amade kirine;
• Belge ji malpera fermî ya Kubernetes;
• Rêberek ji bo Modela Tora Kubernetes;
• Skrîpta ji bo kontrolkirina polîtîkayên torê.

encamê

Polîtîkayên torê yên Kubernetes ji bo dabeşkirina koman komek amûrek baş pêşkêşî dikin, lê ew ne xwerû ne û gelek hûrguliyên wan hene. Ji ber vê tevliheviyê, ez bawer dikim ku gelek polîtîkayên komê yên heyî xelet in. Çareseriyên gengaz ên vê pirsgirêkê otomatîkkirina pênaseyên polîtîkayê an jî karanîna amûrên dabeşkirinê yên din in.

Ez hêvî dikim ku ev rêber ji bo zelalkirina hin pirsan û çareserkirina pirsgirêkên ku hûn pê re rû bi rû dimînin dibe alîkar.

PS ji wergêr

Li ser bloga me jî bixwînin:

• "Bi Istio re vegere servîsên mîkro": beş 1 (danasîna taybetmendiyên sereke), beş 2 (rêxistin, kontrolkirina trafîkê), beşa 3 (ewlehî);
• "Rêberek Illustrated ji bo Tora Kubernetes": beşên 1 û 2 (modela torê, torên sergirtî), beşa 3 (xizmet û pêvajoya trafîkê);
• «Docker û Kubernetes di derdorên hesas ên ewlehiyê de»;
• «9 Pratîkên Baştirîn Ewlekariya Kubernetes»;
• «11 Awayên Ku (Ne) Bibin Qurbana Hackek Kubernetes".

Source: www.habr.com