Въведение в мрежовите политики на Kubernetes за специалисти по сигурността

Прим. прев.: Автор на статията — Reuven Harrison — разполага с над 20 години опит в софтуерната разработка и в момента е технически директор и съосновател на компанията Tufin, която разработва решения за управление на политиките за сигурност. Разглеждайки мрежовите политики на Kubernetes като доста мощен инструмент за сегментация на мрежата в клъстера, той в същото време смята, че те не са толкова лесни за приложение на практика. Тази статия (доста обширна) има за цел да подобри осведомеността на специалистите по този въпрос и да им помогне в създаването на нужните конфигурации.

Днес много компании все повече избират Kubernetes за разгръщането на приложенията си. Интересът към този софтуер е толкова висок, че някои го наричат "новата операционна система за центрове за данни". Постепенно Kubernetes (или k8s) започва да се възприема като критично важна част от бизнеса, която изисква организация на зрели бизнес-процеси, включително осигуряване на мрежова сигурност.

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

Това ръководство ще помогне да се разбере вътрешната структура на мрежовите политики; да се разбере как те се различават от правилата за обикновените защитни стени. Също така ще бъдат разгледани някои подводни камъни и ще бъдат дадени препоръки, които ще помогнат за защитата на приложенията в Kubernetes.

Мрежови политики Kubernetes

Механизмът на мрежовите политики на Kubernetes позволява управление на взаимодействията между разгръщаните на платформата приложения на мрежово ниво (трета нива в модела OSI). Мрежовите политики липсват от някои напреднали функции на съвременните защитни стени, като контрол на 7-мо ниво на OSI и откриване на заплахи, но осигуряват основно ниво на мрежова сигурност, което представлява добра отправна точка.

Мрежовите политики контролират комуникацията между pod’овете

Работните натоварвания в Kubernetes се разпределят по pod-ове, които се състоят от един или няколко контейнера, разпределени заедно. Kubernetes присвоява на всеки pod IP адрес, достъпен от други pod-ове. Мрежовите политики в Kubernetes задават права на достъп за групи pod-ове по подобен начин, както групите за сигурност в облака се използват за управление на достъпа до инстанции на виртуални машини.

Определяне на мрежови политики

Подобно на другите ресурси в 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

