Увод у Кубернетес мрежне политике за професионалце у области безбедности

Белешка. трансл.: Аутор чланка, Реувен Харрисон, има преко 20 година искуства у развоју софтвера, а данас је ЦТО и суоснивач Туфина, компаније која креира решења за управљање безбедносном политиком. Док он посматра Кубернетес мрежне политике као прилично моћан алат за сегментацију мреже у кластеру, он такође верује да их није тако лако применити у пракси. Овај материјал (прилично обиман) има за циљ да побољша свест стручњака о овом проблему и помогне им да направе неопходне конфигурације.

Данас многе компаније све више бирају Кубернетес за покретање својих апликација. Интересовање за овај софтвер је толико велико да неки Кубернетес називају „новим оперативним системом за центар података“. Постепено, Кубернетес (или к8с) почиње да се доживљава као критични део пословања, који захтева организацију зрелих пословних процеса, укључујући и безбедност мреже.

За стручњаке за безбедност који су збуњени радом са Кубернетесом, право откриће може бити подразумевана политика платформе: дозволи све.

Овај водич ће вам помоћи да разумете унутрашњу структуру мрежних политика; разумеју по чему се разликују од правила за обичне заштитне зидове. Такође ће покрити неке замке и дати препоруке које ће помоћи да се обезбеде апликације на Кубернетес-у.

Кубернетес мрежне смернице

Механизам Кубернетес мрежних политика вам омогућава да управљате интеракцијом апликација распоређених на платформи на мрежном слоју (трећи у ОСИ моделу). Мрежним политикама недостају неке од напредних карактеристика модерних заштитних зидова, као што су примена ОСИ слоја 7 и откривање претњи, али оне пружају основни ниво мрежне безбедности који је добра полазна тачка.

Мрежне политике контролишу комуникацију између подова

Радна оптерећења у Кубернетес-у су распоређена на подове, који се састоје од једног или више контејнера који су распоређени заједно. Кубернетес сваком модулу додељује ИП адресу којој се може приступити из других модула. Кубернетес мрежне смернице постављају права приступа за групе подова на исти начин на који се безбедносне групе у облаку користе за контролу приступа инстанцама виртуелне машине.

Дефинисање мрежних политика

Као и други Кубернетес ресурси, мрежне политике су наведене у ИАМЛ-у. У примеру испод, апликација balance приступ 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

(Белешка. трансл.: овај снимак екрана, као и сви следећи слични, није направљен коришћењем изворних Кубернетес алата, већ помоћу алата Туфин Орца, који је развила компанија аутора оригиналног чланка и који се помиње на крају материјала.)

Да бисте дефинисали сопствену мрежну политику, биће вам потребно основно знање о ИАМЛ-у. Овај језик је заснован на увлачењу (наведеном размацима, а не табулаторима). Увучени елемент припада најближем увученом елементу изнад њега. Нови елемент листе почиње цртицом, сви остали елементи имају облик кључ/вредност.

Пошто сте описали политику у ИАМЛ-у, користите кубецтлда га креирате у кластеру:

kubectl create -f policy.yaml

Спецификација мрежне политике

Спецификација Кубернетес мрежне политике укључује четири елемента:

1. podSelector: дефинише подове на које утиче ова политика (циљеви) - обавезно;
2. policyTypes: означава које врсте политика су укључене у ово: улаз и/или излаз - опционо, али препоручујем да се то експлицитно наведе у свим случајевима;
3. ingress: дефинише дозвољено долазни саобраћај до циљних махуна - опционо;
4. egress: дефинише дозвољено одлазни саобраћај из циљних махуна је опциони.

Пример преузет са веб локације Кубернетес (заменио сам role на app), показује како се користе сва четири елемента:

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

Имајте на уму да сва четири елемента не морају бити укључена. То је само обавезно podSelector, други параметри се могу користити по жељи.

Ако изоставите policyTypes, политика ће се тумачити на следећи начин:

• Подразумевано, претпоставља се да дефинише улазну страну. Ако политика то изричито не наводи, систем ће претпоставити да је сав саобраћај забрањен.
• Понашање на излазној страни биће одређено присуством или одсуством одговарајућег излазног параметра.

Да бисте избегли грешке, препоручујем увек изричите policyTypes.

Према наведеној логици, ако параметри ingress и / или egress изостављено, политика ће ускратити сав саобраћај (погледајте „Правило уклањања“ у наставку).

Подразумевана политика је Дозволи

