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

Забелешка. превод.: Авторот на статијата, Реувен Харисон, има над 20 години искуство во развој на софтвер, а денес е CTO и ко-основач на Tufin, компанија која создава решенија за управување со безбедносни политики. Иако тој ги гледа мрежните политики на Кубернетс како прилично моќна алатка за сегментација на мрежата во кластер, тој исто така верува дека тие не се толку лесни за спроведување во пракса. Овој материјал (прилично обемен) е наменет да ја подобри свеста на специјалистите за ова прашање и да им помогне да ги создадат потребните конфигурации.

Денес, многу компании се повеќе избираат Kubernetes за да ги извршуваат своите апликации. Интересот за овој софтвер е толку голем што некои го нарекуваат Kubernetes „новиот оперативен систем за центарот за податоци“. Постепено, Kubernetes (или k8s) почнува да се перцепира како критичен дел од бизнисот, кој бара организација на зрели деловни процеси, вклучително и мрежна безбедност.

За безбедносните професионалци кои се збунети од работата со Kubernetes, вистинското откритие може да биде стандардната политика на платформата: дозволи сè.

Овој водич ќе ви помогне да ја разберете внатрешната структура на мрежните политики; разберете како тие се разликуваат од правилата за редовни заштитни ѕидови. Исто така, ќе опфати некои стапици и ќе даде препораки за да помогне во безбедноста на апликациите на Kubernetes.

Мрежни политики на Kubernetes

Механизмот за мрежна политика Кубернетес ви овозможува да управувате со интеракцијата на апликациите распоредени на платформата на мрежниот слој (третиот во моделот OSI). На мрежните политики им недостасуваат некои од напредните карактеристики на современите заштитни ѕидови, како што е спроведувањето на OSI Layer 7 и откривањето закани, но тие обезбедуваат основно ниво на мрежна безбедност што е добра почетна точка.

Мрежните политики ги контролираат комуникациите помеѓу подлогите

Обемот на работа во Kubernetes се дистрибуира низ подлоги, кои се состојат од еден или повеќе контејнери распоредени заедно. Kubernetes му доделува на секој pod IP адреса што е достапна од други места. Мрежните политики на Kubernetes ги поставуваат правата за пристап за групи на подлоги на ист начин како што безбедносните групи во облакот се користат за контрола на пристапот до примероци на виртуелни машини.

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

Како и другите ресурси на Kubernetes, мрежните политики се наведени во YAML. Во примерот подолу, апликацијата 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

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

За да ја дефинирате сопствената мрежна политика, ќе ви треба основно познавање на YAML. Овој јазик се заснова на вовлекување (наведено со празни места наместо со јазичиња). Вовлечениот елемент припаѓа на најблискиот вовлечен елемент над него. Нов елемент од списокот започнува со цртичка, сите други елементи ја имаат формата клуч-вредност.

Откако ја опишавте политиката во YAML, користете кубектелда го креирате во кластерот:

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 ако се испушти, политиката ќе го одбие целиот сообраќај (видете „Правило за соголување“ подолу).

Стандардна политика е Дозволи

Ако не се дефинирани политики, Kubernetes стандардно го дозволува целиот сообраќај. Сите мешунки можат слободно да разменуваат информации меѓу себе. Ова може да изгледа контраинтуитивно од безбедносна перспектива, но запомнете дека Kubernetes првично беше дизајниран од програмери за да овозможи интероперабилност на апликациите. Мрежните политики беа додадени подоцна.

Простори со имиња

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

Како и повеќето компоненти на Kubernetes, мрежните политики живеат во одреден именски простор. Во блокот metadata можете да одредите на кој простор му припаѓа политиката:

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

Ако именскиот простор не е експлицитно наведен во метаподатоците, системот ќе го користи именскиот простор наведен во kubectl (стандардно namespace=default):

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

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

Главната елемент podSelector во полисата ќе се изберат подлоги од именскиот простор на кој му припаѓа политиката (нема пристап до местата од друг именски простор).

Слично на тоа, podSelectors во влезните и излезните блокови може да избира само мешунки од нивниот сопствен именски простор, освен ако секако не ги комбинирате 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

Етикети

Можете да прикачите приспособени етикети на објектите на Кубернет, како што се подлоги и именски простори. Етикети (етикети - ознаки) се еквивалент на ознаките во облакот. Мрежните политики на Kubernetes користат етикети за избор мешункина кои се однесуваат:

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:
...

