Модуль 2.1: Безпека площини управління
Складність:
[СЕРЕДНЯ]- Основні знанняЧас на виконання: 30-35 хвилин
Передумови: Модуль 1.3: Принципи безпеки
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Оцінити конфігурації безпеки API server, etcd, scheduler та controller manager
- Оцінити вплив компрометації площини управління на загальну безпеку кластера
- Визначити небезпечні налаштування площини управління: анонімна автентифікація, незашифрований etcd, надмірний RBAC
- Пояснити як зміцнити кожен компонент площини управління відповідно до рекомендацій CIS Benchmark
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Площина управління - це мозок Kubernetes. Якщо її скомпрометовано, атакуючий контролює весь ваш кластер - кожен под, кожен секрет, кожне навантаження. Розуміння безпеки площини управління критичне не лише для іспиту, а й для будь-якого продакшн-розгортання Kubernetes.
Це один з найбільших доменів іспиту (22%) разом із безпекою вузлів та мережі. Опануйте це, і ви на шляху до складання.
Архітектура площини управління
Розділ «Архітектура площини управління»┌─────────────────────────────────────────────────────────────┐│ ПЛОЩИНА УПРАВЛІННЯ KUBERNETES │├─────────────────────────────────────────────────────────────┤│ ││ ┌─────────────────────────────────────────────────────┐ ││ │ API SERVER │ ││ │ • Вхідні двері до кластера │ ││ │ • Всі запити проходять через нього │ ││ │ • Автентифікація, авторизація, Admission │ ││ └─────────────────────────────────────────────────────┘ ││ │ │ │ ││ ▼ ▼ ▼ ││ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ ││ │ ETCD │ │ SCHEDULER │ │ CONTROLLER MANAGER │ ││ │ │ │ │ │ │ ││ │ • База │ │ • Розмі- │ │ • Узгодження │ ││ │ даних │ │ щення │ │ • Вбудовані │ ││ │ • Секрети │ │ подів │ │ контролери │ ││ │ • Стан │ │ │ │ │ ││ └─────────────┘ └─────────────┘ └─────────────────────┘ ││ ││ Кожен компонент має свої вимоги безпеки ││ │└─────────────────────────────────────────────────────────────┘Безпека API Server
Розділ «Безпека API Server»API server - найкритичніший компонент. Це єдиний компонент, який комунікує з etcd та є шлюзом для всіх операцій кластера.
Автентифікація
Розділ «Автентифікація»Хто робить цей запит?
┌─────────────────────────────────────────────────────────────┐│ АВТЕНТИФІКАЦІЯ API SERVER │├─────────────────────────────────────────────────────────────┤│ ││ МЕТОДИ АВТЕНТИФІКАЦІЇ ││ ││ ┌─────────────────────────────────────────────────────┐ ││ │ КЛІЄНТСЬКІ СЕРТИФІКАТИ X.509 │ ││ │ • Використовуються: kubelet, controller-manager │ ││ │ • CN = ім'я користувача, O = групи │ ││ │ • Керуються PKI кластера │ ││ └─────────────────────────────────────────────────────┘ ││ ││ ┌─────────────────────────────────────────────────────┐ ││ │ ТОКЕНИ SERVICE ACCOUNT │ ││ │ • Використовуються: подами │ ││ │ • JWT-токени, автоматично монтуються │ ││ │ • Прив'язані до конкретної аудиторії та терміну │ ││ └─────────────────────────────────────────────────────┘ ││ ││ ┌─────────────────────────────────────────────────────┐ ││ │ OIDC (OpenID Connect) │ ││ │ • Використовується: людьми │ ││ │ • Інтегрується з провайдерами ідентифікації │ ││ │ • Підтримує MFA через провайдера │ ││ └─────────────────────────────────────────────────────┘ ││ ││ ┌─────────────────────────────────────────────────────┐ ││ │ WEBHOOK TOKEN AUTHENTICATION │ ││ │ • Використовується: кастомними інтеграціями │ ││ │ • Зовнішній сервіс валідує токени │ ││ └─────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────┘Авторизація
Розділ «Авторизація»Чи дозволено цій ідентифікації виконати цю дію?
┌─────────────────────────────────────────────────────────────┐│ АВТОРИЗАЦІЯ API SERVER │├─────────────────────────────────────────────────────────────┤│ ││ РЕЖИМИ АВТОРИЗАЦІЇ (у порядку оцінки) ││ ││ NODE ││ • Авторизує запити kubelet ││ • Обмежений ресурсами для подів на цьому вузлі ││ ││ RBAC (Найпоширеніший) ││ • Контроль доступу на основі ролей ││ • Roles, ClusterRoles, Bindings ││ • Детальні дозволи ││ ││ ABAC (Застарілий) ││ • Контроль доступу на основі атрибутів ││ • Політики на основі файлів ││ • Потрібен перезапуск API server для змін ││ ││ WEBHOOK ││ • Зовнішній сервіс авторизації ││ • Кастомні рушії політик (OPA/Gatekeeper) ││ ││ Типова конфігурація: --authorization-mode=Node,RBAC ││ │└─────────────────────────────────────────────────────────────┘Admission Control
Розділ «Admission Control»Чи повинен цей валідний, авторизований запит бути дозволений?
┌─────────────────────────────────────────────────────────────┐│ ПОТІК ADMISSION CONTROL │├─────────────────────────────────────────────────────────────┤│ ││ Запит → Автентифікація → Авторизація → Admission ││ ││ ADMISSION CONTROLLERS ││ ││ MUTATING (модифікують запити) ││ ├── DefaultStorageClass: Додає клас сховища ││ ├── ServiceAccount: Додає service account за замовчуванням ││ └── Кастомні webhooks: Додають sidecar, мітки ││ ││ VALIDATING (приймають/відхиляють запити) ││ ├── PodSecurity: Впроваджує Pod Security Standards ││ ├── ValidatingAdmissionPolicy: Валідація на основі CEL ││ └── Кастомні webhooks: Впровадження політик ││ ││ КРИТИЧНІ ДЛЯ БЕЗПЕКИ ADMISSION CONTROLLERS ││ ├── PodSecurity (PSA) ││ ├── NodeRestriction ││ ├── ValidatingAdmissionWebhook ││ └── MutatingAdmissionWebhook ││ │└─────────────────────────────────────────────────────────────┘Прапорці безпеки API Server
Розділ «Прапорці безпеки API Server»Важлива конфігурація, пов’язана з безпекою:
| Прапорець | Призначення | Безпечне значення |
|---|---|---|
--anonymous-auth | Дозвіл неавтентифікованих запитів | false для продакшн |
--authorization-mode | Як авторизувати запити | Node,RBAC |
--enable-admission-plugins | Які admission controllers | Включити PodSecurity,NodeRestriction |
--audit-log-path | Куди писати логи аудиту | Встановити валідний шлях |
--tls-cert-file | TLS-сертифікат API server | Має бути налаштовано |
--etcd-cafile | CA для перевірки etcd | Має бути налаштовано |
Безпека etcd
Розділ «Безпека etcd»etcd зберігає весь стан кластера, включаючи секрети. Його безпека є першочерговою.
┌─────────────────────────────────────────────────────────────┐│ БЕЗПЕКА ETCD │├─────────────────────────────────────────────────────────────┤│ ││ ETCD МІСТИТЬ: ││ • Всі об'єкти Kubernetes (pods, deployments тощо) ││ • Секрети (за замовчуванням у base64) ││ • ConfigMaps ││ • Конфігурацію RBAC ││ • Токени service account ││ ││ ЯКЩО ETCD СКОМПРОМЕТОВАНО: ││ • Всі секрети розкриті ││ • Стан кластера можна змінити ││ • Повна компрометація кластера ││ │└─────────────────────────────────────────────────────────────┘Контролі безпеки etcd
Розділ «Контролі безпеки etcd»┌─────────────────────────────────────────────────────────────┐│ КОНТРОЛІ БЕЗПЕКИ ETCD │├─────────────────────────────────────────────────────────────┤│ ││ КОНТРОЛЬ ДОСТУПУ ││ ├── Лише API server має доступ до etcd ││ ├── Мережева ізоляція (фаєрвол, групи безпеки) ││ ├── Автентифікація клієнтським сертифікатом ││ └── Без прямого доступу з подів ││ ││ ШИФРУВАННЯ ПРИ ПЕРЕДАЧІ ││ ├── TLS для комунікації client-to-server ││ ├── TLS для peer-to-peer (кластер etcd) ││ └── Взаємний TLS (mTLS) рекомендовано ││ ││ ШИФРУВАННЯ У СПОКОЇ ││ ├── Шифрування секретів Kubernetes (EncryptionConfig) ││ ├── Опції провайдерів: aescbc, aesgcm, kms ││ ├── Інтеграція KMS для управління ключами ││ └── Патерн конвертного шифрування ││ ││ БЕЗПЕКА РЕЗЕРВНИХ КОПІЙ ││ ├── Шифруйте резервні копії ││ ├── Захищайте сховище резервних копій ││ └── Тестуйте процедури відновлення ││ │└─────────────────────────────────────────────────────────────┘Шифрування секретів у спокої
Розділ «Шифрування секретів у спокої»За замовчуванням секрети Kubernetes лише кодуються base64 в etcd - не шифруються:
# Приклад EncryptionConfigurationapiVersion: apiserver.config.k8s.io/v1kind: EncryptionConfigurationresources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: <base64-encoded-key> - identity: {} # Резервний для читання незашифрованих| Провайдер | Опис | Випадок використання |
|---|---|---|
identity | Без шифрування | Ніколи для продакшн |
aescbc | Шифрування AES-CBC | Для самокерованих кластерів |
aesgcm | Шифрування AES-GCM | Швидше за aescbc |
kms | Зовнішнє управління ключами | Найкраще для відповідності |
Безпека Scheduler
Розділ «Безпека Scheduler»Scheduler вирішує, де запускати поди. Його компрометація може стратегічно розмістити поди.
┌─────────────────────────────────────────────────────────────┐│ БЕЗПЕКА SCHEDULER │├─────────────────────────────────────────────────────────────┤│ ││ ОБОВ'ЯЗКИ SCHEDULER ││ • Обирає вузли для незапланованих подів ││ • Дотримується запитів та лімітів ресурсів ││ • Виконує правила affinity та anti-affinity ││ • Впроваджує taints та tolerations ││ ││ ПРОБЛЕМИ БЕЗПЕКИ ││ ├── Працює зі значними привілеями кластера ││ ├── Компрометація може вплинути на розміщення подів ││ ├── Може обійти ізоляцію вузлів ││ └── Може спричинити відмову в обслуговуванні ││ ││ КОНТРОЛІ БЕЗПЕКИ ││ ├── Автентифікація клієнтським сертифікатом до API server ││ ├── Мінімальні дозволи RBAC (вбудована прив'язка) ││ ├── Запуск на виділених вузлах площини управління ││ └── Мережева ізоляція від вузлів навантажень ││ │└─────────────────────────────────────────────────────────────┘Безпека Controller Manager
Розділ «Безпека Controller Manager»Controller manager виконує цикли управління, що підтримують бажаний стан.
┌─────────────────────────────────────────────────────────────┐│ БЕЗПЕКА CONTROLLER MANAGER │├─────────────────────────────────────────────────────────────┤│ ││ КОНТРОЛЕРИ ВКЛЮЧАЮТЬ: ││ • Node controller (здоров'я вузлів) ││ • Replication controller (репліки подів) ││ • Endpoints controller (точки доступу сервісів) ││ • ServiceAccount controller (створює SA за замовчуванням) ││ • Та багато інших... ││ ││ ПРОБЛЕМИ БЕЗПЕКИ ││ ├── Доступ до ключа підписання service account ││ ├── Може створювати/видаляти поди та сервіси ││ ├── Керує життєвим циклом вузлів ││ └── Компрометація = вплив на весь кластер ││ ││ КЛЮЧОВІ ПРАПОРЦІ БЕЗПЕКИ ││ ├── --use-service-account-credentials=true ││ │ (Окремий SA для кожного контролера) ││ ├── --root-ca-file ││ │ (CA для перевірки API server) ││ └── --service-account-private-key-file ││ (Ключ для підписання токенів SA) ││ │└─────────────────────────────────────────────────────────────┘Мережева безпека площини управління
Розділ «Мережева безпека площини управління»┌─────────────────────────────────────────────────────────────┐│ МЕРЕЖА ПЛОЩИНИ УПРАВЛІННЯ │├─────────────────────────────────────────────────────────────┤│ ││ РЕКОМЕНДОВАНА АРХІТЕКТУРА ││ ││ ┌────────────────────────────────────────────────────┐ ││ │ ПРИВАТНА ПІДМЕРЕЖА (Площина управління) │ ││ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ ││ │ │ API │ │ etcd │ │ Sched │ │ Ctrl │ │ ││ │ │ Server │ │ │ │ │ │ Mgr │ │ ││ │ └────┬────┘ └─────────┘ └─────────┘ └─────────┘ │ ││ │ │ │ ││ └───────┼────────────────────────────────────────────┘ ││ │ (Лише API server відкритий) ││ ▼ ││ ┌────────────────────────────────────────────────────┐ ││ │ ПРИВАТНА ПІДМЕРЕЖА (Робочі вузли) │ ││ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ ││ │ │ Вузол 1 │ │ Вузол 2 │ │ Вузол 3 │ │ ││ │ │ kubelet │ │ kubelet │ │ kubelet │ │ ││ │ └─────────┘ └─────────┘ └─────────┘ │ ││ └────────────────────────────────────────────────────┘ ││ ││ ВИМОГИ БЕЗПЕКИ: ││ • etcd: Доступний лише з API server ││ • API server: Доступний з вузлів та адміністраторів ││ • Scheduler/CM: Потрібен доступ лише до API server ││ • Рекомендовано приватну точку доступу API ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
API server обробляє тисячі запитів на секунду у навантажених кластерах. Кожен запит проходить автентифікацію, авторизацію та admission - усі потенційні контрольні точки безпеки.
-
etcd не було розроблено для Kubernetes - це сховище ключ-значення загального призначення. Kubernetes адаптував його, тому шифрування у спокої не ввімкнено за замовчуванням.
-
У керованому Kubernetes ви зазвичай не маєте прямого доступу до etcd. Хмарний провайдер управляє ним та надає опції шифрування через свою конфігурацію.
-
Режим авторизації Node було додано спеціально для запобігання доступу скомпрометованих kubelet до ресурсів подів на інших вузлах - реальний вектор атаки.
Поширені помилки
Розділ «Поширені помилки»| Помилка | Чому це шкодить | Рішення |
|---|---|---|
| Увімкнена анонімна автентифікація | Будь-хто може запитувати API | Вимкнути --anonymous-auth |
| Без шифрування etcd | Секрети зберігаються відкритим текстом | Увімкнути шифрування у спокої |
| etcd відкритий мережі | Прямий доступ обходить безпеку API | Мережева ізоляція |
| Публічна точка доступу API server | Відкритий для атак з інтернету | Використовуйте приватну точку |
| Відсутнє логування аудиту | Не можна виявити або розслідувати порушення | Увімкнути логування аудиту |
Тест
Розділ «Тест»-
Які три стадії обробки запитів API server?
Відповідь
Автентифікація (хто це?), Авторизація (чи дозволено?) та Admission Control (чи повинно бути дозволено/модифіковано?). -
Чому шифрування etcd у спокої важливе?
Відповідь
За замовчуванням секрети Kubernetes лише кодуються base64 в etcd, не шифруються. Якщо сховище etcd скомпрометовано, всі секрети розкриті. Шифрування у спокої захищає секрети навіть при доступі до базового сховища. -
Який режим авторизації обмежує kubelet доступом лише до ресурсів подів на його вузлі?
Відповідь
Режим авторизації Node. Він спеціально розроблений для обмеження доступу kubelet і має використовуватися разом з RBAC (`--authorization-mode=Node,RBAC`). -
Який компонент ЄДИНИЙ повинен мати прямий доступ до etcd?
Відповідь
API server. Всі інші компоненти (scheduler, controller manager, kubelet, користувачі) отримують доступ до стану кластера через API server. -
Яка різниця між mutating та validating admission controllers?
Відповідь
Mutating admission controllers можуть модифікувати запити (додавати мітки, впроваджувати sidecar). Validating admission controllers можуть лише приймати або відхиляти запити без їх модифікації.
Практична вправа: Оцінка безпеки площини управління
Розділ «Практична вправа: Оцінка безпеки площини управління»Сценарій: Перегляньте ці прапорці API server та визначте проблеми безпеки:
kube-apiserver \ --anonymous-auth=true \ --authorization-mode=AlwaysAllow \ --enable-admission-plugins=NamespaceLifecycle,ServiceAccount \ --audit-log-path="" \ --etcd-servers=http://etcd:2379Визначте щонайменше 4 проблеми безпеки:
Проблеми безпеки
-
--anonymous-auth=true- Дозволяє неавтентифіковані запити. Має бутиfalseдля продакшн. -
--authorization-mode=AlwaysAllow- Без перевірки авторизації. Має бутиNode,RBAC. -
Відсутні admission controllers - Немає
PodSecurityтаNodeRestriction. Додайте admission controllers для безпеки. -
--audit-log-path=""- Без логування аудиту. Має вказувати на валідний шлях. -
--etcd-servers=http://...- Незашифроване HTTP-з’єднання до etcd. Має використовувати HTTPS з TLS-сертифікатами.
Підсумок
Розділ «Підсумок»Безпека площини управління - це захист мозку Kubernetes:
| Компонент | Ключові контролі безпеки |
|---|---|
| API Server | TLS, автентифікація (сертифікати, OIDC), RBAC-авторизація, admission control |
| etcd | Мережева ізоляція, TLS, шифрування у спокої, шифрування резервних копій |
| Scheduler | Автентифікація сертифікатом, мережева ізоляція, мінімальні привілеї |
| Controller Manager | Автентифікація сертифікатом, окремі service accounts для контролерів |
Ключові моменти:
- Всі запити проходять через API server
- etcd має бути захищений - він містить всі секрети
- Використовуйте режим авторизації Node,RBAC
- Увімкніть admission controllers для безпеки
- Шифруйте etcd у спокої
Наступний модуль
Розділ «Наступний модуль»Модуль 2.2: Безпека вузлів - Захист робочих вузлів, kubelet та середовищ виконання контейнерів.