Модуль 0.2: Безпековий спосіб мислення

Це базовий модуль рівня [QUICK] для напрямку Kubernetes and Cloud Native Security Associate. Заплануйте 20–25 хвилин і спершу пройдіть Модуль 0.1: Огляд KCSA, щоб домени іспиту й мета сертифікації вже були вам знайомі, перш ніж ви почнете зважувати компроміси безпеки.

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

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

1. Оцінювати конфігурації Kubernetes, мислячи як зловмисник: «що може піти не так?»
2. Розрізняти мислення безпеки, кероване відповідністю (compliance), і мислення, кероване загрозами.
3. Пояснювати ешелоновану оборону (defense in depth) і те, як вона застосовується до багаторівневих засобів контролю безпеки Kubernetes.
4. Оцінювати компроміси безпеки між зручністю використання, продуктивністю та зниженням ризику.

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

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

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

KCSA побудований саме навколо такого міркування. Іспит запитує не лише про те, чи можете ви назвати RBAC, Pod Security Standards, NetworkPolicy чи шифрування; він запитує, чи можете ви розпізнати, коли ці засоби контролю зменшують реальний шлях атаки. Безпековий спосіб мислення допомагає вам поєднати розрізнені факти в одне практичне запитання: якщо щось зламається, що все одно завадить шкоді?

Цей модуль формує цю звичку ще до того, як ви почнете вивчати конкретні інструменти. Ви навчитеся порівнювати мислення зловмисника й захисника, застосовувати ешелоновану оборону, міркувати про найменші привілеї та нульову довіру (zero trust), зіставляти проблеми з моделлю 4 C та обирати засоби контролю безпеки з достатнім контекстом, щоб уникнути і недбалого недостатнього захисту, і дорогої театральної видимості.

Від мислення за чеклістом до перегляду, керованого загрозами

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

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

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

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

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

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

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

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

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

Сприймайте кожен сценарій як короткий звіт про інцидент, який ще тільки має статися. Запитання зазвичай надає робоче навантаження, дозвіл, відкритість або обмеження. Ваше завдання — подумки прокрутити такі кроки: виявлення, доступ, ескалація, переміщення, закріплення та вплив. Якщо відповідь чітко розриває один із цих кроків, вона зазвичай сильніша за відповідь, яка просто звучить просунуто.

Такий спосіб мислення також захищає вас від безпекового абсолютизму. Легко сказати «завжди шифруй усе», «ніколи не дозволяй винятки» або «забороняй увесь трафік всюди». Ці інстинкти вказують у безпечнішому напрямку, але реальним системам усе ж потрібні доступність, діагностика, швидкість викочування та людські робочі процеси. Інженер із безпековим мисленням не відмовляється від сильних типових налаштувань; він пояснює, який ризик виправдовує засіб контролю і якою операційною ціною доведеться керувати.

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

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

Операційно перегляд, керований загрозами, часто починається з п’яти простих запитань. Що є активом? Хто або що може його досягти? Яка ідентичність використовується в цій точці? Що ця ідентичність може зробити далі? Які докази показали б зловживання? Ці запитання достатньо прості, щоб використовувати їх під час перегляду дизайну, pull request, інциденту чи іспитового сценарію, і вони природно зіставляються із засобами контролю Kubernetes.

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

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

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

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

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

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

Безпековий спосіб мислення

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

Ця друга колія — не параною; це інженерна емпатія до збою. Розподілені системи ламаються частковими й несподіваними способами, а інциденти безпеки часто є просто звичайними режимами збою, до яких супротивник прикладає тиск. Хибно позначений простір імен, надмірно широкий RoleBinding чи забута діагностична кінцева точка стають небезпечними, бо зловмисники терпляче поєднують дрібні слабкості, які захисники відкинули як непов’язані.

┌─────────────────────────────────────────────────────────────┐
│              ATTACKER vs DEFENDER MINDSET                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ATTACKER                     │   DEFENDER                  │
│  ─────────────────────────────┼────────────────────────────│
│  "Where's the weakness?"      │  "Where are my weaknesses?"│
│  "What's exposed?"            │  "What have I exposed?"    │
│  "Can I escalate privileges?" │  "How can I limit access?" │
│  "What's the path in?"        │  "What paths exist?"       │
│  "Can I persist?"             │  "How do I detect changes?"│
│                                                             │
│  Both ask the SAME questions from different angles         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

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

