Модуль 2.3: Мережева безпека

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

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

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

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

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

Оцінити пласку мережеву модель Kubernetes та її наслідки для безпеки
Оцінити покриття NetworkPolicy для виявлення незахищених просторів імен та подів
Пояснити як mTLS service mesh забезпечує шифрування та верифікацію ідентифікації для трафіку подів
Порівняти можливості безпеки CNI-плагінів та їх підтримку застосування мережевих політик

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

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

Мережеві політики та service mesh - ваші основні інструменти контролю трафіку всередині кластера.

Мережева модель Kubernetes

┌─────────────────────────────────────────────────────────────┐
│              МЕРЕЖА KUBERNETES ЗА ЗАМОВЧУВАННЯМ              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЗА ЗАМОВЧУВАННЯМ:                                         │
│  • Всі поди можуть комунікувати з усіма іншими подами     │
│  • Без мережевої ізоляції між просторами імен              │
│  • Будь-який под може дістатися до будь-якого сервісу      │
│  • Поди можуть дістатися до зовнішніх мереж                │
│                                                             │
│  ЦЕ НЕБЕЗПЕЧНО:                                            │
│  • Скомпрометований под може сканувати весь кластер        │
│  • Бічний рух є тривіальним                                │
│  • Без глибинного захисту                                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Container Network Interface (CNI)

Плагіни CNI реалізують мережу Kubernetes та часто забезпечують впровадження мережевих політик.

┌─────────────────────────────────────────────────────────────┐
│              ОБОВ'ЯЗКИ ПЛАГІНА CNI                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  БАЗОВА МЕРЕЖА                                              │
│  • Призначення IP-адрес подам                              │
│  • Забезпечення комунікації pod-to-pod                     │
│  • Маршрутизація трафіку між вузлами                       │
│                                                             │
│  ФУНКЦІЇ БЕЗПЕКИ (варіюються за плагіном)                  │
│  • Впровадження мережевих політик                          │
│  • Шифрування при передачі                                 │
│  • Контроль вихідного трафіку                              │
│  • Спостережуваність та логування                          │
│                                                             │
│  ПОШИРЕНІ ПЛАГІНИ CNI                                      │
│  ┌──────────────┬────────────────────────────────────┐    │
│  │ Плагін       │ Підтримка мережевих політик       │    │
│  ├──────────────┼────────────────────────────────────┤    │
│  │ Calico       │ Повна (плюс розширення)            │    │
│  │ Cilium       │ Повна (плюс розширення)            │    │
│  │ Weave        │ Повна                              │    │
│  │ Flannel      │ Немає (лише базова мережа)         │    │
│  │ AWS VPC CNI  │ Через додаток Calico               │    │
│  └──────────────┴────────────────────────────────────┘    │
│                                                             │
│  Flannel не підтримує мережеві політики!                   │
│  Обирайте CNI відповідно до потреб безпеки                 │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Мережеві політики - це вбудований механізм Kubernetes для контролю трафіку.

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

┌─────────────────────────────────────────────────────────────┐
│              КОНЦЕПЦІЯ МЕРЕЖЕВОЇ ПОЛІТИКИ                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Мережеві політики є АДИТИВНИМИ:                           │
│  • Без політик = дозволити весь трафік                     │
│  • Політика існує = заборона за замовчуванням для подів    │
│  • Кілька політик = об'єднання дозволеного трафіку        │
│                                                             │
│  КОМПОНЕНТИ ПОЛІТИКИ:                                      │
│                                                             │
│  podSelector:     Які поди підпадають під політику         │
│  policyTypes:     [Ingress, Egress] або обидва             │
│  ingress:         Правила для вхідного трафіку             │
│  egress:          Правила для вихідного трафіку            │
│                                                             │
│  ОПЦІЇ СЕЛЕКТОРІВ:                                         │
│  • podSelector    - Збіг за мітками подів                  │
│  • namespaceSelector - Збіг за мітками просторів імен     │
│  • ipBlock        - Збіг за діапазоном CIDR               │
│  • ports          - Збіг за портом/протоколом             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Шаблон заборони за замовчуванням

Рекомендована відправна точка для мережевої безпеки:

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

# Дозволити frontend комунікувати з backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Безпека Service Mesh

Service mesh додає sidecar-проксі до кожного поду, забезпечуючи функції безпеки понад мережеві політики.

┌─────────────────────────────────────────────────────────────┐
│              АРХІТЕКТУРА SERVICE MESH                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  БЕЗ SERVICE MESH:                                         │
│  ┌─────────┐                    ┌─────────┐                │
│  │  Pod A  │ ─── HTTP/TCP ───→ │  Pod B  │                │
│  │  (app)  │                    │  (app)  │                │
│  └─────────┘                    └─────────┘                │
│  Незашифровано, без ідентифікації                           │
│                                                             │
│  З SERVICE MESH:                                           │
│  ┌─────────────────┐            ┌─────────────────┐        │
│  │  Pod A          │            │  Pod B          │        │
│  │  ┌─────┐┌─────┐│            │┌─────┐┌─────┐   │        │
│  │  │ app ││proxy│├── mTLS ───→│proxy ││ app │   │        │
│  │  └─────┘└─────┘│            │└─────┘└─────┘   │        │
│  └─────────────────┘            └─────────────────┘        │
│  Зашифровано, з ідентифікацією, спостережуваність          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Функції безпеки service mesh

