Модуль 2.1: Безпека площини управління

• Складність: [СЕРЕДНЯ] — базові знання
• Час на проходження: 30–35 хвилин
• Передумови: Модуль 1.3: Принципи безпеки

Результати навчання

Після завершення цього модуля ви зможете застосовувати ці навички під час оглядів площини управління, реагування на інциденти та усунення несправностей у сценаріях стилю KCSA:

1. Оцінити засоби контролю автентифікації, авторизації, допуску та аудиту API-сервера для площини управління Kubernetes 1.35.
2. Діагностувати відкритість etcd, шифрування транспорту, шифрування секретів та ризики резервних копій ще до того, як вони перетворяться на шляхи компрометації кластера.
3. Порівняти привілеї планувальника та контролер-менеджера, адреси прив’язки, облікові дані сервісних акаунтів та варіанти мережевої ізоляції.
4. Впровадити оцінювання площини управління, яке зіставляє небезпечні прапорці з посиленими налаштуваннями та пріоритетними завданнями з усунення вад.

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

Щойно зловмисник може звертатися до механізму, який створює, планує та зберігає стан кластера, кластер перестає бути межею й стає плацдармом для подальшої атаки. Хрестоматійний приклад 2018 року у великій автомобільній компанії задокументовано в модулі безпеки GUI напрямку CKS — дослідники виявили відкриту адміністративну консоль і спостерігали, як зловмисники перетворили середовище на майнінгову платформу. Публічні повідомлення зосередилися на майнінгу, бо він був помітним, але серйозніший урок стосувався досяжності площини управління. Прямий рахунок за той майнінг був не єдиним ризиком; розкриті хмарні облікові дані, метадані робочих навантажень та збережені дані застосунків можуть спричинити витрати на розслідування, регуляторні наслідки та зупинку бізнесу ще довго після того, як шкідливі Pod’и буде видалено.

Ця історія має значення, тому що безпека площини управління — це не декоративний чекліст із посилення захисту. API-сервер вирішує, чи запит є справжнім, чи має право діяти той, хто його надсилає, чи прийнятний об’єкт і чи записано подію для подальшого розслідування. etcd зберігає ту істину, яку захищає API-сервер, зокрема об’єкти Secret та політику RBAC. Планувальник і контролер-менеджер безперервно перетворюють бажаний стан на запущені робочі навантаження, тому їхні облікові дані та розташування в мережі визначають, наскільки далеко зможе просунутися зловмисник після відмови одного компонента.

Для іспиту KCSA безпека площини управління перебуває всередині великого домену безпеки компонентів кластера, але операційна цінність ширша за межі екзаменаційного плану. Команда в production, яка вміє оцінити прапорці API-сервера, діагностувати відкритість etcd, порівняти привілеї контролерів та впровадити повторюване оцінювання, може скоротити загальнокластерні шляхи компрометації ще до інциденту. Цей модуль використовує термінологію та приклади Kubernetes 1.35+; відповіді в тестах та підказки до рішень використовують поширений псевдонім оболонки k для kubectl.

Архітектура площини управління

Площина управління — це та частина Kubernetes, яка вирішує, яким має бути кластер, і записує, яким кластер є. Робочі вузли запускають контейнери, але вони не вигадують самостійно політику кластера, не призначають Pod’и, не ухвалюють рішень про допуск і не зберігають стійку базу даних стану. Саме ця відмінність пояснює, чому одне скомпрометоване робоче навантаження може бути проблемою рівня простору імен, тоді як скомпрометований API-сервер чи член etcd може стати проблемою всього кластера за лічені хвилини.

┌─────────────────────────────────────────────────────────────┐
│              KUBERNETES CONTROL PLANE                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                    API SERVER                        │   │
│  │  • Front door to the cluster                        │   │
│  │  • All requests go through here                     │   │
│  │  • Authentication, Authorization, Admission         │   │
│  └─────────────────────────────────────────────────────┘   │
│           │              │                │                 │
│           ▼              ▼                ▼                 │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐   │
│  │    ETCD     │ │  SCHEDULER  │ │ CONTROLLER MANAGER  │   │
│  │             │ │             │ │                     │   │
│  │ • Database  │ │ • Pod       │ │ • Reconciliation    │   │
│  │ • Secrets   │ │   placement │ │ • Built-in          │   │
│  │ • State     │ │             │ │   controllers       │   │
│  └─────────────┘ └─────────────┘ └─────────────────────┘   │
│                                                             │
│  Each component has specific security requirements         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Читайте діаграму згори, а не зліва направо. API-сервер — це вхідні двері, і кожна звичайна дія в кластері має заходити через ці двері, перш ніж досягне etcd. Планувальник і контролер-менеджер не обходять API-сервер, щоб маніпулювати «сирим» станом; вони спостерігають за об’єктами, ухвалюють рішення й записують оновлення назад через автентифіковані виклики API. Це створює навмисну точку звуження, де можна послідовно застосовувати ідентичність, авторизацію, політику допуску та журналювання аудиту.

Компроміс щодо безпеки полягає в тому, що точка звуження є водночас і ласим шматком. Якщо API-сервер приймає анонімні запити, використовує AlwaysAllow, пропускає важливі засоби контролю допуску або не може підтвердити ідентичність etcd, решта кластера успадковує цю слабкість. Якщо etcd досяжний з Pod’ів, скомпрометоване робоче навантаження може оминути всі захисні бар’єри API-сервера й читати або змінювати стан напряму. Якщо кінцеві точки планувальника та контролер-менеджера слухають широко, діагностичний інтерфейс, який був зручним під час налаштування, може перетворитися на зайву поверхню атаки.

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

Безпека API-сервера

API-сервер — найкритичніший компонент, тому що це єдиний компонент, який спілкується з etcd у справному дизайні Kubernetes, і тому що він є шлюзом для всіх операцій кластера. У Kubernetes 1.35+ очікуваний шлях запиту залишається тією самою багаторівневою моделлю ухвалення рішень: автентифікувати того, хто звертається, авторизувати запитані дієслово та ресурс, виконати засоби контролю допуску, зберегти прийнятий стан і записати записи аудиту, коли це налаштовано. Якщо якийсь крок вилучено чи послаблено, решта кроків мусить нести більше ризику, ніж було передбачено їхнім дизайном.

Автентифікація

Автентифікація відповідає на перше питання у шляху запиту: хто надсилає цей запит? Kubernetes підтримує кілька автентифікаторів, тому що кластери обслуговують різних учасників. Kubelet’и та компоненти площини управління часто використовують клієнтські сертифікати X.509, Pod’и використовують токени сервісних акаунтів, люди-користувачі зазвичай заходять через OIDC, а власні інтеграції можуть використовувати вебхук-автентифікацію за токеном. Мета безпеки — не віддавати перевагу одному методу всюди, а переконатися, що кожне джерело ідентичності є явним, відкличним та обмеженим конкретним сценарієм використання.

┌─────────────────────────────────────────────────────────────┐
│              API SERVER AUTHENTICATION                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  AUTHENTICATION METHODS                                     │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  X.509 CLIENT CERTIFICATES                          │   │
│  │  • Used by: kubelet, controller-manager, scheduler  │   │
│  │  • CN = username, O = groups                        │   │
│  │  • Managed by cluster PKI                           │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  SERVICE ACCOUNT TOKENS                             │   │
│  │  • Used by: Pods                                    │   │
│  │  • Since 1.24: short-lived projected/bound tokens   │   │
│  │    (TokenRequest API; audience + expiry)            │   │
│  │  • Auto-mounted when automountServiceAccountToken   │   │
│  │    is true (the default) for pods using the SA      │   │
│  │  • Pre-1.24: legacy non-expiring Secret-backed      │   │
│  │    tokens (no longer auto-created)                  │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  OIDC (OpenID Connect)                              │   │
│  │  • Used by: Human users                             │   │
│  │  • Integrates with identity providers               │   │
│  │  • Supports MFA through provider                    │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  WEBHOOK TOKEN AUTHENTICATION                       │   │
│  │  • Used by: Custom integrations                     │   │
│  │  • External service validates tokens                │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Перше небезпечне налаштування, на яке слід звернути увагу, — це --anonymous-auth=true. Анонімна автентифікація не означає, що API-сервер пропускає всі перевірки; вона означає, що неавтентифікованим запитам можна призначити анонімного користувача та групи, а потім передати їх до авторизації. Це звучить безпечніше, ніж є насправді, тому що багато кластерів накопичують дозволи на виявлення (discovery), проби справності, застарілі прив’язки чи власні ролі, які розкривають більше, ніж заплановано. У production вимикайте анонімну автентифікацію, якщо немає задокументованої вимоги сумісності й отримані дозволи ретельно переглянуто.