┌─────────────────────────────────────────────────────────────┐
│              TYPICAL ATTACK CHAIN                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. RECONNAISSANCE                                          │
│     └── What's running? What versions? What's exposed?      │
│                                                             │
│  2. INITIAL ACCESS                                          │
│     └── Exploit vulnerability, phishing, stolen creds       │
│                                                             │
│  3. PRIVILEGE ESCALATION                                    │
│     └── Low privilege → high privilege access               │
│                                                             │
│  4. LATERAL MOVEMENT                                        │
│     └── Move from compromised system to others              │
│                                                             │
│  5. PERSISTENCE                                             │
│     └── Maintain access even after detection                │
│                                                             │
│  6. IMPACT                                                  │
│     └── Data theft, ransomware, disruption                  │
│                                                             │
│  DEFENSE: Break the chain at ANY step to stop the attack   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

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

Основні принципи безпеки

Перший принцип — ешелонована оборона (defense in depth), яка означає, що ви припускаєте: окремі засоби контролю іноді відмовлятимуть. Це не пораженство; це те саме міркування, що ставить паски безпеки, подушки, гальма, дорожню розмітку та обмеження швидкості в одну транспортну систему. Кожен засіб контролю адресує інший режим збою, і система безпечніша, бо жоден окремий засіб контролю не мусить бути ідеальним.

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

┌─────────────────────────────────────────────────────────────┐
│              DEFENSE IN DEPTH                               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Network firewall     ████████████████████████████████████ │
│     │                                                       │
│     └── Kubernetes Network Policy  ███████████████████████ │
│            │                                                │
│            └── Pod Security Standards  ███████████████████ │
│                   │                                         │
│                   └── Container security context  ████████ │
│                          │                                  │
│                          └── Application security  ██████  │
│                                 │                           │
│                                 └── Protected resource ▓   │
│                                                             │
│  If one layer fails, others still protect the resource     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Поширена помилка початківця — ставитися до сильного зовнішнього рівня як до дозволу ігнорувати внутрішні рівні. Хмарний фаєрвол може зменшити відкритість до інтернету, але він не захищає базу даних від скомпрометованого пода, який уже всередині мережі кластера. Pod Security Standards можуть блокувати привілейовані контейнери, але вони не вирішують, який сервісний акаунт може читати секрети. Автентифікація застосунку може захищати користувацькі маршрути, але вона не робить root-контейнер безпечним.

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

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

BAD:  Give admin access "just in case they need it"
GOOD: Give read access to specific namespaces they work with

BAD:  Run containers as root for convenience
GOOD: Run as non-root user with specific capabilities

BAD:  Allow all network traffic by default
GOOD: Deny all, then allow only required connections

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

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

Третій принцип — нульова довіра (zero trust), який відкидає старе припущення, що трафік заслуговує довіри лише тому, що походить із приватної мережі. Kubernetes робить це особливо важливим, бо кластери щільні: багато робочих навантажень, ідентичностей, секретів, контролерів і потоків даних поділяють одну площину управління й спільні вузли. Одне скомпрометоване робоче навантаження може стати відправною точкою для внутрішнього зондування, якщо кластер занадто довіряє розташуванню.

Traditional: "Inside the firewall = trusted"
Zero Trust:  "Verify every request, regardless of source"

Zero Trust principles:
• Verify explicitly (authenticate and authorize every request)
• Use least privilege (minimize access scope and duration)
• Assume breach (design as if attackers are already inside)

Нульова довіра не означає, що кожен запит мусить стати нестерпно повільним або що кожна команда мусить запускати найскладніший service mesh у перший же день. Вона означає, що ідентичності, рішення авторизації, мережеві шляхи та чутливі операції мають бути явними. У Kubernetes 1.35 і новіших цей спосіб мислення проявляється в дизайні RBAC, контролі допуску, обробці сервісних акаунтів, межах простору імен, мережевих політиках, аудиторському логуванні та контекстах безпеки робочих навантажень.

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

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

Стратегія для запитань з безпеки

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

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

┌─────────────────────────────────────────────────────────────┐
│              SCORING SECURITY OPTIONS                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  MOST SECURE (Usually correct)                             │
│  • Deny by default, allow specifically                     │
│  • Requires authentication AND authorization               │
│  • Uses encryption at rest AND in transit                  │
│  • Implements multiple layers                              │
│                                                             │
│  LESS SECURE (Sometimes correct for specific scenarios)    │
│  • Allow by default with some restrictions                 │
│  • Single authentication factor                            │
│  • Encryption only in transit                              │
│  • Single control                                          │
│                                                             │
│  INSECURE (Rarely correct)                                 │
│  • Allow all                                               │
│  • No authentication                                       │
│  • No encryption                                           │
│  • Trust by default                                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