Извор и дестинација

Политиките за заштитен ѕид се состојат од правила со извори и дестинации. Мрежните политики на Kubernetes се дефинирани за цел - збир на подлоги на кои се применуваат - и потоа поставуваат правила за влезен и/или излезен сообраќај. Во нашиот пример, целта на политиката ќе бидат сите подлоги во именскиот простор 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 во оваа политика, го отвора дојдовниот сообраќај до целните места. Со други зборови, влезот е изворот, а целта е соодветната дестинација. Исто така, излезот е дестинацијата и целта е нејзиниот извор.

Ова е еквивалентно на две правила за заштитен ѕид: Влез → Цел; Цел → Излез.

Излез и DNS (важно!)

Со ограничување на појдовниот сообраќај, посветете посебно внимание на DNS - Kubernetes ја користи оваа услуга за мапирање на услуги на IP адреси. На пример, следнава политика нема да работи бидејќи не сте ја дозволиле апликацијата balance пристап до 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

Можете да го поправите со отворање пристап до услугата 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

Последниот елемент to е празна, и затоа индиректно избира сите мешунки во сите именски простори, дозволувајќи balance испратете прашања за DNS до соодветната услуга на Kubernetes (обично работи во просторот kube-system).

Овој пристап функционира, како и да е премногу попустлив и несигурен, бидејќи дозволува DNS барањата да бидат насочени надвор од кластерот.

Можете да го подобрите во три последователни чекори.

1. Дозволете само барања за DNS внатре кластер со додавање 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. Дозволете DNS барања само во именскиот простор 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. Параноичните луѓе можат да одат уште подалеку и да ги ограничат барањата за DNS на одредена DNS услуга во kube-system. Во делот „Филтрирајте по именски простори И мешунки“ ќе ви кажеме како да го постигнете тоа.

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

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

Празно 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

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

Дозволи сè (Any-Any-Any-Allow)

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

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

Овозможува пристап од сите pods во сите именски простори (и сите IP) до кој било pod во именскиот простор 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

Следната политика го дозволува целиот влезен и излезен сообраќај, вклучително и пристап до која било IP адреса надвор од кластерот:

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

Но, при нивното комбинирање, постои едно ограничување на кое истакна Крис Куни: Kubernetes може само да комбинира политики со различни 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 не започнува со цртичка. Во YAML тоа значи дека 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

Повеќе етикети се здружуваат со I

Правилата за заштитен ѕид со повеќе објекти (домаќини, мрежи, групи) се комбинираат со користење на логички ИЛИ. Следното правило ќе работи ако изворот на пакетот се совпаѓа 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

Истата логика важи за сите типови на оператори: избирачи на целни политики, избирачи на pod и избирачи на именски простор.

Подмрежи и IP адреси (IPBlocks)

Заштитните ѕидови користат VLAN, IP адреси и подмрежи за сегментирање на мрежата.

Во Kubernetes, IP-адресите се доделуваат автоматски на pods и може често да се менуваат, така што етикетите се користат за избирање на pods и именски простори во мрежните политики.

Подмрежи (ipBlocks) се користат при управување со дојдовни (влез) или појдовни (излез) надворешни (Север-Југ) врски. На пример, ова правило се отвора за сите подлоги од именскиот простор default пристап до услугата 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

Празниот избирач на pod во овој пример значи „избери ги сите места во именскиот простор“.

Оваа политика дозволува пристап само до 8.8.8.8; пристапот до која било друга IP адреса е забранет. Значи, во суштина, го блокиравте пристапот до внатрешната услуга Kubernetes DNS. Ако сè уште сакате да го отворите, наведете го ова експлицитно.

Обично ipBlocks и podSelectors меѓусебно се исклучуваат, бидејќи внатрешните IP адреси на pods не се користат во ipBlocks. Со укажување внатрешни IP подлоги, всушност ќе дозволите врски до/од подлоги со овие адреси. Во пракса, нема да знаете која IP адреса да ја користите, поради што тие не треба да се користат за избирање на подлоги.

Како контра-пример, следнава политика ги вклучува сите IP адреси и затоа дозволува пристап до сите други подлоги:

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