Зупиніться та спрогнозуйте: як ви гадаєте, що станеться, якщо запит досягне допуску раніше, ніж API-сервер встановив користувача та групу? Контролер допуску матиме менш надійний контекст для рішень щодо політики, а записи аудиту будуть менш корисними під час розслідування. Kubernetes тримає автентифікацію перед авторизацією та допуском, бо кожне пізніше рішення залежить від ідентичності, встановленої на початку шляху запиту. Коли ви оцінюєте автентифікацію API-сервера, ви насправді оцінюєте якість доказів, які використовує кожен пізніший засіб контролю.

Авторизація

Авторизація відповідає на наступне питання: чи дозволено цій ідентичності виконувати це дієслово над цим ресурсом у цій області? Поширений безпечний базовий рівень для production — це --authorization-mode=Node,RBAC, де авторизатор Node обмежує запити kubelet, а RBAC виражає привілеї людей, робочих навантажень та автоматизації. Це не робить дозволи автоматично правильними. Воно дає кластеру рушій політики, який може представляти найменші привілеї та який можна перевірити командами на кшталт k auth can-i.

┌─────────────────────────────────────────────────────────────┐
│              API SERVER AUTHORIZATION                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  AUTHORIZATION MODES (in order of evaluation)              │
│                                                             │
│  NODE                                                       │
│  • Authorizes kubelet requests                             │
│  • Limited to resources for pods on that node              │
│                                                             │
│  RBAC (Most common)                                        │
│  • Role-based access control                               │
│  • Roles, ClusterRoles, Bindings                           │
│  • Fine-grained permissions                                │
│                                                             │
│  ABAC (Legacy)                                             │
│  • Attribute-based access control                          │
│  • File-based policies                                     │
│  • Requires API server restart to change                   │
│                                                             │
│  WEBHOOK                                                    │
│  • External authorization service                          │
│  • (SubjectAccessReview to external authz service)         │
│                                                             │
│  Typical configuration: --authorization-mode=Node,RBAC     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Небезпечне налаштування авторизації — це AlwaysAllow. Воно може з’явитися у старих лабораторних роботах, поспіхом написаних скриптах початкового завантаження або аварійних нотатках з відновлення, які так і не було видалено. З AlwaysAllow автентифікація стає єдиним бар’єром, тож будь-які дійсні облікові дані можуть створювати привілейовані Pod’и, читати об’єкти Secret, патчити RBAC або змінювати вебхуки допуску. Викрадений токен сервісного акаунта з низькими привілеями стає значно ціннішим, тому що рівень авторизації більше не запитує, чи має цьому сервісному акаунту бути дозволено діяти.

RBAC також не є магічним щитом, коли прив’язки занадто широкі. Прив’язати робоче навантаження до cluster-admin через те, що одному контролеру знадобилося одне дієслово, — це наче віддати майстер-ключ від будівлі підряднику через те, що одна комірчина була замкнена. Краще операційне рішення — почати зі спостережених викликів API, створити вузьку Роль або ClusterRole, прив’язати її до точного сервісного акаунта та переглядати прив’язку, коли контролер змінюється. Перш ніж запускати чутливе робоче навантаження, спитайте себе, які перевірки k auth can-i довели б, що сервісний акаунт може виконувати свою роботу, не володіючи кластером.

Контроль допуску

Контроль допуску відповідає на тонше питання: чи слід приймати цей загалом дійсний та авторизований запит у його остаточній формі? Мутувальний допуск може додавати типові значення, sidecar’и, мітки чи інші зміни перед збереженням. Перевіряльний допуск може відхиляти об’єкти, які порушують політику безпеки, правила найменування, обмеження ресурсів чи організаційні вимоги. Цей поділ має значення, тому що авторизація вирішує, чи може той, хто звертається, попросити про дію, тоді як допуск вирішує, чи прийнятний отриманий об’єкт для кластера.

┌─────────────────────────────────────────────────────────────┐
│              ADMISSION CONTROL FLOW                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Request → Authentication → Authorization → Admission      │
│                                                             │
│  ADMISSION CONTROLLERS                                      │
│                                                             │
│  MUTATING (modify requests)                                │
│  ├── DefaultStorageClass: Adds default storage class       │
│  ├── ServiceAccount: Adds default service account          │
│  └── Custom webhooks: Add sidecars, labels                 │
│                                                             │
│  VALIDATING (accept/reject requests)                       │
│  ├── PodSecurity: Enforces Pod Security Standards          │
│  ├── ValidatingAdmissionPolicy: CEL-based validation       │
│  └── Custom webhooks: OPA/Gatekeeper (ValidatingAdmission   │
│      Webhook), other policy enforcement                    │
│                                                             │
│  SECURITY-CRITICAL ADMISSION CONTROLLERS                   │
│  ├── PodSecurity (PSA)                                     │
│  ├── NodeRestriction                                       │
│  ├── ValidatingAdmissionWebhook                            │
│  └── MutatingAdmissionWebhook                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Для безпеки площини управління рівня KCSA дві теми допуску заслуговують на особливу увагу. Плагін допуску PodSecurity увімкнено за замовчуванням з Kubernetes 1.25, і він допомагає застосовувати Pod Security Standards, щоб команди не могли необачно створювати привілейовані, з монтуванням хоста чи іншим чином ризиковані Pod’и в просторах імен, де ці профілі не дозволені. NodeRestriction не входить до типового набору плагінів допуску; його потрібно вмикати явно (наприклад, через --enable-admission-plugins), і він працює разом з авторизатором Node, обмежуючи те, що kubelet’и можуть змінювати, що допомагає не дати скомпрометованим обліковим даним вузла змінювати об’єкти поза його легітимною ідентичністю вузла. Ці засоби контролю зменшують радіус ураження, але NodeRestriction зокрема потрібно навмисно увімкнути та поєднати з RBAC, який не дає зловмисникам окремий шлях в обхід.

Вебхуки допуску додають гнучкості, а ця гнучкість створює компроміс щодо доступності. Перевіряльний вебхук, що вичерпує тайм-аут на кожному створенні Pod’а, може зупинити розгортання по всьому кластеру, тоді як мутувальний вебхук, який неправильно змінює контекст безпеки, може внести ризик у масштабі. Питання безпеки площини управління полягає не просто в тому, чи існують вебхуки. Ви оцінюєте, чи вони досяжні, чи їхня політика реагування на збій відповідає ризику, чи вони захищені TLS і чи журнали аудиту роблять їхні рішення достатньо видимими для усунення несправностей.

Прапорці безпеки API-сервера

Наведена нижче таблиця — один з найшвидших способів перетворити маніфест API-сервера на оцінювання. Не сприймайте її лише як засіб для запам’ятовування. Кожен прапорець відповідає певній поведінці безпеки площини управління, яка змінює те, що може зробити зловмисник після отримання мережевого доступу, токена чи неправильно налаштованого робочого навантаження. Коли верифікатор, аудитор чи колега запитує, чи API-сервер посилено захищено, ці налаштування дають вам конкретні докази.