(Прим. прев.: този екран, както и всички последващи подобни, е създаден не с оригиналните средства на Kubernetes, а с инструмента Tufin Orca, разработен от компанията на автора на оригиналната статия, спомената в края на материала.

За да определите собствена мрежова политика, ще ви трябват основни познания по YAML. Този език е основан на отстъпите (зададени с интервали, а не с табулация). Елемент с отстъп се принадлежи на най-близкия елемент с отстъп над него. Нов елемент от списъка започва с тире, а всички останали елементи са във вида ключ-стойност.

След като опишете политиката на YAML, използвайте kubectl, за да я създадете в кластера:

kubectl create -f policy.yaml

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

Спецификацията на мрежовата политика в Kubernetes включва четири елемента:

1. podSelector: определя pod-овете, засегнати от тази политика (целите) — задължителен;
2. policyTypes: указва кои типове политики са включени в тази: ingress и/или egress — необязателен, но препоръчвам да го описвате ясно във всички случаи;
3. ingress: определя разрешен входящ трафик в целевите pod-ове — необязателен;
4. egress: определя разрешен изходящ трафик от целевите pod-ове — необязателен.

Пример, взет от сайта на Kubernetes (заменил съм 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, политиката ще бъде интерпретирана по следния начин:

• По подразбиране се предполага, че тя определя страната на ingress. Ако в политиката не са посочени ясни указания за това, системата ще счита, че целият трафик е забранен.
• Поведението на egress-страна ще бъде определяно от наличието или отсъствието на съответния egress параметър.

За да избегнете грешки, препоръчвам винаги да посочвате ясно policyTypes.

В съответствие с посочената по-горе логика, в случай че параметрите ingress и/или egress са пропуснати, политиката ще забранява целия трафик (вж. "Правило за почистване" по-долу).

Политиката по подразбиране е разрешаване

Ако политиките не са определени, Kubernetes по подразбиране разрешава целия трафик. Всички pod-ове свободно могат да обменят информация помежду си. От гледна точка на сигурността това може да изглежда нелогично, но не забравяйте, че Kubernetes първоначално е създаден от разработчици с цел да осигури взаимодействие между приложенията. Мрежовите политики са добавени по-късно.

Именни пространства

Именните пространства (Namespaces) са механизъм за колективна работа в Kubernetes. Те са предназначени за изолиране на логически среди една от друга, като обменът на данни между пространства по подразбиране е разрешен.

Както повечето компоненти на Kubernetes, мрежовите политики обитават в определено именна пространство. В блока metadata може да бъде посочено на кое именно пространство принадлежи политиката:

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

Ако именното пространство в метаданните не е посочено ясно, системата ще използва namespace, посочено в kubectl (по подразбиране namespace=default):

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

Препоръчвам ясно да посочвате namespace, освен ако не пишете политика, предназначена за няколко пространства с имена.

Основен елемент podSelector в политиката ще избира pod'и от пространството с имена, към което принадлежи политиката (няма достъп до pod'и от друго пространство с имена).

По същия начин podSelector'ите в блоковете ingress и egress могат да избират pod'и само от своето пространство с имена, освен ако не ги комбинирате с помощта на namespaceSelector (за това ще говорим в раздела "Филтриране по пространства с имена и pod'и").

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

Имената на политиките са уникални в рамките на едно пространство с имена. Не може да има две политики с едно и също име в едно пространство, но могат да съществуват политики с едни и същи имена в различни пространства. Това е удобно, когато искате да приложите една и съща политика в няколко пространства.

Особено ми харесва един от начините за именуване. Той се състои в комбинация на името на пространството с имена с целевите pod'и. Например:

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, като pod'и и пространства с имена, могат да се прикрепят потребителски етикети. Етикетите (labels — марки) са еквивалент на таговете в облака. Мрежовите политики на Kubernetes използват етикети за избор pod'и, към които се прилагат:

podSelector:
  matchLabels:
    role: db

… или пространствата с имена, към които се прилагат. В този пример се избират всички pod'и в пространствата с имена с подходящите етикети:

namespaceSelector:
  matchLabels:
    project: myproject

Едно предупреждение: когато използвате namespaceSelector необходимо е да се уверите, че избраните пространства с имена съдържат необходимия етикет. Имайте предвид, че вградените пространства с имена, като по подразбиране и kube-system, по подразбиране не съдържат етикети.

Добавянето на етикет към пространството може да стане по следния начин:

kubectl label namespace default namespace=default

При това namespace в секцията metadata трябва да се отнася до действителното име на пространството, а не до етикета:

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

Източник и адресат

Политиките за защитните стени се състоят от правила с източници и адресати. Мрежовите политики на Kubernetes се определят за целта – набор от pod’ове, към които се прилагат, и след това установяват правила за входящ (ingress) и/или изходящ (egress) трафик. В нашия пример целта на политиката ще бъдат всички pod’ове в пространството на имена по подразбиране с етикет с ключ 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 в тази политика отваря входящия трафик към целевите pod’ове. С други думи, ingress е източник, а целта е съответният адресат. По аналогичен начин egress е адресат, а целта е неговият източник.

Това е еквивалентно на две правила за защитната стена: Ingress → Цел; Цел → Egress.

Egress и 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

Последният елемент към — е празен и следователно косвено избира всички pod’ове във всички пространства на имена, позволявайки 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. В раздела "Филтриране по пространства на имената и pod’ове" ще бъде описано как да се постигне това.

Друг вариант е да разрешите 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 избира всички pod’ове в пространството на имената.

Първо съвпадение и ред на правилата

В обикновените брандмауери, действието („Разреши“ или „Забрани“) по отношение на пакет се определя от първото правило, на което отговаря. В Kubernetes редът на политиките няма значение.

По подразбиране, когато политиките не са зададени, комуникацията между pod’овете е разрешена и те могат свободно да обменят информация. След като започнете да формулирате политики, всеки pod, засегнат от поне една от тях, става изолиран в съответствие с дизюнкцията (логично ИЛИ) на всички политики, които го избират. Pod’овете, не засегнати от никаква политика, остават отворени.

Можете да промените подобно поведение с помощта на правило за почистване.

Правило за почистване („Забрани“)

Политиките на брандмауера обикновено забраняват всякакъв трафик, който не е явно разрешен.

В Kubernetes няма действие „забранявам“ (deny),обаче подобен ефект може да бъде постигнат с обикновена (разрешаваща) политика, избираща празна група pod’ове-източници (ingress):

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

Тази политика избира всички pod'ове в пространството за име и оставя ingress неопределен, забранявайки целия входящ трафик.

По подобен начин можете да ограничите целия изходящ трафик от пространството за име:

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

Имайте предвид, че всички допълнителни политики, разрешаващи трафик към pod'ове в пространството за име, ще имат предимство над това правило (аналогично на добавянето на разрешаващо правило преди забраняващото в конфигурацията на брандмауера).

Разреши всичко (Any-Any-Any-Allow)

За да създадете политика „Разреши всичко“, трябва да допълните приведената по-горе забранителна политика с празен елемент ingress:

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

Тя отваря достъп от всички pod'ове във всички пространства за име (и всички IP) до всеки pod в пространството за име по подразбиране. Такова поведение е включено по подразбиране, така че обикновено не е необходимо да се дефинира допълнително. Въпреки това понякога може да се наложи временно да деактивирате някои конкретни разрешения за диагностика на проблема.

Правилото може да бъде стеснено и да разреши достъп само до определен набор от pod'ове (app:balance) в пространството за име по подразбиране:

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

Следната политика разрешава целия входящ (ingress) и изходящ (egress) трафик, включително достъп до всякакви IP извън клъстера:

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

Комбиниране на няколко политики

Политиките се комбинират с логическо ИЛИ на три нива; разрешенията на всеки pod се определят в съответствие с дизюнкцията на всички политики, които го засягат:

1. В полетата from и към можете да определите три типа елементи (всички те се комбинират с помощта на ИЛИ):

• namespaceSelector — избирало пространство за име изцяло;
• podSelector — избирало pod'ове;
• ipBlock — избирало подсет.

При това броят на елементите (дори идентични) в подразделите from/към не е ограничен. Всички те ще бъдат комбинирани логически с ИЛИ.

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 може да включва многобройни елементи към (също обединени с дизюнкция):

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). Политиките, които определят 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