Те саме міркування застосовується поза мережевою політикою. Якщо користувачу потрібно переглядати логи, cluster-admin надмірний; Роль, обмежена простором імен, із дієсловами читання для подів і pods/log ближча до завдання. Якщо застосунку потрібен секрет при старті, монтування лише цього секрету вужче, ніж надання доступу list до кожного секрету. Якщо контейнеру потрібен лише вихідний HTTPS до одного сервісу, відкритий egress у світ — це не найменші привілеї.

Перш ніж запускати чи читати приклади, що містять команди Kubernetes, пам’ятайте про проєктну угоду, яку використовують усюди в KubeDojo: k — це локальний аліас для kubectl, зазвичай створений через alias k=kubectl у профілі вашої оболонки. У цьому модулі команди на кшталт k get pods -A — це приклади короткого аліаса, і міркування про безпеку важливіше, ніж зручність набору.

Розібраний приклад: перегляд знаходить под із hostNetwork: true, runAsUser: 0, без NetworkPolicy та із сервісним акаунтом, який може перелічувати секрети у своєму просторі імен. Мислення зловмисника запитує, яке налаштування створює найширший наступний крок після компрометації. Хостова мережа послаблює мережеву ізоляцію, root збільшує вплив на рівні процесу, відсутня політика дозволяє легше бічне переміщення, а RBAC із переліком секретів перетворює сервісний акаунт на цінну здобич. Хороша відповідь не має обирати одне налаштування лише за словником; вона має пояснити шлях від початкового доступу до впливу.

Перш ніж обрати відповідь: запитайте, який засіб контролю розриває наступний хід зловмисника, а не який засіб контролю звучить найбільш «безпеково». Якщо зловмисник уже має виконання коду в поді, політика, що обмежує дозволи API, може мати більше значення, ніж засіб контролю, який лише захищав публічну кінцеву точку до компрометації.

Фреймворк 4 C

Модель 4 C організовує хмарну безпеку навколо чотирьох рівнів: Cloud (хмара), Cluster (кластер), Container (контейнер) та Code (код). Вона корисна, бо проблеми безпеки Kubernetes часто перетинають межі, а початківці можуть втратити з поля зору, до якого рівня належить засіб контролю. Помилка в хмарній ідентичності може відкрити вузли, помилка в RBAC кластера може відкрити секрети, помилка в середовищі виконання контейнера може відкрити хост, а помилка в коді може створити початковий експлойт.

Модель вкладена, бо кожен рівень залежить від рівнів, що зовні нього. Безпечний код застосунку не може повністю компенсувати хмарний акаунт, який дозволяє публічний доступ до приватних компонентів площини управління. Сильний RBAC кластера не може повністю компенсувати образ контейнера, що запускає вразливий вебфреймворк із публічним експлойтом. Рівні підтримують один одного, і слабкість будь-де може стати містком зловмисника до наступного рівня.

┌─────────────────────────────────────────────────────────────┐
│                    THE 4 Cs MODEL                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                     CLOUD                            │   │
│  │  Infrastructure: VMs, networks, IAM, storage        │   │
│  │  ┌─────────────────────────────────────────────┐   │   │
│  │  │                  CLUSTER                     │   │   │
│  │  │  Kubernetes: API server, etcd, RBAC, PSS    │   │   │
│  │  │  ┌─────────────────────────────────────┐   │   │   │
│  │  │  │             CONTAINER               │   │   │   │
│  │  │  │  Runtime: images, isolation, caps   │   │   │   │
│  │  │  │  ┌─────────────────────────────┐   │   │   │   │
│  │  │  │  │           CODE             │   │   │   │   │
│  │  │  │  │  Application: auth, deps   │   │   │   │   │
│  │  │  │  └─────────────────────────────┘   │   │   │   │
│  │  │  └─────────────────────────────────────┘   │   │   │
│  │  └─────────────────────────────────────────────┘   │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Each layer must be secured. A weakness anywhere           │
│  can compromise the whole system.                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Коли ви бачите сценарій KCSA, спершу позначте рівень, потім перевірте, чи живе запропонований засіб контролю на цьому рівні чи на рівні підтримки. Запитання про IAM, VPC, хмарні балансувальники навантаження чи шифрування сховища зазвичай починається на рівні Cloud. Запитання про API-сервер, etcd, RBAC, допуск, вузли чи аудиторське логування зазвичай починається на рівні Cluster. Запитання про образи, Linux-можливості, хостові простори імен чи ізоляцію середовища виконання зазвичай починається на рівні Container. Запитання про залежності, автентифікацію застосунку чи валідацію введення зазвичай починається на рівні Code.