Прапорець	Призначення	Безпечне налаштування	CIS Benchmark
--anonymous-auth	Дозволяти неавтентифіковані запити	false для production	CIS 1.2.1
--authorization-mode	Як авторизувати запити	Node,RBAC	CIS 1.2.7, 1.2.8
--enable-admission-plugins	Які контролери допуску	Включити PodSecurity,NodeRestriction	CIS 1.2.15, 1.2.16
--audit-log-path	Куди записувати журнали аудиту	Встановити коректний шлях	CIS 1.2.19
--tls-cert-file	TLS-сертифікат API-сервера	Має бути налаштований	CIS 1.2.26
--etcd-cafile	CA для перевірки etcd	Має бути налаштований	CIS 1.2.28

Журналювання аудиту часто розглядають як детективний засіб контролю, але воно також змінює поведінку ще до інциденту. Команди, які знають, що високоризикові дії записуються, схильні створювати чіткіші процедури екстреного доступу (break-glass) і менше неформальних адміністративних обхідних шляхів. Корисна політика аудиту записує невдачі автентифікації, зміни RBAC, доступ до Secret, зміни вебхуків допуску та створення привілейованих робочих навантажень, не топлячи операторів у кожній малозначущій події спостереження. API-сервер не може допомогти вам розслідувати те, що його ніколи не було налаштовано записувати.

Безпека etcd

etcd — це пам’ять кластера. Kubernetes зберігає там об’єкти після того, як вони пройшли шлях через API-сервер, а отже etcd містить об’єкти Deployment, Pod, ConfigMap, прив’язки RBAC, лізи, статус вузлів та ресурси Secret. Значення секретів не захищені лише тому, що вони закодовані в base64 в API Kubernetes. Base64 — це кодування для транспортування та відображення, а не шифрування, тож відкритість etcd може перетворити одну мережеву помилку на розкриття облікових даних.

┌─────────────────────────────────────────────────────────────┐
│              ETCD SECURITY                                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ETCD CONTAINS:                                            │
│  • All Kubernetes objects (pods, deployments, etc.)        │
│  • Secrets (base64 encoded by default)                     │
│  • ConfigMaps                                               │
│  • RBAC configuration                                      │
│  • Service account tokens                                  │
│                                                             │
│  IF ETCD IS COMPROMISED:                                   │
│  • All secrets exposed                                     │
│  • Cluster state can be modified                           │
│  • Complete cluster compromise                             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Перший засіб контролю etcd — це мережева ізоляція. У типовому посиленому дизайні лише екземпляри API-сервера потребують прямого клієнтського доступу до etcd, і цей доступ має використовувати TLS з автентифікацією за клієнтським сертифікатом. Pod’и не повинні досягати etcd через виявлення сервісів, маршрутизацію вузлів, мережу хоста чи дозвільне правило брандмауера. Якщо зловмисник скомпрометує Pod і зможе під’єднатися до клієнтського порту etcd, він може оминути автентифікацію, RBAC, допуск та політику аудиту API-сервера — і все це одночасно.

┌─────────────────────────────────────────────────────────────┐
│              ETCD SECURITY CONTROLS                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ACCESS CONTROL                                            │
│  ├── Only API server should access etcd                    │
│  ├── Network isolation (firewall, security groups)         │
│  ├── Client certificate authentication                     │
│  └── No direct access from pods                            │
│                                                             │
│  ENCRYPTION IN TRANSIT                                     │
│  ├── TLS for client-to-server (CIS 2.1)                    │
│  ├── TLS for peer-to-peer (CIS 2.3, 2.4)                   │
│  └── Mutual TLS (mTLS) preferred (CIS 2.2)                 │
│                                                             │
│  ENCRYPTION AT REST                                        │
│  ├── Kubernetes secrets encryption (CIS 1.2.31)            │
│  ├── Provider options: aescbc, aesgcm, kms                 │
│  ├── KMS integration for key management                    │
│  └── Envelope encryption pattern                           │
│                                                             │
│  BACKUP SECURITY                                           │
│  ├── Encrypt backups                                       │
│  ├── Secure backup storage                                 │
│  └── Test restore procedures                               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Шифрування транспорту захищає два шляхи. TLS «клієнт-сервер» захищає з’єднання між API-сервером та etcd. TLS «вузол-вузол» (peer-to-peer) захищає трафік реплікації між членами etcd. Обидва мають значення, тому що кластер може розміщувати членів etcd на окремих вузлах площини управління, а внутрішня мережа не є автоматично надійною. Спостерігач у мережі, який може читати трафік між вузлами чи видавати себе за члена etcd, здатний загрожувати узгодженості, конфіденційності та відновленню.

Шифрування під час зберігання — це окремий засіб контролю. Kubernetes може шифрувати вибрані ресурси перед записом їх до etcd за допомогою EncryptionConfiguration, і ресурси Secret зазвичай є першою ціллю. Порядок провайдерів важливий, бо перший провайдер записує нові дані, тоді як для читань може бути випробувано кожен налаштований провайдер. Саме тому під час міграції може з’явитися резервний варіант identity: він дозволяє API-серверу читати старіші незашифровані дані, доки команда не перезапише ці об’єкти під новим провайдером.

Шифрування секретів під час зберігання

За замовчуванням секрети Kubernetes лише закодовані в base64 у etcd, а не зашифровані. Наведений нижче збережений приклад конфігурації показує поширений патерн: спершу провайдер шифрування, потім identity як резервний варіант для читання. У production матеріал ключа має бути згенерований, збережений, ротований та розповсюджений через контрольований процес; приклад навмисно використовує несекретне значення-заповнювач, щоб його не можна було сприйняти за придатний для використання ключ.

# EncryptionConfiguration example
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-key>
      - identity: {}  # Fallback for reading unencrypted

Провайдер	Опис	Сценарій використання
identity	Без шифрування	Ніколи для production
aescbc	Шифрування AES-CBC	Добре для самокерованих кластерів
aesgcm	Шифрування AES-GCM	Швидше за aescbc
kms	Зовнішнє керування ключами	Найкраще для відповідності вимогам

Практична помилка — увімкнути файл і вважати роботу завершеною. Наявні об’єкти Secret залишаються у своїй попередній збереженій формі, доки їх не буде перезаписано, тож план міграції повинен включати контрольований перезапис об’єктів Secret та перевірку того, що щойно збережені дані зашифровано. У керованому Kubernetes хмарний провайдер може опікуватися etcd та надавати опції конвертного шифрування через свій API платформи, але питання оцінювання залишається тим самим: де керується ключ, які ресурси охоплено та як ви довели б, що старі дані було перешифровано?

Перш ніж запускати це в реальному кластері, який вивід переконав би вас, що шифрування працює, а не лише налаштоване? Сильна відповідь спирається більш ніж на один сигнал: маніфест API-сервера посилається на конфігурацію шифрування, щойно записаний Secret усе ще можна прочитати через API, а контрольований огляд «сирих» даних etcd не виявляє значення Secret у відкритому тексті. Важлива звичка з безпеки — перевіряти поведінку, а не лише наявність файлу.

Резервні копії заслуговують на таку саму повагу, як і жива база даних. Зашифрований член etcd з незашифрованими знімками у спільному об’єктному сховищі — це все одно шлях розкриття даних. Безпека резервного копіювання включає шифрування знімка, обмеження тих, хто може його відновити, тестування відновлення в ізольованому середовищі та документування того, які ключі потрібні під час відновлення. Команда, яка не може безпечно відновитися, може перетворити інцидент безпеки на простій, намагаючись захистити дані.

Безпека планувальника