В резултат на това всички pod’ове в пространството по подразбиране ще получат достъп до pod’овете postgres в пространството от имена database. Но какво, ако искате да отворите достъп само до конкретни pod’ове в пространството postgres Филтър по пространства и pod’ове по подразбиране?

Kubernetes версия 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

Защо това се тълкува като И вместо обичайното ИЛИ?

не започва с тире. В YAML това означава, че

Обърнете внимание, че podSelector и стоящото пред него podSelector се отнасят за един и същ елемент на списъка. Затова те се обединяват логически И. namespaceSelector относятся к одному и тому же элементу списка. Поэтому они объединяются логическим И.

Добавяне на тире преди podSelector ще доведе до създаване на нов елемент от списъка, който ще бъде комбиниран с предшестващия namespaceSelector чрез логическо ИЛИ.

За да изберете pod’ове с определен етикет във всички пространства на имена, напишете празен 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:

| Източник | Дестинация | Услуга | Действие |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Позволи  |
| Host_2 |             |         |        |
| ----------------------------------------|

Обратно, в Kubernetes различните етикети в podSelector или namespaceSelector се обединяват логически с И. Например, следното правило ще избере pod’ове, които притежават и двата етикета, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

Същата логика се прилага за всички видове оператори: селектори на цели политики, селектори на pod’ове и селектори на пространства на имена.

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

