Utangulizi wa Sera za Mtandao wa Kubernetes kwa Wataalamu wa Usalama

Kumbuka. tafsiri.: Mwandishi wa makala, Reuven Harrison, ana uzoefu wa zaidi ya miaka 20 katika uundaji wa programu, na leo ni CTO na mwanzilishi mwenza wa Tufin, kampuni inayounda masuluhisho ya usimamizi wa sera za usalama. Ingawa anatazama sera za mtandao wa Kubernetes kama zana yenye nguvu ya ugawaji wa mtandao katika nguzo, pia anaamini kuwa si rahisi sana kuzitekeleza kwa vitendo. Nyenzo hii (iliyo wazi kabisa) imekusudiwa kuboresha ufahamu wa wataalamu kuhusu suala hili na kuwasaidia kuunda usanidi unaohitajika.

Leo, makampuni mengi yanazidi kuchagua Kubernetes kuendesha maombi yao. Kuvutiwa na programu hii ni kubwa sana hivi kwamba wengine wanaita Kubernetes "mfumo mpya wa uendeshaji wa kituo cha data." Hatua kwa hatua, Kubernetes (au k8s) inaanza kutambuliwa kama sehemu muhimu ya biashara, ambayo inahitaji shirika la michakato ya biashara iliyokomaa, pamoja na usalama wa mtandao.

Kwa wataalamu wa usalama ambao wanashangazwa na kufanya kazi na Kubernetes, ufichuzi halisi unaweza kuwa sera chaguomsingi ya mfumo: ruhusu kila kitu.

Mwongozo huu utakusaidia kuelewa muundo wa ndani wa sera za mtandao; kuelewa jinsi zinavyotofautiana na sheria za firewalls za kawaida. Pia itashughulikia baadhi ya mitego na kutoa mapendekezo ya kusaidia kulinda programu kwenye Kubernetes.

Sera za mtandao za Kubernetes

Utaratibu wa sera ya mtandao wa Kubernetes hukuruhusu kudhibiti mwingiliano wa programu zilizotumwa kwenye jukwaa kwenye safu ya mtandao (ya tatu katika muundo wa OSI). Sera za mtandao hazina baadhi ya vipengele vya juu vya ngome za kisasa, kama vile utekelezaji wa OSI Layer 7 na utambuzi wa vitisho, lakini hutoa kiwango cha msingi cha usalama wa mtandao ambacho ni mahali pazuri pa kuanzia.

Sera za mtandao hudhibiti mawasiliano kati ya maganda

Mzigo wa kazi katika Kubernetes husambazwa kwenye maganda, ambayo yanajumuisha kontena moja au zaidi zilizowekwa pamoja. Kubernetes hukabidhi kila ganda anwani ya IP ambayo inaweza kufikiwa kutoka kwa maganda mengine. Sera za mtandao wa Kubernetes huweka haki za ufikiaji kwa vikundi vya maganda kwa njia ile ile ambayo vikundi vya usalama kwenye wingu vinatumiwa kudhibiti ufikiaji wa matukio ya mashine pepe.

Kufafanua Sera za Mtandao

Kama rasilimali zingine za Kubernetes, sera za mtandao zimebainishwa katika YAML. Katika mfano hapa chini, maombi balance upatikanaji wa 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

(Kumbuka. tafsiri.: picha hii ya skrini, kama zile zingine zinazofuata, iliundwa bila kutumia zana za asili za Kubernetes, lakini kwa kutumia zana ya Tufin Orca, ambayo ilitengenezwa na kampuni ya mwandishi wa nakala asili na ambayo imetajwa mwishoni mwa nyenzo.)

Ili kufafanua sera yako ya mtandao, utahitaji maarifa ya kimsingi ya YAML. Lugha hii inategemea ujongezaji (hubainishwa na nafasi badala ya vichupo). Kipengele kilichojongezwa ni cha kipengele kilicho karibu zaidi kilichowekwa ndani juu yake. Kipengele kipya cha orodha huanza na hyphen, vipengele vingine vyote vina fomu muhimu-thamani.

Baada ya kuelezea sera katika YAML, tumia kubectlkuiunda kwenye nguzo:

kubectl create -f policy.yaml

Uainishaji wa Sera ya Mtandao

Uainishaji wa sera ya mtandao wa Kubernetes inajumuisha vipengele vinne:

