Модуль 2.4: Оновлення безпеки Kubernetes

Складність: [MEDIUM] - Повторення CKA з фокусом на безпеку

Час на виконання: 35-40 хвилин

Передумови: Знання оновлень з CKA, досвід з kubeadm

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

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

Оцінити CVE Kubernetes для визначення терміновості оновлення та впливу на безпеку
Реалізувати процедури оновлення з фокусом на безпеку за допомогою kubeadm
Аудитувати версії кластера для виявлення компонентів з відомими вразливостями
Спроєктувати стратегію оновлення, що мінімізує вікна відкритості для загроз безпеки

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

Використання застарілих версій Kubernetes є ризиком безпеки. Кожен реліз виправляє вразливості — деякі критичні. На іспиті CKS вас можуть попросити перевірити версії, зрозуміти шляхи оновлення або переконатися, що патчі безпеки застосовані.

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

Безпекові наслідки версій

┌─────────────────────────────────────────────────────────────┐
│              ЖИТТЄВИЙ ЦИКЛ БЕЗПЕКИ ВЕРСІЙ                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Модель підтримки Kubernetes:                              │
│  ─────────────────────────────────────────────────────────  │
│  • 3 мінорні версії підтримуються одночасно                │
│  • Виправлення безпеки портуються на всі 3                 │
│  • Старіші версії: БЕЗ ПАТЧІВ БЕЗПЕКИ                     │
│                                                             │
│  Приклад (якщо поточна 1.35):                              │
│  ├── 1.35 ✓ Підтримується (патчі безпеки)                 │
│  ├── 1.34 ✓ Підтримується (патчі безпеки)                 │
│  ├── 1.33 ✓ Підтримується (патчі безпеки)                 │
│  ├── 1.32 ✗ Кінець підтримки (без патчів!)                │
│  └── 1.31 ✗ Не підтримується (вразливий!)                 │
│                                                             │
│  Ризик використання непідтримуваних версій:                │
│  ⚠️  Відомі CVE залишаються невиправленими                │
│  ⚠️  Немає рекомендацій з безпеки                          │
│  ⚠️  Порушення відповідності                               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Перевірка поточних версій

# Перевірити версію кластера
kubectl version

# Перевірити версії всіх компонентів
kubectl get nodes -o wide

# Перевірити версії компонентів площини управління
kubectl get pods -n kube-system -o jsonpath='{range .items[*]}{.metadata.name}: {.spec.containers[0].image}{"\n"}{end}' | grep -E "kube-apiserver|kube-controller|kube-scheduler|etcd"

# Перевірити версії kubelet на вузлах
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}: {.status.nodeInfo.kubeletVersion}{"\n"}{end}'

Розуміння CVE

┌─────────────────────────────────────────────────────────────┐
│              ПРИКЛАД CVE KUBERNETES                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CVE-2024-XXXX: Втеча з контейнера через Symlink-атаку    │
│                                                             │
│  Серйозність: HIGH (CVSS 8.8)                              │
│  Вразливі: v1.26.0 - v1.27.5                               │
│  Виправлено: v1.27.6, v1.28.2, v1.29.0                    │
│                                                             │
│  Вплив:                                                    │
│  Зловмисний контейнер може записувати у файлову систему   │
│  хоста, використовуючи спеціально створене символічне      │
│  посилання                                                  │
│                                                             │
│  Дія:                                                      │
│  Негайно оновити до виправленої версії                     │
│                                                             │
│  Де шукати CVE:                                            │
│  • kubernetes.io/security                                  │
│  • github.com/kubernetes/kubernetes/security/advisories   │
│  • cve.mitre.org                                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Процес оновлення (огляд безпеки)

Контрольний список безпеки перед оновленням

# 1. Перевірити вразливості поточної версії
kubectl version --short
# Дослідити CVE для вашої версії

# 2. Переглянути примітки до релізу щодо виправлень безпеки
# https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/

# 3. Створити резервну копію критичних компонентів
kubectl get all -A -o yaml > cluster-backup.yaml
ETCDCTL_API=3 etcdctl snapshot save backup.db

# 4. Перевірити попередження про застарілі API
kubectl api-resources --verbs=list -o name | xargs -n 1 kubectl get --show-labels -A 2>&1 | grep -i deprecated