Ако ниједна политика није дефинисана, Кубернетес подразумевано дозвољава сав саобраћај. Све махуне могу слободно да размењују информације међу собом. Ово може изгледати контраинтуитивно из безбедносне перспективе, али запамтите да су Кубернетес првобитно дизајнирали програмери да омогући интероперабилност апликација. Мрежне смернице су додате касније.

Намеспацес

Простори имена су механизам за сарадњу у Кубернетесу. Они су дизајнирани да изолују логичка окружења једно од другог, док је комуникација између простора подразумевано дозвољена.

Као и већина Кубернетес компоненти, мрежне политике живе у одређеном именском простору. У блоку metadata можете одредити којем простору политика припада:

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

Ако простор имена није експлицитно наведен у метаподацима, систем ће користити простор имена наведен у кубецтл (подразумевано namespace=default):

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

Препоручујем експлицитно наведите простор имена, осим ако не пишете политику која циља више именских простора одједном.

Основни елемент podSelector у политици ће изабрати подове из именског простора коме политика припада (забрањен је приступ подовима из другог именског простора).

Слично, подСелецторс у улазним и излазним блоковима може да бира само подове из сопственог именског простора, осим ако их, наравно, не комбинујете са namespaceSelector (о томе ће бити речи у одељку „Филтрирај по именским просторима и подовима“).

Правила именовања политике

Називи смерница су јединствени у оквиру истог именског простора. Не могу постојати две политике са истим именом у истом простору, али могу постојати политике са истим именом у различитим просторима. Ово је корисно када желите да поново примените исту политику на више простора.

Посебно ми се свиђа једна од метода именовања. Састоји се од комбиновања имена именског простора са циљним подовима. На пример:

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

Етикете

Кубернетес објектима, као што су подови и простори имена, можете приложити прилагођене ознаке. Ознаке (етикете - ознаке) су еквивалент ознакама у облаку. Кубернетес мрежне смернице користе ознаке за избор подсна које се примењују:

podSelector:
  matchLabels:
    role: db

… или именских просторана које се примењују. Овај пример бира све подове у именским просторима са одговарајућим ознакама:

namespaceSelector:
  matchLabels:
    project: myproject

Једно упозорење: приликом употребе namespaceSelector уверите се да простори имена које изаберете садрже исправну ознаку. Имајте на уму да уграђени простори имена као што су default и kube-system, подразумевано не садрже ознаке.

Можете додати ознаку у простор овако:

kubectl label namespace default namespace=default

Истовремено, именски простор у одељку metadata треба да се односи на стварно име простора, а не на ознаку:

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

Извор и одредиште

Политика заштитног зида се састоји од правила са изворима и одредиштима. Кубернетес мрежне смернице се дефинишу за циљ – скуп подова на које се примењују – а затим постављају правила за улазни и/или излазни саобраћај. У нашем примеру, циљ политике ће бити сви подови у именском простору default са етикетом са кључем app и значење 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

Пододељак ingress у овој политици, отвара долазни саобраћај ка циљним подовима. Другим речима, улаз је извор, а циљ одговарајуће одредиште. Исто тако, излаз је одредиште, а циљ је његов извор.

Ово је еквивалентно два правила заштитног зида: Улаз → Циљ; Циљ → Излазак.

Излаз и ДНС (важно!)

Ограничавањем одлазног саобраћаја, обратите посебну пажњу на ДНС - Кубернетес користи ову услугу за мапирање услуга на ИП адресе. На пример, следећа смерница неће радити јер нисте дозволили апликацију balance приступ ДНС-у:

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

Можете то поправити отварањем приступа ДНС сервису:

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

Последњи елемент to је празан, па стога индиректно бира сви подови у свим именским просторима, дозвољавајући balance шаљите ДНС упите одговарајућој Кубернетес услузи (обично ради у простору kube-system).

Овај приступ функционише, како год претерано попустљив и несигуран, јер омогућава да се ДНС упити усмере ван кластера.

Можете га побољшати у три узастопна корака.

1. Дозволите само ДНС упите унутар кластер додавањем 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. Дозволите ДНС упите само унутар именског простора kube-system.

Да бисте то урадили, потребно је да додате ознаку именском простору kube-system: kubectl label namespace kube-system namespace=kube-system - и запишите то у коришћењу политике 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. Параноични људи могу ићи још даље и ограничити ДНС упите на одређену ДНС услугу kube-system. Одељак „Филтрирај по именским просторима И подовима“ ће вам рећи како да то постигнете.

Друга опција је да се ДНС реши на нивоу именског простора. У овом случају, неће требати да се отвара за сваку услугу:

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

Prazan podSelector бира све подове у именском простору.