1. podSelector: inafafanua maganda yaliyoathiriwa na sera hii (lengo) - inahitajika;
2. policyTypes: inaonyesha ni aina gani za sera zinazojumuishwa katika hili: kuingia na/au kutoroka - kwa hiari, lakini ninapendekeza kubainisha kwa uwazi katika visa vyote;
3. ingress: inafafanua kuruhusiwa zinazoingia trafiki kwa maganda ya lengo - hiari;
4. egress: inafafanua kuruhusiwa anayemaliza muda wake trafiki kutoka kwa maganda lengwa ni ya hiari.

Mfano uliochukuliwa kutoka kwa wavuti ya Kubernetes (nilibadilisha role juu ya app), inaonyesha jinsi vipengele vyote vinne vinatumiwa:

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

Tafadhali kumbuka kuwa vipengele vyote vinne si lazima vijumuishwe. Lazima ni tu podSelector, vigezo vingine vinaweza kutumika kama unavyotaka.

Ukiacha policyTypes, sera itatafsiriwa kama ifuatavyo:

• Kwa chaguo-msingi, inachukuliwa kuwa inafafanua upande wa ingress. Ikiwa sera haisemi hili kwa uwazi, mfumo utachukulia kuwa trafiki yote ni marufuku.
• Tabia kwenye upande wa egress itatambuliwa na uwepo au kutokuwepo kwa parameter inayofanana ya egress.

Ili kuepuka makosa ninapendekeza kila wakati iwe wazi policyTypes.

Kulingana na mantiki hapo juu, ikiwa vigezo ingress na / au egress imeachwa, sera itakataa trafiki yote (angalia "Kanuni ya Kuondoa" hapa chini).

Sera chaguo-msingi Inaruhusu

Ikiwa hakuna sera zilizofafanuliwa, Kubernetes inaruhusu trafiki yote kwa chaguo-msingi. Maganda yote yanaweza kubadilishana habari kwa uhuru kati yao wenyewe. Hili linaweza kuonekana kuwa lisilofaa kutokana na mtazamo wa usalama, lakini kumbuka kuwa Kubernetes iliundwa awali na wasanidi programu ili kuwezesha ushirikiano wa programu. Sera za mtandao ziliongezwa baadaye.

Nafasi za majina

Nafasi za majina ni utaratibu wa ushirikiano wa Kubernetes. Zimeundwa kutenganisha mazingira ya kimantiki kutoka kwa kila mmoja, wakati mawasiliano kati ya nafasi yanaruhusiwa kwa chaguo-msingi.

Kama vipengele vingi vya Kubernetes, sera za mtandao huishi katika nafasi mahususi ya majina. Katika block metadata unaweza kubainisha ni nafasi gani sera ni ya:

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

Ikiwa nafasi ya majina haijabainishwa kwa uwazi katika metadata, mfumo utatumia nafasi ya majina iliyobainishwa katika kubectl (kwa chaguo-msingi. namespace=default):

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

Napendekeza bainisha nafasi ya majina kwa uwazi, isipokuwa unaandika sera inayolenga nafasi nyingi za majina kwa wakati mmoja.

Ya kuu kipengee podSelector katika sera itachagua maganda kutoka kwa nafasi ya majina ambayo sera inamiliki (imenyimwa ufikiaji wa maganda kutoka kwa nafasi nyingine ya jina).

Vile vile, podSelectors katika vitalu vya kuingia na kutoka inaweza tu kuchagua maganda kutoka kwa nafasi yao ya majina, isipokuwa bila shaka utayachanganya nayo namespaceSelector (hii itajadiliwa katika sehemu ya "Chuja kwa nafasi za majina na maganda").

Kanuni za Kutaja Sera

Majina ya sera ni ya kipekee ndani ya nafasi sawa ya majina. Hakuwezi kuwa na sera mbili zilizo na jina moja katika nafasi moja, lakini kunaweza kuwa na sera zilizo na jina moja katika nafasi tofauti. Hii ni muhimu unapotaka kutumia tena sera sawa katika nafasi nyingi.

Ninapenda sana mojawapo ya njia za kutaja. Inajumuisha kuchanganya jina la nafasi ya majina na maganda lengwa. Kwa mfano:

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

Lebo