Якщо запитання згадує…	Це про рівень…
IAM, VPC, хмарний провайдер	Cloud
API-сервер, etcd, RBAC, вузли	Cluster
Образи, середовище виконання, можливості	Container
Залежності, автентифікація	Code

Позначка рівня — не остаточна відповідь; це карта. Якщо проблема — надмірно привілейований сервісний акаунт, ви передусім на рівні Cluster, але вплив може охопити Code, бо скомпрометований процес застосунку може використати цей токен. Якщо проблема — вразлива залежність, ви передусім на рівні Code, але стримування може спиратися на засоби контролю Container, як-от запуск не від root та скинуті можливості.

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

Саме тому «захистити застосунок» і «захистити кластер» — не конкурентні завдання. Це два погляди на той самий ризик. Команда, яка латає код, але ігнорує RBAC, усе одно може втратити секрети після однієї помилки. Команда, яка зміцнює RBAC, але розгортає старі вразливі образи, усе одно може зіткнутися з повторним початковим доступом. 4 C допомагають вам уникнути розв’язання лише того рівня, яким володіє ваша команда.

Поширені компроміси безпеки

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

More Secure                          More Usable
────────────────────────────────────────────────────────────
Require MFA for every action         Single sign-on everywhere
Rotate credentials hourly            Never rotate credentials
Deny all network traffic             Allow all network traffic

KCSA asks: What's the appropriate balance for the scenario?

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

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

More Secure                          Better Performance
────────────────────────────────────────────────────────────
Encrypt all traffic (TLS)            Plain HTTP
Scan every image at runtime          Skip runtime scanning
Log every API call                   Minimal logging

KCSA asks: Which security controls are worth the cost?

Безпека проти продуктивності з’являється, коли засоби контролю споживають CPU, пам’ять, сховище чи бюджет затримки. Шифрування, перевірки допуску, сканування образів, аудиторське логування та sidecar-и service mesh можуть додавати вимірюваних накладних витрат. Безпекове мислення не ігнорує ці накладні витрати; воно запитує, чи виправдовують їх захищені дані, регуляторне середовище, модель загроз та ціна інциденту.

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

More Secure                          Simpler
────────────────────────────────────────────────────────────
Network policies per pod             No network policies
RBAC per resource type               cluster-admin for everyone
Separate service accounts            Default service account

KCSA asks: Does added complexity provide meaningful security?

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

Практичний захисник просить найпростіший засіб контролю, що розриває важливий шлях. Мережеві політики із забороною за замовчуванням та невеликим набором явних дозволів можуть бути зрозумілішими, ніж десятки перекривних широких політик. Окремі сервісні акаунти на робоче навантаження можуть бути вартими додаткових маніфестів, бо вони роблять перегляд RBAC конкретним. Рішення — не «просте чи безпечне»; воно «достатньо просте, щоб експлуатувати, і достатньо сильне, щоб стримати збій».

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

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

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

Третій патерн — малі, тестовані типові налаштування. Мережева політика із забороною за замовчуванням, шаблони робочих навантажень не від root, кореневі файлові системи лише для читання там, де можливо, вузькі сервісні акаунти та аудиторське логування для чутливих ресурсів легше викладати й перевіряти, коли вони вбудовані в шаблони. Патерн масштабується, бо команди починають із безпечніших типових налаштувань і обґрунтовують винятки, а не заново відкривають кожен засіб контролю під час кожного перегляду.

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

Інший антипатерн — постійний екстрений доступ. Інциденти трапляються, і командам іноді потрібне швидке підвищення прав, щоб відновити сервіс, але екстрений шлях стає вразливістю, коли він ніколи не закінчується. Краща альтернатива — задокументований процес break-glass із вузьким обсягом, логуванням, переглядом та очищенням після інциденту. Мета — швидкість під тиском без перетворення терміновості на постійний привілей.

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

Коли це використовувати замість альтернатив

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

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

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

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

Чи знали ви?

• Нульова довіра стала формальним федеральним архітектурним орієнтиром у 2020 році, коли NIST опублікував Special Publication 800-207, перетворивши широку галузеву ідею на конкретну модель, засновану на явній верифікації та найменших привілеях.