Планувальник зазвичай не читає секрети застосунків і не термінує TLS, тож він може здаватися менш чутливим, ніж API-сервер чи etcd. Це враження неповне. Планувальник вирішує, де запускаються Pod’и, а розміщення є рішенням з безпеки щоразу, коли вузли мають різні зони довіри, апаратний доступ, мітки відповідності, межі орендарів чи мережеву досяжність. Скомпрометований планувальник може вплинути на те, які робочі навантаження співіснують і які припущення про ізоляцію перестають бути правдивими.

Зупиніться та спрогнозуйте: якщо зловмисник компрометує планувальник, він може впливати на те, де розміщуються Pod’и; як це можна використати навіть без зміни самих Pod’ів? Одна відповідь — примусове розміщення поруч (co-location). Чутливе робоче навантаження можна розмістити на вузлі, який також виконує код під контролем зловмисника, або «галасливе» робоче навантаження можна розмістити там, де воно виснажуватиме важливі сервіси. Інша відповідь — обхід ізоляції, коли команди покладаються на мітки вузлів, taint’и та affinity для відокремлення регульованих робочих навантажень від загальних.

┌─────────────────────────────────────────────────────────────┐
│              SCHEDULER SECURITY                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  SCHEDULER RESPONSIBILITIES                                │
│  • Selects nodes for unscheduled pods                     │
│  • Respects resource requests and limits                   │
│  • Honors affinity and anti-affinity rules                │
│  • Enforces taints and tolerations                         │
│                                                             │
│  SECURITY CONCERNS                                         │
│  ├── Runs with significant cluster privileges             │
│  ├── Compromise could influence pod placement              │
│  ├── Could bypass node isolation                          │
│  └── Could cause denial of service                        │
│                                                             │
│  SECURITY CONTROLS                                         │
│  ├── Client certificate authentication to API server      │
│  ├── Minimal RBAC permissions (built-in binding)          │
│  ├── Bind address to localhost (127.0.0.1) (CIS 1.4.2)    │
│  ├── Disable profiling if not needed (CIS 1.4.1)          │
│  ├── Run on dedicated control plane nodes                 │
│  └── Network isolation from workload nodes                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Планувальник має автентифікуватися до API-сервера власним клієнтським сертифікатом або kubeconfig, а його RBAC має залишатися близьким до вбудованих дозволів, необхідних для планування. Йому не потрібні широкі адміністративні прив’язки, створені вручну. Його небезпечні службові інтерфейси мають прив’язуватися до localhost, якщо немає навмисного, захищеного шляху спостережуваності. Профілювання може бути корисним під час досліджень продуктивності, але залишати кінцеві точки профілювання широко досяжними під час звичайної роботи означає розкривати внутрішню поведінку заради малої користі для безпеки.

Реалістична історія з планувальником починається з невинної мітки. Платформена команда позначає кілька вузлів для робочих навантажень PCI, а згодом надає сервісу автоматизації дозвіл позначати вузли, тому що скрипту викочування потрібна гнучкість. Якщо планувальник, мітки вузлів та RBAC не переглядаються разом, цей сервіс автоматизації може опосередковано вирішувати, де можуть запускатися регульовані робочі навантаження. Тому безпека планувальника включає сам процес планувальника та засоби контролю розміщення навколо нього, які живлять його рішення.

Безпека контролер-менеджера

Контролер-менеджер виконує цикли узгодження. Контролер помічає, що бажаний стан і фактичний стан відрізняються, а потім вживає заходів, щоб усунути розрив. Ця дія може створювати Pod’и, оновлювати endpoint’и, реагувати на справність вузлів, видавати токени сервісних акаунтів чи керувати іншими вбудованими ресурсами. Узгодження — це одна із сильних сторін Kubernetes, але скомпрометований контролер-менеджер небезпечний, тому що він може раз за разом перетворювати шкідливий бажаний стан на стійку поведінку кластера.

┌─────────────────────────────────────────────────────────────┐
│              CONTROLLER MANAGER SECURITY                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CONTROLLERS INCLUDE:                                      │
│  • Node controller (node health)                           │
│  • Replication controller (pod replicas)                   │
│  • Endpoints controller (service endpoints)                │
│  • ServiceAccount controller (creates default SA)          │
│  • Many more...                                            │
│                                                             │
│  SECURITY CONCERNS                                         │
│  ├── Access to service account signing key                │
│  ├── Can create/delete pods and services                  │
│  ├── Manages node lifecycle                               │
│  └── Compromise = cluster-wide impact                     │
│                                                             │
│  KEY SECURITY FLAGS                                        │
│  ├── --use-service-account-credentials=true (CIS 1.3.3)   │
│  │   (Use separate SA for each controller)                 │
│  ├── --root-ca-file (CIS 1.3.5)                           │
│  │   (CA for verifying API server)                         │
│  └── --service-account-private-key-file (CIS 1.3.4)       │
│      (Key for signing SA tokens)                           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Прапорець --use-service-account-credentials=true має значення, тому що він розділяє ідентичності контролерів, замість того щоб проштовхувати кожен вбудований контролер через одні широкі облікові дані. Розділення покращує чіткість аудиту й обмежує те, скільки має дозволятися одній ідентичності контролера. Прапорець --service-account-private-key-file має значення, тому що підписання токенів є коренем довіри для робочих навантажень. Якщо зловмисник здобуде ключ підпису, він може отримати змогу карбувати токени, які виглядають легітимними, доки ключ не буде ротовано, а залежну довіру — відновлено.

Посилення кінцевих точок контролер-менеджера дотримується того самого принципу, що й посилення планувальника. Прив’язуйте діагностичні кінцеві точки вузько, надавайте метрики через захищений шлях та уникайте залишати ввімкненим профілювання без причини. Компонент має автентифікуватися до API-сервера власними обліковими даними й не повинен ділити клієнтський матеріал з непов’язаними процесами. Команда, яка розслідує компрометацію площини управління, має бути спроможна визначити, яка саме ідентичність контролера внесла зміну, замість того щоб бачити повсюди одного нечіткого адміністративного діяча.

Контролер-менеджер також пов’язує безпеку площини управління з життєвим циклом вузлів. Якщо контролер може позначати вузли, змінювати endpoint’и чи впливати на поведінку сервісних акаунтів, то його компрометація може перенаправляти трафік, приховувати інфраструктуру, що відмовляє, чи змушувати робочі навантаження довіряти не тій ідентичності. Саме тому посилення контролер-менеджера — це не вузька вправа з CIS. Воно захищає автоматизацію, яка тихо тримає кластер живим.

Мережева безпека площини управління

Розташування в мережі перетворює посилення окремих компонентів на системну межу. Безпечний набір прапорців API-сервера не може захистити etcd, якщо etcd напряму досяжний з кожної мережі Pod’ів. Добре обмежені облікові дані планувальника менш корисні, якщо його кінцева точка налагодження слухає на інтерфейсі, відкритому для робочих вузлів. Мережева безпека площини управління запитує, які компоненти мають спілкуватися, які порти потрібні, які шляхи є адміністративними та які шляхи мають бути неможливими під час звичайної роботи.