Оновлення Kubeadm (короткий огляд)

# На площині управління
sudo apt update
sudo apt install -y kubeadm=1.35.0-*

# Спланувати оновлення
sudo kubeadm upgrade plan

# Застосувати оновлення
sudo kubeadm upgrade apply v1.35.0

# Оновити kubelet та kubectl
sudo apt install -y kubelet=1.35.0-* kubectl=1.35.0-*
sudo systemctl daemon-reload
sudo systemctl restart kubelet

Питання безпеки при оновленні

1. Застарілі API

# Старий API (може бути видалений у новій версії)
apiVersion: extensions/v1beta1
kind: Ingress

# Новий API
apiVersion: networking.k8s.io/v1
kind: Ingress

2. Зміни контролерів допуску

# Перевірити, чи видалено PodSecurityPolicy
# (Видалено в 1.25, використовуйте Pod Security Admission натомість)
kubectl get psp 2>&1 | grep -q "the server doesn't have" && echo "PSP already removed"

3. Зміни Feature Gate

# Деякі функції безпеки переходять з бета-версії в стабільну
# Перевірте, чи потрібно оновити feature gates в API-сервері

# Приклад: функція PodSecurity (стабільна з 1.25)
- --feature-gates=PodSecurity=true  # Може бути більше не потрібна

Політика розбіжності версій

┌─────────────────────────────────────────────────────────────┐
│              ПРАВИЛА РОЗБІЖНОСТІ ВЕРСІЙ                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  kube-apiserver:                                           │
│  └── Повинен бути найновішим компонентом у кластері        │
│                                                             │
│  kube-controller-manager, kube-scheduler:                  │
│  └── Та сама або на одну мінорну версію старіша            │
│      за API-сервер                                          │
│                                                             │
│  kubelet:                                                  │
│  └── Та сама, на одну або дві мінорні версії старіша       │
│  └── Ніколи не новіша за API-сервер                        │
│                                                             │
│  kubectl:                                                  │
│  └── На одну мінорну версію новіша або старіша             │
│                                                             │
│  Чому це важливо для безпеки:                              │
│  • Неузгоджені версії можуть мати непередбачувану поведінку│
│  • Виправлення безпеки можуть не працювати при розбіжності │
│  • Оновлюйте спочатку API-сервер, потім інші компоненти   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Перевірка оновлень безпеки

# Перевірити оголошення безпеки Kubernetes
# https://kubernetes.io/docs/reference/issues-security/security/

# Перевірити конкретний компонент на CVE
trivy image registry.k8s.io/kube-apiserver:v1.30.0

# Перевірити ОС вузла на оновлення безпеки
apt list --upgradable 2>/dev/null | grep -i security

# Використати kube-bench для перевірки налаштувань безпеки після оновлення
./kube-bench run --targets=master

Відкат оновлення

Коли робити відкат

┌─────────────────────────────────────────────────────────────┐
│              ТРИГЕРИ ВІДКАТУ                                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Робити відкат, якщо оновлення спричиняє:                  │
│  ─────────────────────────────────────────────────────────  │
│  • API-сервер не запускається                              │
│  • Збої автентифікації                                     │
│  • RBAC не працює                                          │
│  • Проблеми з мережею (несумісність CNI)                   │
│  • Контролер допуску відхиляє дійсні навантаження          │
│                                                             │
│  НЕ робити відкат через:                                   │
│  ─────────────────────────────────────────────────────────  │
│  • Попередження про застарілі API (виправте маніфести)     │
│  • Зміни функцій (адаптуйте робочі процеси)               │
│  • Відомі проблеми з обхідними рішеннями                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Команди відкату

# Перевірити попередню версію kubelet
journalctl -u kubelet | grep "Kubelet version" | head -1

# Знизити версію kubelet (при потребі)
sudo apt install kubelet=<previous-version>
sudo systemctl restart kubelet

# Примітка: kubeadm не підтримує пряме зниження версії
# Для площини управління відновлюйте з резервної копії etcd

Реальні сценарії іспиту

Сценарій 1: Перевірка готовності до оновлення

# Перевірити, що поточні версії збігаються
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}: {.status.nodeInfo.kubeletVersion}{"\n"}{end}'

