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

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

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

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

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

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

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

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

Работните натоварвания в Kubernetes се разпределят между модули, които се състоят от един или повече контейнери, разположени заедно. Kubernetes присвоява на всеки под 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

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

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

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

kubectl create -f policy.yaml

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

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

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

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

• По подразбиране се приема, че той определя входната страна. Ако политиката не посочва изрично това, системата ще приеме, че целият трафик е забранен.
• Поведението от изходната страна ще се определя от наличието или отсъствието на съответния изходящ параметър.

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

Според горната логика, ако параметрите ingress и / или egress пропуснат, политиката ще откаже целия трафик (вижте „Правило за премахване“ по-долу).

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

Ако не са дефинирани правила, Kubernetes позволява целия трафик по подразбиране. Всички модули могат свободно да обменят информация помежду си. Това може да изглежда нелогично от гледна точка на сигурността, но не забравяйте, че 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 в политиката ще избере pods от пространството от имена, към което принадлежи правилото (има отказ за достъп до pods от друго пространство от имена).

По същия начин, 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, като подове и пространства от имена. Етикети (етикети - тагове) са еквивалент на тагове в облака. Мрежовите политики на 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 в тази политика отваря входящия трафик към целевите подове. С други думи, входът е източникът, а целта е съответната дестинация. По същия начин изходът е дестинацията, а целта е нейният източник.

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

Изход и 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 избира всички подове в пространството от имена.

Първи мач и ред на правилата

В конвенционалните защитни стени действието (Разрешаване или Отказ) върху пакет се определя от първото правило, на което той отговаря. В Kubernetes редът на политиките няма значение.

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

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

Правило за отстраняване („Отказ“)

Политиките на защитната стена обикновено отказват всеки трафик, който не е изрично разрешен.

В Kubernetes няма действие за отказ, обаче, подобен ефект може да се постигне с обикновена (разрешителна) политика чрез избиране на празна група изходни пакети (ingress):

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

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

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

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

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

Позволява достъп от всички подове във всички пространства от имена (и всички IP) към всеки под в пространството от имена 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

Комбиниране на множество политики

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

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

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

Филтрирайте по пространства от имена и групи

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

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

Моля, имайте предвид, че 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 |             |         |        |
| ----------------------------------------|

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

podSelector:
  matchLabels:
    role: db
    version: v2

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

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

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

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

Подмрежи (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

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

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

Обикновено ipBlocks и podSelectors са взаимно изключващи се, тъй като вътрешните IP адреси на подс не се използват в ipBlocks. Чрез посочване вътрешни IP подс, всъщност ще позволите връзки към/от pods с тези адреси. На практика няма да знаете кой 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), това означава всички портове.

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

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

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

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

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

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

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

Необходимо ли е да регистрирате Ingress и Egress?

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

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

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

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

Вижте Stateful или Stateless по-долу.

Дневници

Мрежовите правила на 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.

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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