┌─────────────────────────────────────────────────────────────┐
│              CONTROL PLANE NETWORK                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  RECOMMENDED ARCHITECTURE                                  │
│                                                             │
│  ┌────────────────────────────────────────────────────┐    │
│  │           PRIVATE SUBNET (Control Plane)           │    │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐  │    │
│  │  │   API   │ │  etcd   │ │ Sched   │ │  Ctrl   │  │    │
│  │  │  Server │ │         │ │         │ │   Mgr   │  │    │
│  │  └────┬────┘ └─────────┘ └─────────┘ └─────────┘  │    │
│  │       │                                            │    │
│  └───────┼────────────────────────────────────────────┘    │
│          │ (Only API server exposed)                       │
│          ▼                                                 │
│  ┌────────────────────────────────────────────────────┐    │
│  │           PRIVATE SUBNET (Worker Nodes)            │    │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐              │    │
│  │  │  Node 1 │ │  Node 2 │ │  Node 3 │              │    │
│  │  │ kubelet │ │ kubelet │ │ kubelet │              │    │
│  │  └─────────┘ └─────────┘ └─────────┘              │    │
│  └────────────────────────────────────────────────────┘    │
│                                                             │
│  SECURITY REQUIREMENTS:                                    │
│  • etcd: Only accessible from API server                   │
│  • API server: Accessible from nodes and admins           │
│  • Scheduler/CM: Only need to reach API server            │
│  • Private API endpoint preferred                         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Діаграма зберігає просте, але важливе архітектурне правило: API-сервер відкрито для тих учасників, яким потрібен API Kubernetes, тоді як etcd, планувальник та контролер-менеджер залишаються приватними сервісами площини управління. У самокерованих кластерах ви реалізуєте це за допомогою брандмауерів хоста, груп безпеки, маршрутизації, TLS та іноді окремих інтерфейсів. У керованих кластерах ви часто обираєте між публічними та приватними кінцевими точками API й покладаєтеся на провайдера щодо ізоляції etcd, але ви все одно володієте тим, як адміністративні мережі, CI-системи та робочі вузли досягають API.

Мережеві засоби контролю слід поєднувати із засобами контролю ідентичності, тому що будь-який із цих рівнів можна неправильно прочитати. Приватна кінцева точка API не усуває потреби в RBAC, журналюванні аудиту та політиці допуску; вона лише зменшує коло тих, хто може досягти вхідних дверей. TLS на etcd не усуває потреби в правилах брандмауера; він лише вимагає від клієнта довести ідентичність після того, як той досягне порту. Глибокоешелонований захист означає, що зловмисник має подолати мережеву досяжність, криптографічну довіру та політику Kubernetes, а не перемагати після однієї помилки.

Для екзаменаційного та production-мислення відокремлюйте «досяжний» від «авторизований». Pod може бути неавторизованим читати об’єкти Secret через API-сервер, але все одно здатним відкрити TCP-з’єднання до etcd, якщо це дозволяє маршрутизація. Ноутбук розробника може бути авторизований через OIDC, але не повинен напряму досягати кінцевих точок налагодження компонентів. Гарне оцінювання площини управління фіксує обидва виміри, тому що реальні інциденти часто починаються там, де команди припустили, що один рівень означає інший.

Робочий процес оцінювання площини управління

Оцінювання корисне тоді, коли воно перетворює розрізнені налаштування на пріоритетний план усунення вад. Почніть з визначення типу кластера, тому що керовані та самокеровані кластери розкривають різні поверхні управління. У самокерованих кластерах маніфести статичних Pod’ів та файли service unit можуть напряму показувати прапорці API-сервера, планувальника, контролер-менеджера та etcd. У керованих кластерах API провайдера та екрани конфігурації кластера можуть бути єдиним підтримуваним шляхом для відкритості кінцевих точок, налаштувань шифрування та інтеграції аудиту.

Перший прохід має зіставити кожен небезпечний прапорець із властивістю безпеки, яку він послаблює. Анонімна автентифікація послаблює впевненість в ідентичності. AlwaysAllow послаблює авторизацію. Відсутність PodSecurity та NodeRestriction послаблює допуск і засоби контролю радіуса ураження на рівні вузла. Відсутність журналів аудиту послаблює виявлення та розслідування. URL-адреси etcd на чистому HTTP послаблюють конфіденційність транспорту та ідентичність сервера. Це зіставлення має значення, тому що воно допомагає вам пояснити ризик операційною мовою, замість того щоб вивалювати на іншу команду список прапорців.

Другий прохід має розглянути ризик змін. Перемикання AlwaysAllow на Node,RBAC у production-кластері без розуміння наявних робочих навантажень може спричинити простої, навіть якщо поточне налаштування є небезпечним. Увімкнення шифрування під час зберігання без перезапису наявних об’єктів Secret може створити хибне відчуття завершеності. Блокування кінцевої точки API без урахування CI-мереж може зламати розгортання. Зрілий план усунення вад швидко виправляє найризикованішу відкритість, водночас послідовно проводячи зміни з великим радіусом ураження через staging, дані аудиту та плани відкату.

Який підхід ви б тут обрали і чому: негайно посилити кожен прапорець площини управління в одному вікні обслуговування чи спершу зібрати докази аудиту та поетапно впровадити зміни разом із власниками робочих навантажень? Безпечніша відповідь — зазвичай поетапне усунення вад, за винятком тих видів відкритості, які активно експлуатуються та мають вузьке виправлення, як-от порт etcd, досяжний з мереж робочих навантажень. Мета — не сповільнити зміни. Мета — зробити покращення безпеки реальним, а не замінити один інцидент іншим.

Коли ви документуєте знахідки, описуйте їх як причину, наслідок та виправлення. «Анонімна автентифікація має значення true» — це налаштування. «Неавтентифіковані запити можуть потрапити до шляху запиту API-сервера, і будь-яка випадкова анонімна прив’язка RBAC може розкрити інформацію про кластер; встановіть --anonymous-auth=false після підтвердження, що потрібні проби автентифікуються» — це дієва знахідка. Цей стиль також допомагає з конструктивним узгодженням для вашого власного навчання: ви оцінюєте засоби контролю, діагностуєте відкритість, порівнюєте ризики компонентів та впроваджуєте пріоритетне оцінювання.

Патерни та антипатерни

Патерн: API-сервер як єдині двері до стану

Використовуйте цей патерн, коли хочете, щоб кожна звичайна зміна стану кластера проходила через автентифікацію, авторизацію, допуск та аудит. API-сервер має бути єдиним клієнтським шляхом до etcd, а адміністративна автоматизація має використовувати облікові дані API Kubernetes, а не прямий доступ до бази даних. Цей патерн працює, бо він концентрує застосування політики на компоненті, спроєктованому під семантику Kubernetes, а не на «сирому» сховищі ключ-значення, яке не здатне зрозуміти RBAC чи Pod Security.

Аспект масштабування — це доступність. Якщо API-сервер є єдиними дверима до стану, API-сервер має бути високодоступним, моніторитися та бути захищеним від «галасливих» клієнтів. Обмеження частоти запитів, проєктування політики аудиту та доступність вебхуків стають частиною патерну, а не необов’язковими додатками. Здорова реалізація робить API-сервер центральним, не роблячи його крихким.

Патерн: ідентичності, специфічні для компонентів

Використовуйте цей патерн, коли планувальник, контролер-менеджер, kubelet’и, робочі навантаження та люди потребують різних дозволів і різних слідів аудиту. Контролер-менеджер має використовувати розділені облікові дані сервісних акаунтів там, де це підтримується, планувальник має використовувати власну клієнтську ідентичність, а робочі навантаження мають уникати спільного використання широких сервісних акаунтів. Патерн працює, бо облікові дані тоді описують реального діяча, що робить можливими найменші привілеї та реагування на інциденти.

Цей патерн масштабується через автоматизацію оглядів. Команди можуть періодично запитувати RBAC, перевіряти k auth can-i для важливих сервісних акаунтів та сповіщати про нові прив’язки cluster-admin. Це не усуває потреби в людському судженні, але дає рецензентам менші одиниці для осмислення. Облікові дані, які означають лише «якийсь внутрішній компонент», важко захищати й важко розслідувати.

Патерн: приватні компоненти з перевіреними винятками

Використовуйте цей патерн, коли площина управління охоплює мережі, акаунти чи адміністративні команди. Кінцеві точки etcd, планувальника та контролер-менеджера мають бути приватними за замовчуванням, тоді як API-сервер має бути відкритим лише для тих мереж та ідентичностей, яким він потрібен. Винятки мають називати джерело, призначення, порт, протокол, бізнес-причину та дату закінчення чи перегляду. Це працює, бо сервіси площини управління рідко потребують широкої досяжності, а широка досяжність створює мовчазні шляхи атаки.