Можете да го отворите пристапот само до надворешни IP-адреси, со исклучок на внатрешните IP-адреси на подлогите. На пример, ако подмрежата на вашиот pod е 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), ова значи TCP;
• Ако ја испуштите дефиницијата на портата (port), ова значи сите пристаништа.

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

Ве молиме имајте предвид дека мора да користите под-порти, а не сервисни порти (повеќе за ова во следниот пасус).

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

Вообичаено, подовите во Kubernetes пристапуваат меѓусебно преку услуга - виртуелен балансирач на оптоварување кој го пренасочува сообраќајот кон местата што ја спроведуваат услугата. Можеби мислите дека мрежните политики го контролираат пристапот до услугите, но тоа не е така. Мрежните политики на Kubernetes работат на под-порти, а не на сервисни порти.

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

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

Нов архитектонски пристап користејќи Service Mesh (на пример, видете за Истио подолу - прибл. превод.) ви овозможува да се справите со овој проблем.

Дали е потребно да се регистрираат и Ingress и Egress?

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

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

Ако некои под-извор ќе бидат избрани од еден или повеќе излез-Политичарите, ограничувањата што ќе му се наметнат ќе бидат утврдени со нивна дисјункција. Во овој случај, ќе треба експлицитно да дозволите поврзување со подлогата -на адресатот. Ако некоја група не е избрана од некоја политика, неговиот појдовен (излезен) сообраќај е стандардно дозволен.

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

Видете државјанство или без државјанство подолу.

Дневници

Мрежните политики на Kubernetes не можат да евидентираат сообраќај. Ова го отежнува одредувањето дали политиката работи како што е планирано и во голема мера ја комплицира безбедносната анализа.

Контрола на сообраќајот кон надворешни услуги

Мрежните политики на Kubernetes не дозволуваат да наведете целосно квалификувано име на домен (DNS) во секциите за излез. Овој факт води до значителни непријатности кога се обидувате да го ограничите сообраќајот на надворешни дестинации кои немаат фиксна IP адреса (како што е aws.com).

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

Заштитните ѕидови ќе ве предупредат или дури и ќе одбијат да ја прифатите погрешната политика. Kubernetes исто така прави одредена проверка. Кога поставува мрежна политика преку kubectl, Kubernetes може да изјави дека е неточна и да одбие да ја прифати. Во други случаи, Kubernetes ќе ја преземе политиката и ќе ја пополни со деталите што недостасуваат. Тие можат да се видат со помош на командата:

kubernetes get networkpolicy <policy-name> -o yaml

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

Извршување

Kubernetes не ги имплементира мрежните политики сам по себе, туку е само API порта што го делегира товарот на контрола на основниот систем наречен Container Networking Interface (CNI). Поставувањето политики на кластерот Kubernetes без доделување на соодветниот CNI е исто како и креирањето политики на серверот за управување со заштитен ѕид без потоа да ги инсталирате на заштитните ѕидови. Од вас зависи дали ќе се осигурате дека имате пристоен CNI или, во случај на платформи на Kubernetes, хостирани во облакот (можете да ја видите листата на провајдери тука - прибл. транс.), овозможете мрежни политики што ќе ви постават CNI.

Имајте предвид дека Kubernetes нема да ве предупреди ако поставите мрежна политика без соодветен помошник CNI.

Државен или без државјанство?

Сите Kubernetes CNI што ги сретнав се со статус (на пример, Calico користи Linux conntrack). Ова му овозможува на pod да прима одговори на TCP конекцијата што ја иницирала без да мора повторно да ја воспостави. Како и да е, не сум свесен за стандард на Кубернетс кој би гарантирал државност.

Напредно управување со безбедносни политики

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

1. Архитектонската шема на Service Mesh користи контејнери за странична кола за да обезбеди детална телеметрија и контрола на сообраќајот на ниво на услуга. Како пример можеме да земеме Истио.
2. Некои од продавачите на CNI ги проширија своите алатки за да ги надминат мрежните политики на Kubernetes.
3. Туфин Орка Обезбедува видливост и автоматизација на мрежните политики на Кубернетес.

Пакетот Tufin Orca управува со мрежните политики на Kubernetes (и е изворот на сликите од екранот погоре).

дополнителни информации

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

Заклучок

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

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

PS од преведувач

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

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

Извор: www.habr.com