За сегментиране на мрежата защитните стени използват VLAN, IP адреси и подмрежи.

В Kubernetes IP адресите се присвояват на pod’овете автоматично и могат често да се променят, затова за избор на pod’ове и пространства на имена в мрежовите политики се използват етикети.

Подмрежи (ipBlocks) се използват при управление на входящите (ingress) или изходящите (egress) външни (North-South) връзки. Например, тази политика отваря достъп на всички pod’ове в пространството на имена по подразбиране до DNS услугата на Google:

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’ове в този пример означава „изберете всички pod’ове в пространството на имена“.

Тази политика отваря достъп само до 8.8.8.8; достъпът до всякакви други IP е забранен. По този начин, в същността, вие блокирате достъпа до вътрешната услуга DNS на Kubernetes. Ако все пак искате да я отворите, посочете това явно.

Обикновено ipBlocks и podSelectors са взаимно изключващи, тъй като вътрешните IP адреси на pod’овете не се използват в ipBlocks. Посочвайки вътрешните IP адреси на pod’овете, вие фактически разрешавате свързвания от/к pod’ове с тези адреси. На практика, няма да знаете кой IP адрес да използвате, именно затова не трябва да ги прилагате за избор на pod’ове.

Като контрапример, следната политика включва всички IP адреси и следователно разрешава достъп до всички други pod’ове:

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’овете. Например, ако подсетната маска на вашия 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

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

Обычно pod’овете слушат един порт. Това означава, че можете просто да не посочвате номера на портовете в политиките и да оставите всичко по подразбиране. Все пак, се препоръчва политиките да бъдат максимално ограничителни, затова в някои случаи все пак можете да посочите портове:

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 се прилага към всички елементи в блока към или from, в който се съдържа. За да посочите различни портове за различни набори от елементи, разделете ingress или egress на няколко подраздела с към или 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), това означава всички портове.

Най-добра практика: не разчитайте на стойности по подразбиране, посочвайте нужните ви явно.

Обърнете внимание, че трябва да се използват портовете на pod-овете, а не на услугите (повече за това в следващия параграф).

Политиките определени ли са за pod-ове или услуги?

Обикновено pod-овете в Kubernetes се свързват помежду си чрез услуга — виртуален балансировчик на натоварването, пренасочващ трафика към pod-овете, реализиращи услугата. Може да изглежда, че мрежовите политики контролират достъпа до услугите, но това не е така. Мрежовите политики на Kubernetes работят с портовете на pod-овете, а не с услугите.

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

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

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

Необходимо ли е да се зададат както Ingress, така и Egress?

Краткият отговор е да, за да може pod А да се свърже с pod В, е необходимо да му бъде разрешено да прави изходящо свързване (за което трябва да се настрои egress политика), а pod В трябва да има възможността да приема входящо свързване (за което, съответно, е необходима ingress политика).

Въпреки това, на практика може да се разчита на политика по подразбиране, разрешаваща свързвания в една или в двете посоки.

Ако някой pod-източник бъде избран от една или повече egress-политики, ограниченията, наложени на него, ще бъдат определени от тяхната дизюнкция. В този случай ще е необходимо да се разреши явно свързването с pod-адресат. Ако pod не е избран от някоя политика, неговият изходящ (egress) трафик е разрешен по подразбиране.

По подобен начин съдбата на pod-а-адресат, избран от една или повече ingress-политики, ще се определи от тяхната дизюнкция. В този случай е необходимо да се разреши явно да получава трафик от pod-а-източник. Ако pod не е избран от никаква политика, целият входящ (ingress) трафик за него е разрешен по подразбиране.