У масштабі складна частина — це дрейф. Правило брандмауера, додане під час інциденту, може пережити сам інцидент, а тимчасова публічна кінцева точка API може стати нормою, бо вона спрощує доступ розробникам. Розглядайте мережеві винятки як конфігурацію, що потребує власника, перегляду та доказів. Стан безпеки — це не діаграма з дати запуску; це фактична досяжність сьогодні.

Антипатерн: прапорці початкового завантаження, залишені в production

Команди потрапляють у цей антипатерн, коли використовують дозвільні налаштування, щоб підняти кластер, і ніколи їх не прибирають. --authorization-mode=AlwaysAllow, анонімна автентифікація та мінімальні плагіни допуску можуть полегшити раннє усунення несправностей, але це не нейтральні налаштування. Вони привчають кластер занадто багато довіряти й залишають кожне пізніше робоче навантаження за одну крадіжку облікових даних від ширшої компрометації.

Краща альтернатива — створити чекліст початкового завантаження з явним виходом через посилення захисту. Кластер не готовий до production, доки API-сервер не використовує Node,RBAC, анонімна автентифікація не вимкнена (якщо не виправдана), журналювання аудиту не пише в реальний шлях, а орієнтовані на безпеку контролери допуску не присутні. Якщо аварійна ситуація вимагає тимчасового послаблення, дайте йому власника та час видалення.

Антипатерн: ставлення до шифрування etcd як до галочки

Цей антипатерн з’являється, коли команда налаштовує провайдера шифрування, але не ротує дані, не захищає ключі й не захищає резервні копії. Це трапляється, бо шифрування під час зберігання звучить бінарно, тоді як поведінка шифрування Kubernetes залежить від порядку провайдерів, вибору ресурсів, перезаписів та керування ключами. Отриманий кластер може пройти поверхневий огляд, доки старіші об’єкти Secret та знімки залишаються відкритими.

Краща альтернатива — життєвий цикл шифрування. Вирішіть, які ресурси охоплено, оберіть провайдера, що відповідає потребам відповідності, зберігайте ключі поза доступом звичайного адміністратора, перезапишіть наявні об’єкти, перевірте «сире» сховище та протестуйте відновлення з потрібними ключами. Для керованих кластерів зафіксуйте опцію провайдера та докази, які розкриває платформа, замість того щоб припускати, що провайдер автоматично опікується кожною деталлю.

Антипатерн: публічні кінцеві точки налагодження

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

Краща альтернатива — захищений шлях спостережуваності. Прив’язуйте чутливі кінцеві точки компонентів локально чи приватно, збирайте метрики через автентифіковані та авторизовані механізми та вимикайте профілювання, якщо поточне дослідження його не потребує. Якщо кінцева точка має бути досяжною поза підмережею площини управління, задокументуйте чому та розмістіть її за мережевими засобами контролю й засобами контролю ідентичності, що відповідають її чутливості.

Фреймворк прийняття рішень

Під час огляду безпеки площини управління використовуйте трирівневий фреймворк прийняття рішень: шлях запиту, сховище стану та операції компонентів. Шлях запиту охоплює автентифікацію, авторизацію, допуск, TLS та аудит API-сервера. Сховище стану охоплює досяжність etcd, шифрування транспорту, шифрування під час зберігання, керування ключами та резервні копії. Операції компонентів охоплюють ідентичності планувальника та контролер-менеджера, адреси прив’язки, профілювання, метрики та мережеву ізоляцію. Утримання цих рівнів окремо запобігає поширеній помилці огляду, коли один сильний засіб контролю приховує слабкий сусідній.

Почніть зі здатності до експлуатації. Якщо etcd досяжний з мереж робочих навантажень або API-сервер використовує AlwaysAllow, надавайте пріоритет цим знахідкам, тому що вони можуть швидко перетворити одні скомпрометовані облікові дані чи Pod на широкий контроль. Далі перегляньте засоби контролю доказів, як-от журналювання аудиту, тому що відсутні журнали роблять кожен пізніший інцидент важче обмежити. Потім займіться роботою з уточнення, як-от стискання надмірно широкого RBAC, покращення політик реагування вебхуків на збій та зменшення відкритості діагностичних кінцевих точок. Цей порядок надає перевагу швидкому скороченню загальнокластерних шляхів компрометації, не нехтуючи довгостроковою гігієною.

Використовуйте радіус ураження для вибору між негайними та поетапними змінами. Вимкнення анонімної автентифікації зазвичай має низький ризик, якщо немає легітимного анонімного доступу, але зміна режимів авторизації може зламати робочі навантаження, які мовчки залежали від дозвільного доступу. Увімкнення шифрування під час зберігання є цінним, проте воно потребує перезапису даних та плану ключів. Обмеження мереж кінцевої точки API покращує відкритість, але воно має включати CI, адміністраторів та екстрений доступ (break-glass). Краще рішення — те, що зменшує реальний ризик і переживає наступний день розгортання.

Порівнюючи ризик планувальника та контролер-менеджера, запитуйте, на що компонент може впливати, а не чи зберігає він секрети напряму. Планувальник впливає на розміщення, що зачіпає ізоляцію, доступність та ризик сумісного розташування. Контролер-менеджер впливає на узгодження, поведінку сервісних акаунтів, endpoint’и та життєвий цикл вузлів. Обидва мають використовувати вузькі ідентичності та приватні кінцеві точки, але історії впливу різняться. Гарне оцінювання пояснює ці відмінності, щоб власники усунення вад розуміли, чому знахідка має значення.

Нарешті, вимагайте доказів. Рядок маніфесту, хмарне налаштування чи знімок екрана корисні, але найсильніший доказ пов’язує конфігурацію зі спостереженою поведінкою. Чи може неавтентифікований запит зробити щось корисне? Чи може цільовий сервісний акаунт створити привілейований Pod? Чи може мережа Pod’а досягти etcd? Чи можна прочитати новий Secret через API, але не побачити у відкритому тексті в «сирому» сховищі? Фреймворк прийняття рішень завершується перевіркою, тому що безпека площини управління настільки сильна, наскільки сильна поведінка кластера, що працює сьогодні.

Запишіть остаточне рішення мовою, за якою інший інженер може діяти під час вікна змін. Гарні знахідки називають небезпечну умову, зачеплений компонент, очікуваний посилений стан, доказ перевірки та операційний ризик його зміни. Такий рівень конкретики перетворює безпеку площини управління з думки на повторювану інженерну практику.

Чи знали ви?

• API-сервер — єдиний звичайний компонент Kubernetes, який пише напряму до etcd. Саме цей дизайн робить прямий доступ до etcd таким небезпечним: він оминає семантику автентифікації, авторизації, допуску та аудиту Kubernetes.

• Об’єкти Secret у Kubernetes за замовчуванням закодовані в base64, а не зашифровані. Шифрування під час зберігання вимагає явної конфігурації API-сервера або функції керованого провайдера Kubernetes, а старіші об’єкти потрібно перезаписати, щоб змінити їхню збережену форму.

• Авторизація Node та NodeRestriction розв’язують різні половини проблеми вузла. Авторизатор обмежує те, що можуть запитувати облікові дані kubelet, тоді як контролер допуску обмежує, які поля вузла та Pod’а kubelet’и можуть змінювати.

• Керований Kubernetes зменшує володіння площиною управління, а не відповідальність за неї. Ви можете не патчити прапорці etcd напряму, але ви все одно обираєте відкритість кінцевої точки API, інтеграцію аудиту, опції шифрування, доступ адміністраторів та дозволи робочих навантажень.

Типові помилки