Unaweza kuambatisha lebo maalum kwa vipengee vya Kubernetes, kama vile maganda na nafasi za majina. Lebo (maandiko - tags) ni sawa na tagi kwenye wingu. Sera za mtandao za Kubernetes hutumia lebo kuchagua magandaambazo zinatumika:

podSelector:
  matchLabels:
    role: db

... au nafasi za majinaambazo zinatumika. Mfano huu huchagua maganda yote katika nafasi za majina zilizo na lebo zinazolingana:

namespaceSelector:
  matchLabels:
    project: myproject

Tahadhari moja: wakati wa kutumia namespaceSelector hakikisha nafasi za majina unazochagua zina lebo sahihi. Fahamu kuwa nafasi za majina zilizojengwa kama vile default и kube-system, kwa chaguo-msingi hazina lebo.

Unaweza kuongeza lebo kwenye nafasi kama hii:

kubectl label namespace default namespace=default

Wakati huo huo, nafasi ya majina katika sehemu metadata inapaswa kurejelea jina halisi la nafasi, sio lebo:

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

Chanzo na marudio

Sera za Firewall zinajumuisha sheria zilizo na vyanzo na maeneo. Sera za mtandao za Kubernetes zimefafanuliwa kwa lengo - seti ya maganda ambayo zinatumika - na kisha kuweka sheria za kuingia na/au kutoka kwa trafiki. Katika mfano wetu, sera inayolengwa itakuwa maganda yote kwenye nafasi ya majina default yenye lebo yenye ufunguo app na thamani 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

Kifungu kidogo ingress katika sera hii, hufungua trafiki inayoingia kwa maganda lengwa. Kwa maneno mengine, ingress ni chanzo na lengo ni marudio sambamba. Kadhalika, kutoka ni marudio na lengo ni chanzo chake.

Hii ni sawa na sheria mbili za ngome: Ingress → Lengo; Lengo → Egress.

Egress na DNS (muhimu!)

Kwa kupunguza trafiki inayotoka, kulipa kipaumbele maalum kwa DNS - Kubernetes hutumia huduma hii kuweka huduma ramani kwa anwani za IP. Kwa mfano, sera ifuatayo haitafanya kazi kwa sababu hujaruhusu programu balance fikia 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

Unaweza kuirekebisha kwa kufungua ufikiaji wa huduma ya 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
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

Kipengele cha mwisho to ni tupu, na kwa hivyo huchagua kwa njia isiyo ya moja kwa moja maganda yote katika nafasi zote za majina, kuruhusu balance tuma hoja za DNS kwa huduma inayofaa ya Kubernetes (kawaida hutumika kwenye nafasi kube-system).

Njia hii inafanya kazi, hata hivyo kuruhusiwa kupita kiasi na kukosa usalama, kwa sababu inaruhusu maswali ya DNS kuelekezwa nje ya nguzo.

Unaweza kuiboresha katika hatua tatu mfululizo.

1. Ruhusu hoja za DNS pekee ndani nguzo kwa kuongeza 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. Ruhusu hoja za DNS ndani ya nafasi ya majina pekee kube-system.

Ili kufanya hivyo unahitaji kuongeza lebo kwenye nafasi ya majina kube-system: kubectl label namespace kube-system namespace=kube-system - na uandike kwa kutumia sera 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. Watu wenye hasira wanaweza kwenda mbali zaidi na kudhibiti hoja za DNS kwa huduma mahususi ya DNS kube-system. Sehemu "Chuja kwa nafasi za majina NA pods" itakuambia jinsi ya kufikia hili.

Chaguo jingine ni kutatua DNS katika kiwango cha nafasi ya majina. Katika kesi hii, haitahitaji kufunguliwa kwa kila huduma:

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

Tupu podSelector huchagua maganda yote kwenye nafasi ya majina.

Mechi ya kwanza na utaratibu wa sheria

Katika ngome za kawaida, kitendo (Ruhusu au Kataa) kwenye pakiti imedhamiriwa na sheria ya kwanza ambayo inakidhi. Katika Kubernetes, mpangilio wa sera haujalishi.

Kwa chaguo-msingi, wakati hakuna sera zilizowekwa, mawasiliano kati ya maganda yanaruhusiwa na wanaweza kubadilishana habari kwa uhuru. Pindi tu unapoanza kutunga sera, kila ganda lililoathiriwa na angalau mojawapo hutengwa kulingana na mtengano (mantiki AU) wa sera zote zilizoichagua. Maganda ambayo hayajaathiriwa na sera yoyote hubaki wazi.