Вижте раздела 'Stateful или Stateless' по-долу.

Логове

Мрежовите политики на Kubernetes не могат да журнализират трафика. Това затруднява определянето на това дали политиката работи правилно и значително усложнява анализа в областта на сигурността.

Контрол върху трафика към външни услуги

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

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

Брандмауерите ще ви предупредят или дори ще откажат да приемат неправилна политика. Kubernetes също извършва известно валидиране. При задаване на мрежова политика чрез kubectl, Kubernetes може да заяви, че тя е неправилна и да откаже да я приеме. В други случаи Kubernetes ще приеме политиката и ще я допълни с липсващи детайли. Те могат да се видят с помощта на командата:

kubernetes get networkpolicy  -o yaml

Имайте предвид, че системата за проверка на Kubernetes не е безгрешна и може да пропусне някои видове грешки.

Изпълнение

Kubernetes не се занимава със изпълнението на мрежови политики самостоятелно, а е просто API шлюз, който прехвърля тежестта на контрола на по-долната система, наречена Container Networking Interface (CNI). Задаването на политики в кластера Kubernetes без назначаване на съответния CNI е равносилно на създаване на политики на сървъра за управление на брандмауера без тяхното последващо инсталиране в брандмауерите. Вие сами трябва да се уверите в наличието на подходящ CNI или, в случаи на платформи Kubernetes, разположени в облака (С списък на доставчиците може да се запознаете тук. — бел. ред.), да активирате мрежови политики, които ще настроят CNI за вас.

Обърнете внимание, че Kubernetes няма да ви предупреди, ако зададете мрежова политика без съответния помощен CNI.

Stateful или Stateless?

Всички CNI Kubernetes, с които съм се сблъсквал, съхраняват състояния (например, Calico използва Linux conntrack). Това позволява на pod да получава отговори по инициирано от него TCP свързване без необходимост от повторно установяване. В същото време не ми е известно за стандарт на Kubernetes, който да гарантира съхранение на състояние (statefulness).

Усовершенствано управление на политиката за сигурност

Ето няколко начина за повишаване на ефективността на изпълнението на политиката за сигурност в Kubernetes:

1. Архитектурният патърн Service Mesh използва sidecar контейнери за осигуряване на подробна телеметрия и контрол над трафика на ниво услуги. Като пример можем да вземем Istio.
2. Някои от доставчиците CNI разшириха инструментите си, така че да излязат извън мрежовите политики на Kubernetes.
3. Tufin Orca осигурява прозрачност и автоматизация на мрежовите политики на Kubernetes.

Пакетът Tufin Orca управлява мрежовите политики на Kubernetes (и служи като източник на скрийншотове, посочени по-горе).

Допълнителна информация

• Примери за мрежови политики, подготвени от Ахмет Алп Балкан от GKE;
• Документация от официалния сайт на Kubernetes;
• Ръководство за мрежовата модел на Kubernetes;
• Скрипт за проверка на мрежовите политики.

Заключение

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

Надявам се, че това ръководство ще помогне да изясни някои въпроси и да реши проблемите, с които може да се сблъскате.

P.S. от преводача

Прочетете също в нашия блог:

• «Назад към микросервисите с Istio»: част 1 (запознаване с основните възможности), част 2 (маршрутизиране, управление на трафика), част 3 (сигурност);
• «Илюстрировано ръководство за структурата на мрежата в Kubernetes»: части 1 и 2 (мрежова модел, overlay мрежи), част 3 (услуги и обработка на трафика);
• «Docker и Kubernetes в среди, изискващи сигурност»;
• «9 най-добри практики за осигуряване на безопасността в Kubernetes»;
• «11 начина (не) да станете жертва на хакерска атака в Kubernetes».

Източник: habr.com