Помилка	Чому це трапляється	Як це виправити
Увімкнена анонімна автентифікація	Типові налаштування початкового завантаження чи перевірки справності копіюються в production без огляду впливу анонімного RBAC	Встановіть --anonymous-auth=false після підтвердження, що проби та клієнти автентифікуються коректно
Відсутнє шифрування etcd	Команди вважають кодування Secret у base64 шифруванням або покладаються на типові налаштування провайдера без доказів	Увімкніть шифрування під час зберігання для Secret, перезапишіть наявні об’єкти та перевірте поведінку збережених даних
etcd відкритий для мережі	Плоскі мережі чи широкі групи безпеки дають Pod’ам та робочим вузлам досягати портів бази даних площини управління	Обмежте доступ до etcd екземплярами API-сервера та вимагайте автентифікацію за клієнтським TLS-сертифікатом
Публічна кінцева точка API-сервера	Віддаленому адмініструванню надають перевагу раніше, ніж проєктують мережеву відкритість та засоби контролю ідентичності	Надавайте перевагу приватній кінцевій точці або обмежте публічний доступ затвердженими мережами з сильною автентифікацією
Відсутнє журналювання аудиту	Журналювання відкладають, щоб зменшити шум, вартість сховища чи час налаштування під час початкового завантаження кластера	Налаштуйте політику аудиту та --audit-log-path, потім налаштуйте цінні події замість вимкнення журналів
Авторизація AlwaysAllow	Лабораторні, аварійне відновлення чи ранні налаштування початкового завантаження доживають до реальних середовищ	Перейдіть на --authorization-mode=Node,RBAC через поетапне тестування та огляд дозволів робочих навантажень
Кінцеві точки контролерів відкриті широко	Зручність метрик чи профілювання залишає інтерфейси планувальника та контролер-менеджера досяжними	Прив’язуйте чутливі кінцеві точки до localhost чи приватних мереж та спрямовуйте спостережуваність через захищені шляхи

Тест

Ваше оцінювання API-сервера виявляє увімкнену анонімну автентифікацію, вимкнене журналювання аудиту та наявну авторизацію `Node,RBAC`. Який ризик ви поясните першим і які докази зібрали б перед зміною прапорців?

Першою слід пояснити анонімну автентифікацію, тому що вона дозволяє неавтентифікованим запитам потрапляти до шляху запиту як анонімна ідентичність. `Node,RBAC` усе ще обмежує те, що ця ідентичність може зробити, тож докази мають включати наявні анонімні дозволи RBAC, доступ до виявлення (discovery), вимоги перевірок справності та будь-яких клієнтів, які можуть покладатися на неавтентифіковану поведінку. Журналювання аудиту слід виправити в межах того самого плану усунення вад, тому що воно надає докази для майбутніх розслідувань. Найбезпечніша зміна вимикає анонімну автентифікацію після валідації легітимних проб, а потім вмикає сфокусовану політику аудиту, замість того щоб створювати «галасливі» журнали малої цінності.

Колега каже, що etcd у безпеці, бо лише адміністратори знають його кінцеву точку. Під час тестування Pod може відкрити TCP-з'єднання до etcd. Як ви діагностуєте цю відкритість та поясните наслідки?

Діагноз — це збій мережевої ізоляції, а не лише проблема документації. Якщо Pod може досягти etcd, скомпрометоване робоче навантаження може спробувати оминути засоби контролю API-сервера, які зазвичай застосовують автентифікацію, RBAC, допуск та аудит. Наслідки серйозні, тому що etcd зберігає стан кластера, політику RBAC та ресурси Secret, які можуть бути незашифрованими в «сирому» сховищі. Виправлення має обмежити клієнтський доступ до etcd екземплярами API-сервера, вимагати клієнтські TLS-сертифікати та перевірити, що мережі робочих навантажень не можуть досягти шляху до бази даних.

Ваша команда вмикає провайдер шифрування `aescbc` з `identity` як резервним варіантом, а потім оголошує всі наявні об'єкти Secret зашифрованими. Що не так із цим висновком?

Висновок плутає налаштовані майбутні записи зі збереженою формою наявних об'єктів. Порядок провайдерів означає, що нові записи Secret використовують перший провайдер, тоді як резервний варіант identity може все ще читати старіші незашифровані об'єкти Secret. Наявні об'єкти Secret потрібно перезаписати через API-сервер, перш ніж зміниться їхня збережена форма. Повна відповідь включає керування ключами, захист резервних копій та перевірку того, що «сирі» дані etcd не виявляють щойно записане тестове значення у відкритому тексті.

Кластер використовує приватну кінцеву точку API, але API-сервер працює з `--authorization-mode=AlwaysAllow`. Як ви порівняєте ці засоби контролю?

Приватна кінцева точка — це корисний засіб контролю досяжності, бо менше мереж можуть під'єднатися до API-сервера. Вона не замінює авторизацію, тому що будь-якій ідентичності, яка таки досягає API-сервера, дозволено виконувати кожну дію за `AlwaysAllow`. Порівняння має відокремлювати мережевий доступ від перевірок дозволів Kubernetes. Усунення вад зберігає обмеження кінцевої точки, водночас переводячи авторизацію на `Node,RBAC` через тестування, яке виявляє робочі навантаження, що залежать від неявного широкого доступу.

Кінцева точка планувальника досяжна з робочих вузлів, і профілювання ввімкнено. Ніхто не продемонстрував зміну Pod'а. Чому це все одно є знахідкою з безпеки площини управління?

Планувальник впливає на розміщення Pod'ів, а розміщення зачіпає ізоляцію, доступність та ризик сумісного розташування навіть тоді, коли специфікації Pod'ів не змінюються напряму. Широко досяжна кінцева точка профілювання чи діагностики також дає зловмисникам цінність для розвідки та може розкривати внутрішні дані, які мають залишатися приватними. Знахідка стосується зайвої досяжності площини управління та розкриття інформації. Виправлення — прив'язати чутливі кінцеві точки до localhost або приватної мережі площини управління та надавати метрики через автентифікований шлях спостережуваності.

Контролер-менеджер використовує одні широкі облікові дані для вбудованих контролерів. Під час реагування на інцидент записи аудиту показують зміни від однієї й тієї ж ідентичності всюди. Яке покращення дизайну ви б порекомендували?

Порекомендуйте використовувати окремі облікові дані сервісних акаунтів для контролерів там, де це підтримується, зокрема `--use-service-account-credentials=true`. Окремі ідентичності покращують найменші привілеї, бо кожен контролер може отримати дозволи, ближчі до його роботи. Вони також покращують якість аудиту, бо слідчі можуть розрізнити, який цикл управління вніс зміну. Рекомендація має включати захист ключів підпису сервісних акаунтів та одночасний огляд відкритості кінцевих точок контролер-менеджера.

Вас просять впровадити оцінювання площини управління для production-кластера за один день. Як ви розставите пріоритети в роботі, не перетворюючи її на ризиковану масову зміну?

Почніть зі збору доказів для рівнів шляху запиту, сховища стану та операцій компонентів. Надавайте пріоритет активно експлуатованим загальнокластерним шляхам першими, як-от `AlwaysAllow`, досяжний etcd, відсутній TLS etcd чи відсутні журнали аудиту. Поетапно проводьте зміни, які можуть зламати робочі навантаження, особливо зміни режиму авторизації та обмеження кінцевої точки API, з тестуванням та нотатками щодо відкату. Результат має зіставити кожен небезпечний прапорець чи відкритість із наслідком, виправленням, власником та доказом перевірки, а не лише перелічувати налаштування.

Практична вправа: оцінювання безпеки площини управління

Ця вправа використовує статичний фрагмент API-сервера, щоб ви могли практикувати міркування з оцінювання, не потребуючи адміністративного доступу до реальної площини управління. У живому самокерованому кластері схожі прапорці можуть з’явитися в маніфесті статичного Pod’а в каталозі маніфестів хоста площини управління, тоді як керовані кластери розкривають еквівалентні варіанти через налаштування провайдера. Ваше завдання — читати фрагмент як слідчий: визначити послаблений засіб контролю, пояснити ймовірний наслідок, обрати посилене налаштування та вирішити, чи зміна є негайною або поетапною. Розглядайте кожну знахідку як доказ для рішення, тому що усунення вад у production вдається тоді, коли команда розуміє і технічну слабкість, і операційний наслідок.