Функція	Опис
mTLS	Автоматичне шифрування між сервісами
Ідентифікація	Криптографічна ідентифікація для кожного навантаження
Авторизація	Детальні політики доступу
Спостережуваність	Метрики трафіку, трейсинг
Контроль трафіку	Обмеження швидкості, повтори, тайм-аути

Поширені опції service mesh

Mesh	Опис
Istio	Повнофункціональний, складний, широко впроваджений
Linkerd	Легкий, простий, швидкий
Cilium	На основі eBPF, поєднаний CNI та mesh
Consul Connect	Service mesh від HashiCorp

Шифрування трафіку

mTLS (Взаємний TLS)

┌─────────────────────────────────────────────────────────────┐
│              mTLS ПОЯСНЕННЯ                                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЗВИЧАЙНИЙ TLS (односторонній)                             │
│  Клієнт ──────→ Сервер                                     │
│  • Клієнт перевіряє ідентифікацію сервера                  │
│  • Сервер не перевіряє клієнта                             │
│  • Як HTTPS до вебсайту                                    │
│                                                             │
│  ВЗАЄМНИЙ TLS (двосторонній)                               │
│  Клієнт ←─────→ Сервер                                     │
│  • Клієнт перевіряє ідентифікацію сервера                  │
│  • Сервер перевіряє ідентифікацію клієнта                  │
│  • Обидві сторони автентифіковані                          │
│                                                             │
│  В KUBERNETES:                                             │
│  • Service mesh забезпечує mTLS автоматично                │
│  • Кожен под отримує сертифікат                            │
│  • Сертифікати ротуються автоматично                       │
│  • Досягнута мережа нульової довіри                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

Мережеві політики є просторовими - вони впливають лише на поди у своєму просторі імен. Неможливо створити кластерну “заборону всього” стандартними мережевими політиками.
Flannel не підтримує мережеві політики - це один з найпоширеніших плагінів CNI, але він забезпечує лише базову зв’язність. Для впровадження політик потрібен Calico або Cilium.
Впровадження service mesh зростає - хоча це додає складність, переваги безпеки (автоматичний mTLS, ідентифікація) роблять його дедалі поширенішим у продакшн.
Cilium використовує eBPF - це дозволяє впроваджувати політики на рівні ядра, що робить його швидшим та потужнішим за рішення на основі iptables.

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

Помилка	Чому це шкодить	Рішення
Без мережевих політик	Всі поди можуть дістатися до всіх	Впровадити заборону за замовчуванням
Flannel без додатку політик	Мережеві політики не діють	Calico, Cilium або додати підтримку
Дозвіл всього вихідного трафіку	Поди можуть витягувати дані куди завгодно	Контролюйте вихідний трафік
Не шифрувати внутрішній трафік	Вразливий до прослуховування	Service mesh з mTLS
Надмірно дозвільні політики	Зводить нанівець мету політик	Дотримуйтесь мінімальних привілеїв

Тест

Яка мережева поведінка за замовчуванням у Kubernetes?

Відповідь
Дозволити весь трафік. За замовчуванням всі поди можуть комунікувати з усіма іншими подами та зовнішніми точками. Мережеві політики мають бути створені явно для обмеження трафіку.
Як мережеві політики поводяться, коли кілька політик застосовуються до поду?

Відповідь
Мережеві політики є адитивними. Дозволений трафік - це об'єднання всіх застосовних політик. Якщо будь-яка політика дозволяє трафік, він дозволений.
Що робить мережева політика з порожнім podSelector?

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

Відповідь
Плагін CNI може не підтримувати мережеві політики. Flannel, наприклад, не впроваджує мережеві політики. Потрібен CNI як Calico, Cilium або Weave, що підтримує впровадження політик.
Яку функцію безпеки забезпечує mTLS, яку не забезпечує звичайний TLS?

Відповідь
Взаємну автентифікацію. У звичайному TLS лише клієнт перевіряє сервер. У mTLS обидві сторони перевіряють ідентифікацію одна одної, запобігаючи атакам імітації.

Підсумок

Мережева безпека в Kubernetes вимагає активної конфігурації:

Концепція	Ключові моменти
Поведінка за замовчуванням	Всі поди можуть дістатися до всіх - впровадьте заборону
Плагіни CNI	Обирайте з підтримкою мережевих політик (Calico, Cilium)
Мережеві політики	Адитивні, просторові, вимагають явних дозволів
Service Mesh	Забезпечує mTLS, ідентифікацію та детальну авторизацію
mTLS	Шифрує трафік ТА перевіряє обидві сторони

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

Модуль 2.4: PKI та сертифікати - Розуміння управління сертифікатами Kubernetes та PKI.