Unaweza kubadilisha tabia hii kwa kutumia sheria ya kuondoa.

Sheria ya kuondoa ("Kataa")

Sera za ngome kwa kawaida hukataa trafiki yoyote ambayo hairuhusiwi waziwazi.

Hakuna hatua ya kukanusha katika Kubernetes, hata hivyo, athari sawa inaweza kupatikana kwa sera ya kawaida (ruhusa) kwa kuchagua kikundi tupu cha maganda ya chanzo (ingress):

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

Sera hii huteua maganda yote katika nafasi ya majina na kuacha ingress bila kufafanuliwa, na kukataa trafiki yote inayoingia.

Vivyo hivyo, unaweza kuzuia trafiki yote inayotoka kutoka kwa nafasi ya majina:

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

Tafadhali kumbuka kuwa sera zozote za ziada zinazoruhusu trafiki kwa maganda katika nafasi ya majina zitachukua kipaumbele juu ya sheria hii (sawa na kuongeza sheria ya kuruhusu kabla ya sheria ya kukataa katika usanidi wa firewall).

Ruhusu kila kitu (Yoyote-Yoyote-Yoyote-Ruhusu)

Ili kuunda sera ya Ruhusu Yote, unahitaji kuongeza sera ya Kataa kwa kipengele kisicho na kitu ingress:

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

Inaruhusu ufikiaji kutoka maganda yote katika nafasi zote za majina (na IP zote) kwa ganda lolote kwenye nafasi ya majina default. Tabia hii imewezeshwa na chaguo-msingi, kwa hivyo kawaida haihitaji kufafanuliwa zaidi. Hata hivyo, wakati mwingine unaweza kuhitaji kuzima kwa muda baadhi ya ruhusa maalum ili kutambua tatizo.

Sheria inaweza kupunguzwa ili kuruhusu ufikiaji tu kwa seti maalum ya maganda (app:balance) katika nafasi ya majina default:

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

Sera ifuatayo inaruhusu trafiki yote ya kuingia na kutoka, ikijumuisha ufikiaji wa IP yoyote nje ya nguzo:

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

Kuchanganya Sera Nyingi

Sera zinaunganishwa kwa kutumia mantiki AU katika viwango vitatu; Ruhusa za kila pod zimewekwa kwa mujibu wa mtengano wa sera zote zinazoiathiri:

1. Mashambani from и to Aina tatu za vitu zinaweza kufafanuliwa (zote zimeunganishwa kwa kutumia AU):

• namespaceSelector - chagua nafasi nzima ya majina;
• podSelector - huchagua maganda;
• ipBlock — huchagua subnet.

Aidha, idadi ya vipengele (hata vile vinavyofanana) katika vifungu from/to sio mdogo. Zote zitaunganishwa kwa mantiki AU.

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. Ndani ya sehemu ya sera ingress inaweza kuwa na vipengele vingi from (pamoja na mantiki AU). Vile vile, sehemu egress inaweza kujumuisha vipengele vingi to (pia imejumuishwa na mgawanyiko):

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. Sera tofauti pia zimeunganishwa na mantiki AU

Lakini wakati wa kuzichanganya, kuna kizuizi kimoja ambacho alisema Chris Cooney: Kubernetes inaweza tu kuchanganya sera na tofauti policyTypes (Ingress au Egress) Sera zinazofafanua ingress (au egress) zitabatiliana.

Uhusiano kati ya nafasi za majina

Kwa chaguo-msingi, kushiriki habari kati ya nafasi za majina kunaruhusiwa. Hii inaweza kubadilishwa kwa kutumia sera ya kukataa ambayo itazuia trafiki inayotoka na/au inayoingia kwenye nafasi ya majina (ona "Kanuni ya Kuondoa" hapo juu).

Mara baada ya kuzuia ufikiaji wa nafasi ya majina (tazama "Kanuni ya Kuondoa" hapo juu), unaweza kufanya vighairi kwa sera ya kukataa kwa kuruhusu miunganisho kutoka kwa nafasi maalum ya majina kwa kutumia. 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