• Ешелонована оборона походить із військової стратегії, де кілька оборонних ліній складніше пробити, ніж один сильний бар’єр; Kubernetes застосовує ту саму ідею через хмарні засоби контролю, засоби контролю кластера, засоби контролю робочих навантажень та засоби контролю застосунків.

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

• Модель 4 C — це словник хмарної безпеки CNCF, прийнятий у настановах з безпеки Kubernetes; багаторівнева концепція універсальна для хмари, кластера, контейнера та коду.

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

Помилка	Чому вона трапляється	Як її виправити
Пошук «найскладнішої» відповіді	Складність може здаватися зрілістю, особливо коли кілька засобів контролю мають назви, що звучать безпеково.	Обирайте засіб контролю, що найпряміше розриває описаний шлях атаки з найменшим необхідним обсягом.
Ігнорування контексту сценарію	Учні запам’ятовують улюблений засіб контролю й застосовують його навіть тоді, коли сценарій описує інший ризик.	Визначте актив, позицію зловмисника та наступний крок, перш ніж порівнювати відповіді.
Припущення, що «більше — краще»	Команди додають засоби контролю, не перевіряючи зручність, продуктивність чи операційне володіння.	Застосуйте найменші привілеї та ешелоновану оборону, потім перевірте, чи залишається система зрозумілою та зручною.
Забування про ешелоновану оборону	Сильний окремий засіб контролю створює впевненість, тож внутрішні рівні залишають широкими чи без моніторингу.	Запитайте, що все ще обмежує шкоду, якщо найсильніший засіб контролю відмовить чи буде обійдений.
Невміння мислити як зловмисник	Перегляди зосереджуються на запланованій поведінці й пропускають шляхи зловживання через облікові дані, мережі чи типові налаштування.	Для кожного маніфесту запитайте «як цим можна зловживати після компрометації?» і простежте наступні два кроки.
Сприйняття відповідності як моделі загроз	Аудиторські вимоги легше виміряти, ніж поведінку зловмисника, тож команди оптимізують лише під докази.	Використовуйте відповідність як базову лінію, потім проведіть перегляд, керований загрозами, для фактичного робочого навантаження й даних.
Надання постійного екстреного привілею	Нагальні потреби діагностики стають постійним доступом, бо очищення незручне.	Використовуйте обмежений у часі доступ break-glass з аудиторським логуванням та переглядом після інциденту.

Тест

Ваша команда розгорнула вебзастосунок із налаштованим RBAC, але без мережевих політик. Зловмисник експлуатує вразливість застосунку й отримує доступ до оболонки всередині контейнера. Який принцип безпеки було порушено і що зловмисник міг би зробити далі?

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

Перегляд безпеки виявляє, що розробники в просторі імен `team-alpha` мають `cluster-admin` через ClusterRoleBinding, бо вони іноді діагностують робочі навантаження в інших просторах імен. Які принципи це порушує і що б ви порекомендували?

Це порушує найменші привілеї, бо cluster-admin надає набагато більше, ніж потребують перегляд логів чи діагностика подів. Це також послаблює нульову довіру, бо членство в команді стає широким неявним рішенням про довіру в усьому кластері. Кращий дизайн — вузька Роль чи ClusterRole лише з потрібними дієсловами й ресурсами, потім RoleBindings у просторах імен, де доступ виправданий. Якщо тимчасова міжпросторова діагностика необхідна, зробіть її обмеженою в часі й аудійованою, а не постійною.

Сценарій іспиту показує под із `hostNetwork: true`, `runAsUser: 0` та без мережевих політик. Запитання просить найзначущішу проблему безпеки. Як вам слід міркувати про це?

Думайте від наступного ходу зловмисника. hostNetwork: true особливо небезпечний, бо розміщує под у хостовому мережевому просторі імен і може обійти звичайні припущення про мережу пода. Запуск від root збільшує можливу шкоду всередині контейнера, а відсутні мережеві політики полегшують бічне переміщення, але хостова мережа послаблює головну межу ізоляції. Найкраща відповідь пояснює, чому це налаштування створює ширшу досяжність після компрометації, а не просто те, що воно виглядає ризикованим.

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