Прво подударање и редослед правила

У конвенционалним заштитним зидовима, акција (Дозволи или Одбиј) на пакету је одређена првим правилом које он задовољава. У Кубернетесу редослед политика није битан.

Подразумевано, када није постављена ниједна политика, комуникација између подова је дозвољена и они могу слободно да размењују информације. Једном када почнете да формулишете смернице, свака група на коју утиче бар једна од њих постаје изолована у складу са дисјунцијом (логичко ИЛИ) свих смерница које су га одабрале. Подови на које не утиче ниједна политика остају отворени.

Ово понашање можете променити помоћу правила уклањања.

Правило скидања („Одбиј“)

Смернице заштитног зида обично одбијају сваки саобраћај који није изричито дозвољен.

У Кубернетесу нема акције одбијања, међутим, сличан ефекат се може постићи редовном (пермисивном) политиком избором празне групе изворних подова (улаз):

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

Ова политика бира све подове у именском простору и оставља улаз недефинисаним, одбијајући сав долазни саобраћај.

На сличан начин можете ограничити сав одлазни саобраћај из именског простора:

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

Обратите пажњу на то све додатне смернице које дозвољавају саобраћај ка подовима у именском простору имаће предност над овим правилом (слично додавању правила дозволе пре правила забране у конфигурацији заштитног зида).

Дозволи све (Било који-било-било-допусти)

Да бисте креирали смерницу Дозволи све, морате да допуните горњу смерницу забране са празним елементом ingress:

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

Омогућава приступ из све подове у свим именским просторима (и све ИП адресе) на било који под у именском простору default. Ово понашање је подразумевано омогућено, тако да га обично не треба даље дефинисати. Међутим, понекад ћете можда морати да привремено онемогућите неке специфичне дозволе да бисте дијагностиковали проблем.

Правило се може сузити да дозволи приступ само за одређени скуп махуна (app:balance) у именском простору default:

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

Следеће смернице дозвољавају сав улазни и излазни саобраћај, укључујући приступ било којој ИП адреси ван кластера:

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

Комбиновање више смерница

Политике се комбинују коришћењем логичког ИЛИ на три нивоа; Дозволе сваке групе су постављене у складу са раздвајањем свих смерница које на њега утичу:

1. На пољима from и to Могу се дефинисати три типа елемената (сви се комбинују помоћу ИЛИ):

• namespaceSelector — бира цео именски простор;
• podSelector — бира махуне;
• ipBlock — бира подмрежу.

Штавише, број елемената (чак и идентичних) у пододељцима from/to није ограничено. Сви они ће бити комбиновани логичким ИЛИ.

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. Унутар одељка о политици ingress може имати много елемената from (комбиновано логичким ИЛИ). Слично, одељак egress може укључивати многе елементе to (такође комбиновано дисјункцијом):

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. Различите политике се такође комбинују са логичким ИЛИ

Али када их комбинујете, постоји једно ограничење истакнуто Цхрис Цоонеи: Кубернетес може комбиновати само смернице са различитим policyTypes (Ingress или Egress). Политике које дефинишу улаз (или излаз) ће заменити једна другу.

Однос између именских простора

Подразумевано, дељење информација између именских простора је дозвољено. Ово се може променити коришћењем политике забране која ће ограничити одлазни и/или долазни саобраћај у простор имена (погледајте „Правило уклањања“ изнад).

Једном када блокирате приступ именском простору (погледајте „Правило уклањања“ изнад), можете направити изузетке од политике одбијања тако што ћете дозволити везе из одређеног именског простора користећи 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

Као резултат, сви подови у именском простору default имаће приступ подс postgres у именском простору database. Али шта ако желите да отворите приступ postgres само одређене подове у именском простору default?

Филтрирајте по именским просторима и подовима

Кубернетес верзија 1.11 и новије вам омогућавају комбиновање оператора namespaceSelector и podSelector користећи логичко И. То изгледа овако:

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

Зашто се ово тумачи као И уместо уобичајеног ИЛИ?

Имајте на уму да podSelector не почиње цртицом. У ИАМЛ-у то значи да podSelector и стојећи пред њим namespaceSelector односе се на исти елемент листе. Стога су комбиновани са логичким И.

Додавање цртице пре podSelector резултираће појавом новог елемента листе, који ће бити комбинован са претходним namespaceSelector користећи логичко ИЛИ.

Да бисте изабрали махуне са одређеном ознаком у свим именским просторима, унесите празно 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

Више етикета се удружује са И