Сценарій: перегляньте ці прапорці API-сервера та визначте проблеми безпеки в автентифікації, авторизації, допуску, журналюванні аудиту та транспортній безпеці etcd, перш ніж пропонувати зміни:

kube-apiserver \
  --anonymous-auth=true \
  --authorization-mode=AlwaysAllow \
  --enable-admission-plugins=NamespaceLifecycle,ServiceAccount \
  --audit-log-path="" \
  --etcd-servers=http://etcd:2379

Почніть з відокремлення шляху запиту від шляху сховища стану. Анонімна автентифікація та AlwaysAllow впливають на те, як запити заходять та проходять через API-сервер. Відсутні плагіни допуску впливають на те, чи можна відхилити ризиковані об’єкти після авторизації. Порожній шлях журналу аудиту впливає на виявлення та розслідування. URL etcd на чистому HTTP впливає на довіру та конфіденційність з’єднання з базою даних стану. Цей поділ робить вашу відповідь точною, бо кожен прапорець послаблює іншу властивість безпеки.

• Завдання 1: Оцініть засоби контролю автентифікації, авторизації, допуску та аудиту API-сервера у фрагменті, потім назвіть небезпечний прапорець для кожного засобу контролю.
• Завдання 2: Діагностуйте відкритість транспорту etcd та поясніть, чому прямий чи незашифрований доступ до сховища стану змінює шлях компрометації.
• Завдання 3: Порівняйте засоби контролю планувальника та контролер-менеджера з цього модуля із засобами контролю API-сервера, показаними у фрагменті, зосереджуючись на ризику ідентичності та адреси прив’язки.
• Завдання 4: Впровадьте пріоритетний план усунення вад, який перелічує негайні виправлення, поетапні виправлення, команди чи перевірки для валідації та міркування щодо відкату.
• Завдання 5: Напишіть коротку нотатку-доказ, яку аудитор зміг би зрозуміти, не бачачи оригінального фрагмента.

Підказки до рішення для Завдань 1 і 2

Фрагмент API-сервера має щонайменше п'ять важливих знахідок. `--anonymous-auth=true` дозволяє неавтентифікованим запитам потрапляти до шляху запиту й зазвичай має бути встановлений у `false` у production. `--authorization-mode=AlwaysAllow` усуває змістовну авторизацію й має бути замінений на `Node,RBAC` після тестування дозволів. Список плагінів допуску пропускає орієнтовані на безпеку засоби контролю на кшталт `PodSecurity` та `NodeRestriction`, тож ризиковані Pod'и та поведінка облікових даних вузла можуть бути необмеженими. `--audit-log-path=""` вимикає корисне журналювання аудиту, а `--etcd-servers=http://etcd:2379` показує незашифрований клієнтський URL etcd, який має перейти на HTTPS з перевіркою сертифіката.

Підказки до рішення для Завдань 3 і 4

Засоби контролю планувальника та контролер-менеджера дотримуються тих самих тем, але захищають різну поведінку. Планувальник потребує вузької ідентичності, приватної адреси прив'язки та обмеженої відкритості профілювання, бо він впливає на розміщення. Контролер-менеджер потребує розділених облікових даних сервісних акаунтів там, де це підтримується, захищених ключів підпису, приватних кінцевих точок та чіткої ідентичності в аудиті, бо він виконує узгодження. Для усунення вад швидко виправляйте очевидно небезпечні та низькоризикові налаштування, як-от порожні шляхи аудиту та відкриті діагностичні кінцеві точки, водночас поетапно проводячи зміни режиму авторизації та міграції шифрування через тестування, огляд власника та плани відкату.

Підказки до рішення для Завдання 5

Стисла нотатка-доказ могла б звучати так: «Оцінена конфігурація API-сервера послаблює ідентичність, авторизацію, допуск, аудитованість та транспортну безпеку etcd. Анонімні запити приймаються, кожен автентифікований запит авторизується, орієнтовані на безпеку контролери допуску відсутні, журналювання аудиту не має призначення, а з'єднання з etcd використовує чистий HTTP. Рекомендоване усунення вад — `--anonymous-auth=false`, `--authorization-mode=Node,RBAC`, засоби контролю допуску, зокрема `PodSecurity` та `NodeRestriction`, реальний шлях журналу аудиту з політикою та кінцеві точки etcd на HTTPS з перевіркою CA та клієнтського сертифіката». Ця нотатка пояснює причину, наслідок та виправлення, не вимагаючи від читача виводити ризик із «сирих» прапорців.

Використовуйте наведені нижче критерії успіху, щоб перевірити, чи ваше оцінювання пов’язує кожну знахідку з доказом, ризиком та практичним кроком усунення вад:

• Ви можете зіставити кожен небезпечний прапорець API-сервера з ризиком автентифікації, авторизації, допуску, аудиту чи транспорту etcd.
• Ви можете пояснити, чому відкритість etcd оминає засоби контролю API-сервера, а не просто дублює їх.
• Ви можете розрізнити ризик розміщення планувальника від ризику узгодження та ключа підпису контролер-менеджера.
• Ви можете запропонувати порядок усунення вад, який скорочує загальнокластерні шляхи компрометації, не нехтуючи ризиком простою.
• Ви можете назвати щонайменше одну перевірку валідації для кожного важливого засобу контролю, замість того щоб покладатися лише на намір конфігурації.

Підсумок

Безпека площини управління — це про захист мозку Kubernetes, але ця фраза корисна лише тоді, коли вона вказує на конкретні обов’язки компонентів та вибори засобів контролю:

Компонент	Ключові засоби контролю безпеки
API-сервер	TLS, автентифікація (сертифікати, OIDC), авторизація RBAC, контроль допуску
etcd	Мережева ізоляція, TLS, шифрування під час зберігання, шифрування резервних копій
Планувальник	Автентифікація за сертифікатом, мережева ізоляція, мінімальні привілеї
Контролер-менеджер	Автентифікація за сертифікатом, окремі сервісні акаунти для кожного контролера

Найважливіший урок полягає в тому, що безпека площини управління є багаторівневою. API-сервер має бути навмисними вхідними дверима, etcd має бути приватним та зашифрованим, кінцеві точки планувальника та контролер-менеджера мають бути вузькими, а кожен компонент має використовувати ідентичність, що відповідає його роботі. Якщо кластер дає анонімним користувачам, викраденим токенам робочих навантажень чи скомпрометованим Pod’ам шлях в обхід цих рівнів, загальнокластерний радіус ураження швидко розширюється.

На практиці сильні огляди площини управління звучать як інженерні рішення, а не гасла. Ви оцінюєте шлях запиту API-сервера, діагностуєте відкритість etcd та прогалини в шифруванні, порівнюєте привілеї планувальника та контролер-менеджера й впроваджуєте план усунення вад з доказами. Саме цю навичку очікує іспит KCSA, і саме цю звичку потребують команди в production, коли Kubernetes стає достатньо важливим, щоб його захищати.

Джерела

• Kubernetes Components
• Kubernetes Authentication
• Kubernetes Authorization
• Kubernetes Admission Controllers
• Kubernetes RBAC
• Kubernetes Node Authorization
• Encrypting Confidential Data at Rest
• Operating etcd clusters for Kubernetes
• etcd Transport Security Model
• kube-apiserver Reference
• kube-controller-manager Reference
• kube-scheduler Reference

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

Модуль 2.2: Безпека вузлів продовжує ту саму тему багаторівневої безпеки, переходячи від компонентів площини управління до робочих вузлів, kubelet’ів та середовищ виконання контейнерів.