Ланцюжок починається з початкового доступу через скомпрометований под, потім переходить до крадіжки облікових даних через токен сервісного акаунта, далі досягає впливу, коли секрети перелічено. Засоби захисту могли б розірвати ланцюжок у кількох точках: вузький RBAC, щоб токен не міг перелічувати секрети; вимкнення чи обмеження монтування токена ServiceAccount там, де це непотрібно (automountServiceAccountToken: false); сповіщення про незвичайний доступ до Secret; за бажанням обмеження egress до Service API Kubernetes там, де CNI це підтримує. Урок у тому, що один зламаний под не має автоматично ставати обліковим записом кластера. Кілька засобів контролю роблять кожен крок складнішим і помітнішим.

Офіцер з відповідності хоче mTLS у service mesh для кожного виклику між подами, тоді як інженерна команда переймається затримкою та операційною ціною. Як би ви сформулювали це рішення?

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

Команда каже, що її кластер безпечний, бо кожен простір імен має об'єкт NetworkPolicy, але ви помічаєте, що кілька політик дозволяють весь ingress від усіх подів. Якою є відповідь із безпековим мисленням?

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

Ви переглядаєте робоче навантаження, яке використовує типовий сервісний акаунт, змінні теги образів, запуск від root та записувану кореневу файлову систему. Команда питає, яку проблему виправити першою. Як ви розставляєте пріоритети?

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

Практична вправа: аналіз безпеки

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

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

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      runAsUser: 0
      privileged: true
    ports:
    - containerPort: 80
  hostNetwork: true
  hostPID: true

Виконайте ці завдання по порядку:

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

Запропонований аналіз

Маніфест має кілька високоризикових виборів. runAsUser: 0 запускає процес від root усередині контейнера, що збільшує ефект компрометації процесу. privileged: true дає широкі можливості рівня хоста й може зробити втечу з контейнера чи втручання в хост набагато легшими. image: myapp:latest використовує змінний тег, тож рецензенти не можуть бути впевнені, яка версія образу запущена. hostNetwork: true розміщує под у хостовому мережевому просторі імен, а hostPID: true дозволяє йому бачити хостові процеси. Відсутні безпечніші типові налаштування, як-от коренева файлова система лише для читання та скинуті можливості, прибирають додаткові рівні стримування.

Запропоноване розставлення пріоритетів

Два найшвидші шляхи до тяжкого впливу — це зазвичай privileged: true та налаштування хостових просторів імен. Привілейований режим прямо послаблює межу контейнера, тоді як хостова мережа й доступ до host PID відкривають поверхні рівня вузла, які звичайним подам не мають бути потрібні. Запуск від root також серйозний, але він стає особливо небезпечним у поєднанні з привілейованим режимом і хостовим доступом. Пріоритет має ґрунтуватися на тому, як швидко скомпрометований процес може вплинути на вузол чи вийти за межі запланованого робочого навантаження.

Запропонований безпечніший напрямок

Безпечніший напрямок — прибрати привілейований режим, уникати хостових просторів імен, запускати від користувача не-root, скинути непотрібні можливості, закріпити образ до незмінної версії чи дайджесту й додати кореневу файлову систему лише для читання, якщо застосунок це підтримує. Робоче навантаження також має використовувати виділений сервісний акаунт із вузьким RBAC, а не типовий сервісний акаунт. Якщо застосунку потрібен мережевий доступ, дозвольте лише потрібні джерела й призначення через NetworkPolicy, а не покладайтеся на пласку мережу кластера.

Критерії успіху:

• Ви пояснили кожну проблему як перевагу зловмисника, а не лише як назву поля.
• Ви пов’язали проблеми щонайменше з двома принципами безпеки з уроку.
• Ви розставили пріоритети виправлень за радіусом ураження й ланцюжком атаки, а не за абеткою.
• Ви запропонували безпечніші типові налаштування, що зберігають базове призначення робочого навантаження.
• Ви можете відстояти свою рекомендацію в одній стислій відповіді в стилі KCSA.

Джерела

• Документація Kubernetes: Overview of Cloud Native Security
• Документація Kubernetes: The 4 Cs of Cloud Native Security
• Документація Kubernetes: Pod Security Standards
• Документація Kubernetes: Good practices for Kubernetes RBAC
• Документація Kubernetes: Network Policies
• Документація Kubernetes: Configure a Security Context
• Документація Kubernetes: Secrets
• Документація Kubernetes: Using RBAC Authorization
• Документація Kubernetes: Admission Controllers
• Документація Kubernetes: Auditing
• NIST Special Publication 800-207: Zero Trust Architecture
• CNCF Cloud Native Security Whitepaper

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

Модуль 1.1: 4 C хмарної безпеки — глибоке занурення у фундаментальну модель безпеки для хмарних систем.