Модуль 3.5: Мережеві політики

Складність: [СЕРЕДНЯ] - Основні знання

Час на виконання: 25-30 хвилин

Передумови: Модуль 3.4: Безпека ServiceAccount

---

Що ви зможете робити

Після завершення цього модуля ви зможете:

• Оцінити покриття мережевих політик для виявлення незахищених подів та просторів імен
• Оцінити чи мережеві політики реалізують default-deny та правила трафіку з мінімальними привілеями
• Визначити прогалини в мережевій сегментації, що дозволяють бічний рух між навантаженнями
• Пояснити як політики ingress та egress комбінуються для контролю трафіку між подами та зовнішнього трафіку

---

Чому цей модуль важливий

За замовчуванням всі поди можуть комунікувати з усіма іншими подами в Kubernetes. Ця пласка мережа зручна, але небезпечна - скомпрометований под може сканувати весь ваш кластер та дістатися до будь-якого сервісу. Мережеві політики - це ваш фаєрвол всередині кластера.

Цей модуль будує на концепціях мережевої безпеки з Частини 2, зосереджуючись на практичному впровадженні політик.

---

Основи мережевих політик

┌─────────────────────────────────────────────────────────────┐
│              ОСНОВИ МЕРЕЖЕВИХ ПОЛІТИК                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ПОВЕДІНКА ЗА ЗАМОВЧУВАННЯМ (Без політик):                 │
│  • Всі поди можуть дістатися до всіх інших подів          │
│  • Всі поди можуть дістатися до зовнішніх точок            │
│  • Всі поди приймають трафік звідусіль                     │
│                                                             │
│  З МЕРЕЖЕВОЮ ПОЛІТИКОЮ:                                    │
│  • Поди обрані політикою мають обмежений трафік            │
│  • Не обрані поди залишаються повністю з'єднаними          │
│  • Політики адитивні (об'єднання дозволеного)              │
│                                                             │
│  КЛЮЧОВЕ РОЗУМІННЯ:                                         │
│  Застосування БУДЬ-ЯКОЇ політики до поду створює неявну    │
│  заборону для вказаного напрямку (ingress/egress)          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Структура політики

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example-policy
  namespace: production
spec:
  # 1. До яких подів застосовується?
  podSelector:
    matchLabels:
      app: backend

  # 2. Які напрямки контролює?
  policyTypes:
  - Ingress
  - Egress

  # 3. Який трафік дозволено ВСЕРЕДИНУ?
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

  # 4. Який трафік дозволено НАЗОВНІ?
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

Типи селекторів

┌─────────────────────────────────────────────────────────────┐
│              СЕЛЕКТОРИ МЕРЕЖЕВИХ ПОЛІТИК                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  podSelector                                               │
│  • Збіг подів за мітками                                   │
│  • У тому ж просторі імен що й політика                    │
│                                                             │
│  namespaceSelector                                         │
│  • Збіг просторів імен за мітками                          │
│  • Потім всі поди у відповідних просторах                  │
│                                                             │
│  ipBlock                                                   │
│  • Збіг за діапазоном CIDR                                 │
│  • Для зовнішніх IP                                        │
│                                                             │
│  КОМБІНОВАНО (логіка І):                                   │
│  from:                                                     │
│  - podSelector:            # Поди з app: web               │
│      matchLabels:          # ТА                             │
│        app: web            # у просторах з env: prod       │
│    namespaceSelector:                                      │
│      matchLabels:                                          │
│        env: production                                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Поширені шаблони

Заборона за замовчуванням

# Заборонити весь вхідний трафік у просторі імен
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}       # Порожній = всі поди
  policyTypes:
  - Ingress
  # Без правил ingress = заборонити все

Дозвіл DNS

Необхідний при використанні політик egress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Лише у тому ж просторі імен

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}  # Будь-який под у тому ж просторі

---

Деталі поведінки політик

І проти АБО в селекторах

# АБО: Трафік від app=web АБО app=api
ingress:
- from:
  - podSelector:
      matchLabels:
        app: web
  - podSelector:            # Окремий елемент списку = АБО
      matchLabels:
        app: api