# Всі повинні показувати однакову версію
# Неузгоджені версії = ризик безпеки

# Перевірити використання застарілих API
kubectl get --raw /metrics | grep apiserver_requested_deprecated

Сценарій 2: Перевірка безпеки після оновлення

# Після оновлення перевірити налаштування безпеки
# 1. Перевірити, що API-сервер працює
kubectl get pods -n kube-system | grep apiserver

# 2. Переконатися, що RBAC працює
kubectl auth can-i create pods --as=developer

# 3. Перевірити контролери допуску
kubectl get pods -n kube-system -o yaml | grep admission

# 4. Запустити kube-bench
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Сценарій 3: Пошук версії з виправленням CVE

# Питання: "Оновити кластер до версії, що виправляє CVE-2024-XXXX"

# 1. Дослідити CVE (на іспиті можуть надати інформацію)
# 2. Знайти виправлену версію
kubectl version --short

# 3. Спланувати оновлення
kubeadm upgrade plan | grep -E "v1\.[0-9]+\.[0-9]+"

# 4. Виконати оновлення до виправленої версії

Оновлення керованого Kubernetes

┌─────────────────────────────────────────────────────────────┐
│              ОСОБЛИВОСТІ ОНОВЛЕННЯ КЕРОВАНОГО K8S           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  EKS (AWS):                                                │
│  • Площина управління оновлюється окремо від вузлів        │
│  • Керовані групи вузлів можуть оновлюватися автоматично   │
│  • eksctl upgrade cluster                                  │
│                                                             │
│  GKE (GCP):                                                │
│  • Канали релізів для автоматичних оновлень                │
│  • Вікна обслуговування для планових оновлень              │
│  • gcloud container clusters upgrade                       │
│                                                             │
│  AKS (Azure):                                              │
│  • Доступний канал автооновлення                           │
│  • Оновлення образів вузлів окремо                         │
│  • az aks upgrade                                          │
│                                                             │
│  Примітка щодо безпеки:                                    │
│  Керований K8s часто відстає від останньої версії          │
│  (для стабільності). Перевіряйте графік патчів безпеки     │
│  провайдера.                                                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

Kubernetes має квартальні релізи (приблизно кожні 4 місяці). Кожен реліз отримує близько 14 місяців підтримки патчами.
Серйозність CVE не завжди означає можливість експлуатації. Деякі “критичні” CVE потребують дуже специфічних умов. Читайте повну рекомендацію.
Комітет з реагування на безпеку Kubernetes обробляє звіти про вразливості. Вони координують виправлення для всіх підтримуваних версій.
Автооновлення продакшен-кластерів є ризикованим. Багато організацій використовують версію на одну менше за останню, щоб отримати перевагу від виявлення помилок спільнотою.

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

Помилка	Чому це шкодить	Рішення
Пропуск версій	Може зламати компоненти	Оновлюйте на одну мінорну версію за раз
Оновлення робочих вузлів до площини управління	Порушення розбіжності версій	Спочатку площина управління
Не перевіряти застарілі API	Навантаження можуть зламатися	Перегляньте примітки до релізу
Без резервної копії перед оновленням	Неможливо зробити відкат	Завжди створюйте резервну копію etcd
Використання непідтримуваних версій	Без патчів безпеки	Тримайтеся у вікні підтримки

Тест

Скільки мінорних версій Kubernetes підтримуються патчами безпеки?

Відповідь
Три мінорні версії. Наприклад, якщо поточна 1.35, версії 1.35, 1.34 та 1.33 отримують патчі безпеки.
Який компонент слід оновлювати першим у кластері?

Відповідь
kube-apiserver (площина управління). Він завжди повинен бути найновішим компонентом. Потім оновлюйте controller-manager, scheduler і, нарешті, kubelet.
Як перевірити, чи використовує ваш кластер застарілі API?

Відповідь
Перевірити метрики API-сервера: `kubectl get --raw /metrics | grep apiserver_requested_deprecated` або переглянути попередження kubectl про застарілість при доступі до ресурсів.
Чому використання непідтримуваної версії Kubernetes є ризиком безпеки?

Відповідь
Непідтримувані версії не отримують патчів безпеки. Відомі CVE залишаються невиправленими, залишаючи кластер вразливим до експлуатації.