Правила за заштитни зид са више објеката (хостови, мреже, групе) се комбинују коришћењем логичког ИЛИ. Следеће правило ће функционисати ако се извор пакета подудара Host_1 ИЛИ Host_2:

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

Напротив, у Кубернетесу различите ознаке у podSelector или namespaceSelector су комбиновани са логичким И. На пример, следеће правило ће изабрати подове који имају обе ознаке, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Иста логика се примењује на све типове оператора: бираче циља политике, селекторе под и бираче простора имена.

Подмреже и ИП адресе (ИПБлоцкови)

Заштитни зидови користе ВЛАН-ове, ИП адресе и подмреже да сегментирају мрежу.

У Кубернетес-у, ИП адресе се аутоматски додељују подовима и могу се често мењати, тако да се ознаке користе за избор модула и именских простора у мрежним смерницама.

Подмреже (ipBlocks) се користе при управљању долазним (улазним) или одлазним (излазним) спољним (север-југ) везама. На пример, ова смерница се отвара за све подове из именског простора default приступ Гоогле ДНС сервису:

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

Празан селектор под у овом примеру значи „изаберите све подове у именском простору.

Ова политика дозвољава приступ само 8.8.8.8; приступ било којој другој ИП адреси је забрањен. Дакле, у суштини, блокирали сте приступ интерној Кубернетес ДНС услузи. Ако и даље желите да га отворите, то изричито назначите.

Обично ipBlocks и podSelectors се међусобно искључују, пошто се интерне ИП адресе подова не користе у ipBlocks. Указивањем интерне ИП под, заправо ћете дозволити везе са/са подова са овим адресама. У пракси, нећете знати коју ИП адресу да користите, због чега их не би требало користити за одабир подова.

Као контра-пример, следећа политика укључује све ИП адресе и стога дозвољава приступ свим осталим подовима:

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

Можете отворити приступ само спољним ИП адресама, искључујући интерне ИП адресе подова. На пример, ако је подмрежа вашег модула 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

Портови и протоколи

Подови обично слушају један порт. То значи да једноставно не можете навести бројеве портова у политикама и оставити све као подразумевано. Међутим, препоручује се да политике буду што рестриктивније, тако да у неким случајевима и даље можете да наведете портове:

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

Имајте на уму да селектор ports односи се на све елементе у блоку to или from, који садржи. Да бисте навели различите портове за различите скупове елемената, поделите ingress или egress на неколико подсекција са to или from и у сваком регистру ваши портови:

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

Подразумевана операција порта:

• Ако потпуно изоставите дефиницију порта (ports), ово значи све протоколе и све портове;
• Ако изоставите дефиницију протокола (protocol), то значи ТЦП;
• Ако изоставите дефиницију порта (port), ово значи све портове.

Најбоља пракса: Не ослањајте се на подразумеване вредности, експлицитно наведите шта вам је потребно.

Имајте на уму да морате користити под портове, а не сервисне портове (више о томе у следећем параграфу).

Да ли су политике дефинисане за модуле или услуге?

Типично, подови у Кубернетес-у приступају једни другима преко услуге - виртуелног балансера оптерећења који преусмерава саобраћај на подове који имплементирају услугу. Можда мислите да мрежне политике контролишу приступ услугама, али то није случај. Кубернетес мрежне смернице раде на портовима за под, а не на сервисним портовима.

На пример, ако услуга слуша порт 80, али преусмерава саобраћај на порт 8080 својих подова, морате да наведете тачно 8080 у мрежној политици.

Такав механизам треба сматрати неоптималним: ако се промени унутрашња структура услуге (чији портови слушају), мрежне политике ће морати да се ажурирају.

Нови архитектонски приступ користећи Сервице Месх (на пример, погледајте о Истио испод – прибл. превод) омогућава вам да се носите са овим проблемом.

Да ли је потребно регистровати и Ингресс и Егресс?

Кратак одговор је да, да би под А могао да комуницира са модулом Б, мора му бити дозвољено да креира одлазну везу (за ово морате да конфигуришете излазну политику), а под Б мора бити у стању да прихвати долазну везу ( за ово вам је, сходно томе, потребна улазна политика).политика).

Међутим, у пракси се можете ослонити на подразумевану политику да бисте дозволили везе у једном или оба смера.

Ако неки под-извор ће бити изабран од стране једног или више њих излазак-политичари, ограничења која су јој наметнута биће одређена њиховом дисјункцијом. У овом случају, мораћете експлицитно да дозволите везу са подом -адресату. Ако под није изабрана ниједна смерница, њен одлазни (излазни) саобраћај је подразумевано дозвољен.