Kama matokeo, maganda yote kwenye nafasi ya majina default itakuwa na ufikiaji wa maganda postgres katika nafasi ya majina database. Lakini vipi ikiwa unataka kufungua ufikiaji postgres maganda maalum pekee kwenye nafasi ya majina default?

Chuja kwa nafasi za majina na maganda

Toleo la Kubernetes 1.11 na la juu zaidi hukuruhusu kuchanganya waendeshaji namespaceSelector и podSelector kwa kutumia mantiki NA. Inaonekana kama hii:

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

Kwa nini hii inatafsiriwa kama NA badala ya ile ya kawaida AU?

Tafadhali kumbuka kuwa podSelector haianzi na kistari. Katika YAML hii ina maana kwamba podSelector na kusimama mbele yake namespaceSelector rejelea kipengele cha orodha sawa. Kwa hiyo, wao ni pamoja na mantiki NA.

Inaongeza hyphen kabla podSelector itasababisha kuibuka kwa kipengele kipya cha orodha, ambacho kitaunganishwa na kilichotangulia namespaceSelector kwa kutumia mantiki AU.

Ili kuchagua maganda yaliyo na lebo maalum katika nafasi zote za majina, weka wazi 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

Lebo nyingi huungana na I

Sheria za ngome yenye vitu vingi (wenyeji, mitandao, vikundi) zimeunganishwa kwa kutumia mantiki AU. Sheria ifuatayo itafanya kazi ikiwa chanzo cha pakiti kinalingana Host_1 Au Host_2:

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

Kinyume chake, katika Kubernetes lebo mbalimbali katika podSelector au namespaceSelector zimeunganishwa na mantiki NA. Kwa mfano, sheria ifuatayo itachagua maganda ambayo yana lebo zote mbili, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Mantiki hiyo hiyo inatumika kwa aina zote za waendeshaji: viteuzi lengwa vya sera, viteuzi vya pod na viteuzi vya nafasi ya majina.

Subnets na anwani za IP (IPBlocks)

Firewalls hutumia VLAN, anwani za IP, na subnets kugawa mtandao.

Katika Kubernetes, anwani za IP hupewa ganda kiotomatiki na zinaweza kubadilika mara kwa mara, kwa hivyo lebo hutumiwa kuchagua maganda na nafasi za majina katika sera za mtandao.

Nyanda ndogo (ipBlocks) hutumika wakati wa kudhibiti miunganisho inayoingia (ingress) au inayotoka (egress) ya nje (Kaskazini-Kusini). Kwa mfano, sera hii inafungua kwa maganda yote kutoka kwa nafasi ya majina default ufikiaji wa huduma ya 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

Kiteuzi tupu cha ganda katika mfano huu kinamaanisha "chagua maganda yote kwenye nafasi ya majina."

Sera hii inaruhusu ufikiaji wa 8.8.8.8 pekee; ufikiaji wa IP nyingine yoyote ni marufuku. Kwa hivyo, kimsingi, umezuia ufikiaji wa huduma ya ndani ya Kubernetes DNS. Ikiwa bado unataka kuifungua, onyesha hii kwa uwazi.

Kawaida ipBlocks и podSelectors hazitengani, kwani anwani za IP za ndani za maganda hazitumiki ipBlocks. Kwa kuashiria maganda ya ndani ya IP, kwa kweli utaruhusu miunganisho ya/kutoka kwa maganda yenye anwani hizi. Kwa mazoezi, hutajua ni anwani gani ya IP ya kutumia, ndiyo sababu haipaswi kutumiwa kuchagua maganda.

Kama mfano wa kupinga, sera ifuatayo inajumuisha IP zote na kwa hivyo inaruhusu ufikiaji wa maganda mengine yote:

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

Unaweza kufungua ufikiaji wa IP za nje pekee, ukiondoa anwani za IP za ndani za maganda. Kwa mfano, ikiwa subnet ya ganda lako ni 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

Bandari na itifaki

Kwa kawaida maganda husikiliza lango moja. Hii inamaanisha kuwa huwezi kubainisha nambari za mlango katika sera na kuacha kila kitu kama chaguomsingi. Walakini, inashauriwa kuweka sera ziwe na vizuizi iwezekanavyo, kwa hivyo katika hali zingine bado unaweza kubainisha bandari:

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