Практична вправа

Завдання: Практика оцінювання безпеки перед оновленням та перевірки після оновлення.

# Крок 1: Створити тестовий простір імен для перевірки стану до/після "оновлення"
kubectl create namespace upgrade-test

# Крок 2: Розгорнути тестове навантаження з контекстом безпеки
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: security-test
  namespace: upgrade-test
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
  containers:
  - name: app
    image: busybox
    command: ["sleep", "3600"]
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
EOF

# Крок 3: Зберегти стан перед оновленням (завжди створюйте резервну копію перед оновленням!)
echo "=== Збереження стану перед оновленням ==="
kubectl get all -n upgrade-test -o yaml > /tmp/pre-upgrade-backup.yaml
echo "Резервну копію збережено у /tmp/pre-upgrade-backup.yaml"

# Крок 4: Перевірити поточні версії кластера
echo "=== Поточні версії ==="
kubectl version --short 2>/dev/null || kubectl version

echo "=== Версії вузлів ==="
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}: {.status.nodeInfo.kubeletVersion}{"\n"}{end}'

# Крок 5: Перевірити використання застарілих API (важливо перед оновленням)
echo "=== Перевірка застарілих API ==="
# Пошук застарілих версій API у наших ресурсах
kubectl get pod security-test -n upgrade-test -o yaml | grep "apiVersion"

# Крок 6: Переконатися, що RBAC все ще працює (ключова перевірка після оновлення)
echo "=== Перевірка RBAC ==="
kubectl auth can-i list pods -n upgrade-test --as=system:serviceaccount:upgrade-test:default

# Крок 7: Запустити перевірку безпеки (імітує перевірки після оновлення)
echo "=== Перевірка контексту безпеки ==="
kubectl get pod security-test -n upgrade-test -o jsonpath='{.spec.securityContext}' && echo ""
kubectl get pod security-test -n upgrade-test -o jsonpath='{.spec.containers[0].securityContext}' && echo ""

# Крок 8: Переконатися, що Pod працює правильно
echo "=== Статус Pod ==="
kubectl get pod security-test -n upgrade-test

# Крок 9: Перевірити результати kube-bench (запускається на реальному вузлі)
echo "=== Перевірка безпекового бенчмарку ==="
echo "На площині управління запустіть: ./kube-bench run --targets=master"
echo "На робочих вузлах запустіть: ./kube-bench run --targets=node"

# Крок 10: Перевірити підтримку NetworkPolicy (важливо для безпеки)
echo "=== Тест підтримки NetworkPolicy ==="
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-policy
  namespace: upgrade-test
spec:
  podSelector:
    matchLabels:
      app: security-test
  policyTypes:
  - Ingress
  - Egress
EOF

kubectl get networkpolicy -n upgrade-test

# Очищення
echo "=== Очищення ==="
kubectl delete namespace upgrade-test
rm -f /tmp/pre-upgrade-backup.yaml

echo ""
echo "=== Вправа завершена ==="
echo "Виконані ключові перевірки безпеки оновлення:"
echo "1. ✓ Створено резервну копію стану кластера"
echo "2. ✓ Перевірено узгодженість версій"
echo "3. ✓ Перевірено відсутність застарілих API"
echo "4. ✓ Підтверджено роботу RBAC"
echo "5. ✓ Валідовано контексти безпеки"
echo "6. ✓ Перевірено підтримку NetworkPolicy"

Критерії успіху: Успішно виконати резервне копіювання перед оновленням, аудит версій та контрольний список перевірки безпеки після оновлення.

Підсумок

Безпека версій:

Тільки 3 мінорні версії отримують патчі
Непідтримувана = вразлива
Оновлюйте регулярно

Порядок оновлення:

Площина управління (спочатку API-сервер)
Контролери та планувальник
Kubelet на робочих вузлах

Перевірки безпеки після оновлення:

API-сервер працює
RBAC працює
Контролери допуску активні
Запустити kube-bench

Поради для іспиту:

Знайте, як перевірити версії
Розумійте політику розбіжності версій
Будьте в курсі впливу застарілих API

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

Модуль 2.5: Обмеження доступу до API — Мережеві та автентифікаційні обмеження для API-сервера.