Слично, судбина махуна јеадреса, изабран од стране једног или више њих улазак-политичаре, одредиће њихова дисјункција. У овом случају, морате му изричито дозволити да прима саобраћај из изворног модула. Ако под није изабрана ниједна смерница, сав улазни саобраћај за њега је подразумевано дозвољен.

Погледајте доле са статусом или без држављанства.

Дневници

Кубернетес мрежне смернице не могу да евидентирају саобраћај. Ово отежава утврђивање да ли политика функционише како је предвиђено и у великој мери компликује безбедносну анализу.

Контрола саобраћаја ка екстерним сервисима

Кубернетес мрежне смернице вам не дозвољавају да наведете потпуно квалификовано име домена (ДНС) у излазним одељцима. Ова чињеница доводи до значајних непријатности када покушавате да ограничите саобраћај на спољне дестинације које немају фиксну ИП адресу (као што је авс.цом).

Провера политике

Заштитни зидови ће вас упозорити или чак одбити да прихватите погрешну политику. Кубернетес такође врши неку верификацију. Када поставља мрежну политику преко кубецтл-а, Кубернетес може изјавити да је нетачна и одбити да је прихвати. У другим случајевима, Кубернетес ће преузети политику и попунити је детаљима који недостају. Могу се видети помоћу команде:

kubernetes get networkpolicy <policy-name> -o yaml

Имајте на уму да Кубернетес систем валидације није непогрешив и да може пропустити неке врсте грешака.

Извршење

Кубернетес не имплементира мрежне политике сам по себи, већ је само АПИ капија који делегира терет контроле на основни систем који се зове Цонтаинер Нетворкинг Интерфаце (ЦНИ). Постављање смерница на Кубернетес кластеру без додељивања одговарајућег ЦНИ је исто као и креирање смерница на серверу за управљање заштитним зидом без њиховог затим инсталирања на заштитне зидове. На вама је да осигурате да имате пристојан ЦНИ или, у случају Кубернетес платформе, хостован у облаку (можете видети листу провајдера овде — прибл. транс.), омогућите мрежне политике које ће поставити ЦНИ за вас.

Имајте на уму да вас Кубернетес неће упозорити ако поставите мрежну политику без одговарајућег помоћног ЦНИ-а.

Са држављанством или без држављанства?

Сви Кубернетес ЦНИ-ови на које сам наишао су са стањем (на пример, Цалицо користи Линук цоннтрацк). Ово омогућава модулу да прима одговоре на ТЦП везу коју је покренуо без потребе да је поново успоставља. Међутим, нисам упознат са Кубернетес стандардом који би гарантовао задржавање стања.

Управљање напредним безбедносним политикама

Ево неколико начина да побољшате спровођење безбедносне политике у Кубернетес-у:

1. Архитектонски образац Сервице Месх користи контејнере с приколицом да обезбеди детаљну телеметрију и контролу саобраћаја на нивоу услуге. Као пример можемо узети Истио.
2. Неки од добављача ЦНИ-а проширили су своје алате да превазиђу Кубернетес мрежне политике.
3. Туфин Орца Пружа видљивост и аутоматизацију Кубернетес мрежних политика.

Туфин Орца пакет управља Кубернетес мрежним смерницама (и извор је снимака екрана изнад).

додатне информације

• Примери мрежних политика које је припремио Ахмет Алп Балкан из ГКЕ;
• Документација са званичне Кубернетес веб странице;
• Водич за Кубернетес мрежни модел;
• Скрипта за проверу мрежних политика.

Закључак

Кубернетес мрежне смернице нуде добар скуп алата за сегментирање кластера, али нису интуитивне и имају много суптилности. Због ове сложености, верујем да су многе постојеће политике кластера погрешне. Могућа решења за овај проблем укључују аутоматизацију дефиниција политике или коришћење других алата за сегментацију.

Надам се да ће вам овај водич помоћи да разјасните нека питања и решите проблеме на које можете наићи.

ПС од преводиоца

Прочитајте и на нашем блогу:

• „Назад на микроуслуге са Истио-ом“: део 1 (увод у главне карактеристике), део 2 (рутирање, контрола саобраћаја), део 3 (безбедност);
• „Илустровани водич за умрежавање у Кубернетесу“: делови 1 и 2 (мрежни модел, мреже са преклапањем), део 3 (услуге и обрада саобраћаја);
• «Доцкер и Кубернетес у безбедносно осетљивим окружењима";
• «9 најбољих пракси за Кубернетес безбедност";
• «11 начина да (не) постанете жртва Кубернетес хака'.

Извор: ввв.хабр.цом