Kumbuka kwamba kiteuzi ports inatumika kwa vipengele vyote kwenye block to au from, ambayo ina. Ili kutaja bandari tofauti za seti tofauti za vipengele, gawanya ingress au egress katika vifungu kadhaa na to au from na katika kila usajili bandari zako:

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

Operesheni chaguomsingi ya mlango:

• Ukiacha ufafanuzi wa bandari kabisa (ports), hii ina maana itifaki zote na bandari zote;
• Ukiacha ufafanuzi wa itifaki (protocol), hii ina maana TCP;
• Ukiacha ufafanuzi wa bandari (port), hii inamaanisha bandari zote.

Mbinu bora: Usitegemee maadili chaguo-msingi, taja unachohitaji kwa uwazi.

Tafadhali kumbuka kuwa lazima utumie bandari za ganda, sio bandari za huduma (zaidi juu ya hii katika aya inayofuata).

Je, sera zimefafanuliwa kwa maganda au huduma?

Kwa kawaida, maganda katika Kubernetes hupatana kupitia huduma - kiweka usawazishaji cha upakiaji ambacho huelekeza trafiki kwenye maganda yanayotekeleza huduma. Unaweza kufikiria kuwa sera za mtandao zinadhibiti ufikiaji wa huduma, lakini sivyo. Sera za mtandao za Kubernetes hufanya kazi kwenye bandari za ganda, si bandari za huduma.

Kwa mfano, ikiwa huduma inasikiliza bandari 80, lakini ielekeze trafiki kwenye bandari 8080 ya maganda yake, lazima ubainishe haswa 8080 katika sera ya mtandao.

Utaratibu kama huo unapaswa kuzingatiwa kuwa haufai: ikiwa muundo wa ndani wa huduma (bandari ambazo maganda yake husikiza) itabadilika, sera za mtandao zitalazimika kusasishwa.

Mbinu mpya ya usanifu kwa kutumia Service Mesh (kwa mfano, angalia kuhusu Istio hapa chini - takriban. transl.) inakuwezesha kukabiliana na tatizo hili.

Je, ni muhimu kusajili Ingress na Egress?

Jibu fupi ni ndiyo, ili pod A iwasiliane na ganda B, lazima iruhusiwe kuunda muunganisho unaotoka (kwa hili unahitaji kusanidi sera ya egress), na pod B lazima iweze kukubali muunganisho unaoingia ( kwa hili, ipasavyo, unahitaji sera ya ingress). sera).

Hata hivyo, kiutendaji, unaweza kutegemea sera chaguo-msingi ili kuruhusu miunganisho katika pande moja au zote mbili.

Ikiwa ganda fulani-chanzo itachaguliwa na mmoja au zaidi egress-wanasiasa, vikwazo vilivyowekwa juu yake vitaamuliwa na kutengana kwao. Katika kesi hii, utahitaji kuruhusu wazi uunganisho kwenye ganda -kwa mhusika. Ikiwa ganda halijachaguliwa na sera yoyote, trafiki yake inayotoka (egress) inaruhusiwa kwa chaguomsingi.

Vile vile, hatima ya pod nimwajiriwa, iliyochaguliwa na mmoja au zaidi ingress-wanasiasa, wataamuliwa kwa kutengana kwao. Katika kesi hii, lazima uiruhusu kwa uwazi kupokea trafiki kutoka kwa ganda la chanzo. Ikiwa ganda halijachaguliwa na sera yoyote, trafiki yote ya kuingia kwake inaruhusiwa kwa chaguo-msingi.

Tazama Wasio na Uraia hapa chini.

Kumbukumbu

Sera za mtandao za Kubernetes haziwezi kuweka trafiki. Hii inafanya kuwa vigumu kubainisha ikiwa sera inafanya kazi inavyokusudiwa na inatatiza sana uchanganuzi wa usalama.

Udhibiti wa trafiki kwa huduma za nje

Sera za mtandao za Kubernetes hazikuruhusu kubainisha jina la kikoa lililohitimu kikamilifu (DNS) katika sehemu za egress. Ukweli huu husababisha usumbufu mkubwa wakati wa kujaribu kuzuia trafiki kwa maeneo ya nje ambayo hayana anwani ya IP isiyobadilika (kama vile aws.com).

Ukaguzi wa Sera