# І: Трафік від подів що І у просторі production
#    І мають мітку app=web
ingress:
- from:
  - podSelector:            # Той самий елемент списку = І
      matchLabels:
        app: web
    namespaceSelector:
      matchLabels:
        env: production

---

Контроль вихідного трафіку

┌─────────────────────────────────────────────────────────────┐
│              РОЗГЛЯД ПОЛІТИК EGRESS                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЧОМУ КОНТРОЛЮВАТИ EGRESS:                                 │
│  • Запобігти витягуванню даних                             │
│  • Обмежити бічний рух                                     │
│  • Вимоги відповідності                                    │
│  • Зменшити поверхню атаки                                 │
│                                                             │
│  ЩО ДОЗВОЛЯТИ:                                             │
│  • DNS (майже завжди потрібен)                              │
│  • Потрібні backend-сервіси                                │
│  • Зовнішні API (конкретні IP якщо можливо)                │
│  • Точки моніторингу                                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Блокування хмарних метаданих

# Блокувати доступ до сервісу хмарних метаданих
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-metadata
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32  # Метадані AWS/GCP

---

Чи знали ви?

• Мережеві політики не застосовуються до подів з host network - поди з hostNetwork: true обходять мережеві політики.

• Порожній podSelector ({}) означає всі поди - так працюють політики заборони за замовчуванням.

• Політики просторові - впливають лише на поди у своєму просторі імен (але можуть посилатися на інші).

• Порядок не має значення - політики адитивні незалежно від порядку створення.

---

Поширені помилки

Помилка	Чому це шкодить	Рішення
Забути DNS у egress	Застосунок не може розв’язувати імена	Завжди дозволяйте DNS egress
CNI не підтримує політики	Політики не діють	Calico, Cilium тощо
Відсутні мітки просторів імен	Міжпросторові правила не працюють	Позначте простори імен
Неправильна логіка І/АБО	Несподіваний дозвіл/заборона	Ретельно тестуйте
Без заборони за замовчуванням	Нові поди без обмежень	Починайте із заборони

---

Тест

1. Що відбувається, коли у просторі імен немає мережевих політик?

   Відповідь

   Весь трафік дозволений. Поди можуть комунікувати з будь-яким іншим подом у кластері та зовнішніми точками. Мережеві політики створюють обмеження; без них обмежень немає.

2. Як створити політику “заборона всього вхідного за замовчуванням”?

   Відповідь

   Створити NetworkPolicy з порожнім podSelector (збіг усіх подів), policyTypes включає Ingress, та без правил ingress. Порожній список правил означає, що вхідний трафік не дозволений.

3. Чому політики egress зазвичай повинні дозволяти DNS?

   Відповідь

   Більшість застосунків потребують DNS для розв'язання імен сервісів. Без egress DNS поди не можуть розв'язувати імена хостів для сервісів, до яких потрібно звертатися, що ламає більшість застосунків.

4. Яка різниця між podSelector ТА namespaceSelector в одному елементі списку проти окремих елементів?

   Відповідь

   Один елемент списку = І (має відповідати обом). Окремі елементи = АБО (відповідність будь-якому). Це поширене джерело помилок у політиках.

5. Чи можуть мережеві політики блокувати трафік до/від подів з hostNetwork: true?

   Відповідь

   Ні. Поди з hostNetwork обходять мережеві політики, оскільки використовують мережевий простір імен хоста, а не мережевий простір імен поду, де впроваджуються політики.

---

Підсумок

Мережеві політики впроваджують мережу нульової довіри:

Концепція	Ключові моменти
Поведінка за замовчуванням	Весь трафік дозволений без політик
podSelector	Які поди підпадають під політику
policyTypes	Ingress, Egress або обидва
Селектори	podSelector, namespaceSelector, ipBlock
Комбінування	Політики адитивні (АБО)

Найкращі практики:

• Починайте із заборони за замовчуванням
• Завжди дозволяйте DNS для egress
• Використовуйте мітки просторів імен для міжпросторових правил
• Тестуйте політики перед продакшн
• Перевірте підтримку CNI

---

Наступний модуль

Модуль 4.1: Поверхні атак - Розуміння векторів атак Kubernetes.