Firewalls itakuonya au hata kukataa kukubali sera isiyo sahihi. Kubernetes pia hufanya uthibitishaji fulani. Wakati wa kuweka sera ya mtandao kupitia kubectl, Kubernetes inaweza kutangaza kuwa si sahihi na kukataa kuikubali. Katika hali nyingine, Kubernetes itachukua sera na kuijaza na maelezo yanayokosekana. Wanaweza kuonekana kwa kutumia amri:

kubernetes get networkpolicy <policy-name> -o yaml

Kumbuka kwamba mfumo wa uthibitishaji wa Kubernetes haukosei na unaweza kukosa aina fulani za hitilafu.

Utekelezaji

Kubernetes haitekelezi sera za mtandao yenyewe, lakini ni lango tu la API ambalo hukabidhi mzigo wa udhibiti kwa mfumo msingi unaoitwa Container Networking Interface (CNI). Kuweka sera kwenye kundi la Kubernetes bila kukabidhi CNI inayofaa ni sawa na kuunda sera kwenye seva ya usimamizi wa ngome bila kuzisakinisha kwenye ngome. Ni juu yako kuhakikisha kuwa una CNI nzuri au, kwa upande wa mifumo ya Kubernetes, inayopangishwa katika wingu. (unaweza kuona orodha ya watoa huduma hapa - takriban. trans.), wezesha sera za mtandao ambazo zitakuwekea CNI.

Kumbuka kuwa Kubernetes haitakuonya ikiwa utaweka sera ya mtandao bila CNI msaidizi anayefaa.

Nchi au isiyo na Raia?

Kubernetes CNI zote ambazo nimekutana nazo ni za hali ya juu (kwa mfano, Calico hutumia uingiliaji wa Linux). Hii huruhusu ganda kupokea majibu kwenye muunganisho wa TCP ulioanzisha bila kulazimika kukianzisha tena. Walakini, sijui kiwango cha Kubernetes ambacho kinaweza kuhakikisha hali ya utulivu.

Usimamizi wa Sera ya Usalama ya Juu

Hapa kuna baadhi ya njia za kuboresha utekelezaji wa sera ya usalama katika Kubernetes:

1. Mchoro wa usanifu wa Mesh ya Huduma hutumia kontena za kando ili kutoa telemetry ya kina na udhibiti wa trafiki katika kiwango cha huduma. Kama mfano tunaweza kuchukua Istio.
2. Baadhi ya wachuuzi wa CNI wamepanua zana zao kwenda zaidi ya sera za mtandao za Kubernetes.
3. Tufin Orca Hutoa mwonekano na otomatiki wa sera za mtandao za Kubernetes.

Kifurushi cha Tufin Orca hudhibiti sera za mtandao za Kubernetes (na ndicho chanzo cha picha za skrini hapo juu).

maelezo ya ziada

• Mifano ya sera za mtandao zilizotayarishwa na Ahmet Alp Balkan kutoka GKE;
• Hati kutoka kwa tovuti rasmi ya Kubernetes;
• Mwongozo wa Muundo wa Mtandao wa Kubernetes;
• Hati ya kuangalia sera za mtandao.

Hitimisho

Sera za mtandao za Kubernetes hutoa seti nzuri ya zana za kugawanya makundi, lakini si angavu na zina hila nyingi. Kwa sababu ya ugumu huu, ninaamini sera nyingi za nguzo zilizopo ni za hitilafu. Suluhisho zinazowezekana kwa tatizo hili ni pamoja na ufafanuzi wa kiotomatiki wa sera au kutumia zana zingine za ugawaji.

Natumai mwongozo huu utasaidia kusuluhisha baadhi ya maswali na kutatua masuala ambayo unaweza kukutana nayo.

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

• "Rudi kwa huduma ndogo na Istio": Sehemu ya 1 (utangulizi wa sifa kuu), Sehemu ya 2 (kuelekeza, kudhibiti trafiki), Sehemu ya 3 (Usalama);
• "Mwongozo Ulioonyeshwa kwa Mtandao katika Kubernetes": sehemu ya 1 na 2 (mfano wa mtandao, mitandao inayowekelea), Sehemu ya 3 (huduma na usindikaji wa trafiki);
• «Docker na Kubernetes katika mazingira nyeti kwa usalama";
• «Mbinu 9 Bora za Usalama wa Kubernetes";
• «Njia 11 za (Si) Kuwa Mwathirika wa Udukuzi wa Kubernetes'.

Chanzo: mapenzi.com