Модуль 1.1: Чотири С безпеки хмарних технологій

Складність: [СЕРЕДНЯ] — базовий фреймворк безпеки для тих, хто готується до KCSA і має навчитися класифікувати неоднозначні знахідки в хмарних середовищах через межі інфраструктури, Kubernetes, середовища виконання та застосунку.

Час на проходження: 35–45 хвилин

Передумови: Модуль 0.2: Мислення безпеки

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

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

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

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

Наприкінці 2019 року велика компанія фінансових послуг повідомила, що зловмисник дістався до конфіденційних даних застосунку, зловживши вадою типу server-side request forgery та сервісом метаданих хмарного інстансу. Публічне обговорення зосередилося на ваді вебзастосунку, але глибший урок був багаторівневим: код застосунку прийняв небезпечний запит, середовище виконання могло дістатися до метаданих, хмарна ідентичність дозволила доступ до даних, а моніторинг не зупинив цю послідовність достатньо швидко. Повідомлений вплив на бізнес включав регуляторні штрафи, юридичні витрати, роботу з усунення наслідків та роки репутаційних збитків — і саме тому безпеку хмарних технологій не можна звести до одного сканера, одного фаєрвола чи однієї політики Kubernetes.

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

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

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

Модель 4 С: стек залежностей

Модель 4 С — це не чотири незалежні контрольні списки. Це стек залежностей, де кожен рівень успадковує ризик від рівня під ним. Cloud є фундаментом, тому що Kubernetes працює на інфраструктурі, ідентичностях, мережах і сховищах, які існують ще до того, як кластер зможе щось захищати. Cluster іде наступним, тому що API-сервер, контролери допуску, RBAC, NetworkPolicies та конфігурація вузлів вирішують, що дозволено робити робочим навантаженням. Container іде далі, бо образи, ізоляція середовища виконання, можливості Linux та налаштування файлової системи визначають, скільки шкоди може завдати запущений процес. Code є найглибшим внутрішнім рівнем, тому що логіка застосунку, залежності, автентифікація та обробка даних — це те, до чого користувачі та зловмисники зазвичай дотикаються першими.

┌─────────────────────────────────────────────────────────────┐
│                    THE 4 Cs OF SECURITY                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│      Each layer builds on the security of the layer         │
│      below it. A breach at any layer can weaken all         │
│      layers above it unless other controls contain it.      │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │                     CLOUD                           │    │
│  │  Infrastructure, network, identity, storage          │    │
│  │  ┌─────────────────────────────────────────────┐    │    │
│  │  │                  CLUSTER                    │    │    │
│  │  │  Kubernetes control plane and configuration  │    │    │
│  │  │  ┌─────────────────────────────────────┐    │    │    │
│  │  │  │             CONTAINER               │    │    │    │
│  │  │  │  Image, runtime, and isolation       │    │    │    │
│  │  │  │  ┌─────────────────────────────┐    │    │    │    │
│  │  │  │  │           CODE              │    │    │    │    │
│  │  │  │  │  Application and libraries   │    │    │    │    │
│  │  │  │  └─────────────────────────────┘    │    │    │    │
│  │  │  └─────────────────────────────────────┘    │    │    │
│  │  └─────────────────────────────────────────────┘    │    │
│  └─────────────────────────────────────────────────────┘    │
│                                                             │
│  Security at one layer cannot erase insecurity below it;    │
│  it can only reduce what happens after the lower layer       │
│  has already been trusted.                                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

Активна перевірка: Якщо розробник каже: «Ми використовуємо distroless-образи й відкидаємо можливості Linux, тож сервіс безпечний», — який рівень розробник адресував, а які рівні залишаються непідтвердженими? Напишіть одне речення, яке відокремлює правдиву частину твердження від ризикованого припущення.

Рівень	Головне питання	Типовий власник	Приклад засобу контролю
Cloud	Чи можна достатньо довіряти базовій інфраструктурі, мережі, ідентичності та сховищу, щоб розмістити на них кластер?	Хмарна платформа, інфраструктура, інженерія безпеки	IAM із найменшими привілеями, приватні підмережі, зашифровані томи, правила фаєрвола, журнали аудиту
Cluster	Чи безпечно Kubernetes автентифікує, авторизує, допускає, ізолює, планує та спостерігає за робочими навантаженнями?	Інженерія платформи, адміністратори Kubernetes, інженерія безпеки	RBAC, Pod Security Standards, політика допуску, NetworkPolicy, шифрування etcd, політика аудиту
Container	Чи обмежують образ і конфігурація середовища виконання те, що може робити процес після запуску?	Платформа застосунків, DevSecOps, власники робочих навантажень	Сканування образів, підписування, користувачі не-root, файлова система лише для читання, seccomp, відкинуті можливості
Code	Чи безпечно застосунок обробляє користувачів, дані, залежності, секрети та зовнішній ввід?	Команди застосунків, продуктова інженерія, безпека застосунків	Валідація вводу, сканування залежностей, перевірки авторизації, обробка секретів, безпечне керування сесіями

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

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

Рівень 1: Cloud, межа інфраструктури

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

┌─────────────────────────────────────────────────────────────┐
│              CLOUD LAYER SECURITY                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  IDENTITY & ACCESS                                          │
│  ├── IAM policies with least privilege                      │
│  ├── MFA for privileged users                               │
│  └── Short-lived credentials for automation                 │
│                                                             │
│  NETWORK                                                    │
│  ├── VPC or virtual network isolation                       │
│  ├── Security groups, firewalls, and routing controls       │
│  ├── Private subnets for sensitive control paths            │
│  └── TLS for external entry points                          │
│                                                             │
│  COMPUTE                                                    │
│  ├── Patched node images and host operating systems         │
│  ├── Encrypted root and data volumes                        │
│  └── Restricted instance metadata access                    │
│                                                             │
│  DATA                                                       │
│  ├── Encryption at rest with managed keys where needed      │
│  ├── Encryption in transit between managed services         │
│  └── Access logging for storage and administrative APIs     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

┌─────────────────────────────────────────────────────────────┐
│              SHARED RESPONSIBILITY MODEL                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  MANAGED KUBERNETES (EKS, GKE, AKS, and similar services)   │
│  ├── Provider: Managed control plane operations             │
│  └── You: Workloads, RBAC, policies, identity, networking   │
│                                                             │
│  SELF-MANAGED KUBERNETES                                   │
│  ├── Provider: Underlying compute and physical facilities   │
│  └── You: Control plane, nodes, patches, policies, apps     │
│                                                             │
│  ON-PREMISES                                                │
│  └── You: Physical security through application behavior    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Компонент Cloud	Що може піти не так	Виправлення, коректне для рівня
Хмарна роль IAM для автоматизації	Завдання CI може створювати кластери, прикріплювати адміністраторські політики або читати непов’язане сховище, бо його хмарна роль надто широка.	Розділіть ролі розгортання, використовуйте короткоживучі облікові дані, обмежте дозволи лише потрібними ресурсами та журналюйте використання адміністративного API.
Правила віртуальної мережі та фаєрвола	Точка доступу до площини управління, порт вузла, база даних або внутрішній сервіс стають доступними з мереж, які ніколи не мали б із ними спілкуватися.	Використовуйте приватні точки доступу, де доречно, звужуйте правила вхідного й вихідного трафіку та переглядайте таблиці маршрутизації разом із виставленням Kubernetes.
Керований сервіс ключів	Конфіденційні томи або шифрування секретів залежать від ключів, якими може адмініструвати або які може вимкнути забагато операторів.	Відокремте адміністрування ключів від адміністрування кластера, увімкніть ротацію, де доречно, та проводьте аудит використання ключів.
Сервіс метаданих інстансу	Скомпрометований Под дістається до метаданих вузла й викрадає інфраструктурні облікові дані, прикріплені до вузла.	Обмежте доступ до метаданих, віддавайте перевагу механізмам ідентичності робочого навантаження та уникайте надання вузлам широких хмарних дозволів.

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

Активна перевірка: Ваша команда виявляє Под, який може читати хмарне об’єктне сховище, хоча його сервісний акаунт Kubernetes не має жодних дозволів, окрім читання ConfigMap. Який рівень слід дослідити першим і які докази довели б, чи це проблема ідентичності Cloud, чи проблема RBAC рівня Cluster?

Практичний приклад робить межу зрозумілішою. Припустимо, простір імен платежів має ретельний RBAC, але кожен вузол у групі вузлів несе хмарну роль, яка може читати спільне розрахункове сховище. Скомпрометованому Поду може не знадобитися доступ до Secret у Kubernetes, якщо він може дістатися до метаданих, отримати облікові дані вузла й безпосередньо викликати API сховища. Затягування RoleBinding у Kubernetes усе одно було б доброю гігієною, але воно не прибрало б шлях до даних. Виправлення, коректне для рівня, — зменшити обсяг хмарної ідентичності, віддати перевагу ідентичності робочого навантаження, де доступно, та обмежити шляхи метаданих чи вихідного трафіку, щоб Поди не успадковували дозволи, призначені для інфраструктури.

Рівень 2: Cluster, межа управління Kubernetes

Рівень Cluster — це місце, де Kubernetes вирішує, хто може чого вимагати, які запити дозволені, де працюють робочі навантаження, як спілкуються Поди та як захищено стан кластера. Цей рівень включає API-сервер, etcd, controller-manager, scheduler, kubelet, kube-proxy або його заміну, контролери допуску, RBAC, сервісні акаунти, журнали аудиту, Pod Security Standards та NetworkPolicies. Це той рівень, який більшість тих, хто навчається, асоціюють із безпекою Kubernetes, але це лише один рівень у моделі. Засоби контролю рівня Cluster найефективніші, коли вони припускають, що застосунок зрештою може бути скомпрометований, а хмарний фундамент усе ще потребує окремої перевірки.

┌─────────────────────────────────────────────────────────────┐
│              CLUSTER LAYER SECURITY                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  API SERVER                                                 │
│  ├── TLS for all API communication                          │
│  ├── Strong authentication through OIDC or certificates     │
│  ├── RBAC authorization with least privilege                │
│  └── Audit logging for sensitive operations                 │
│                                                             │
│  ETCD                                                       │
│  ├── Encryption at rest for Secrets where supported         │
│  ├── TLS for peer and client communication                  │
│  └── Restricted network access to datastore endpoints       │
│                                                             │
│  NODES                                                      │
│  ├── Secure kubelet configuration                           │
│  ├── Disabled anonymous and read-only access where relevant │
│  └── Node authorization and NodeRestriction admission       │
│                                                             │
│  WORKLOAD CONTROLS                                          │
│  ├── Pod Security Standards                                 │
│  ├── NetworkPolicies with a default-deny posture            │
│  └── Resource quotas and limit ranges for guardrails        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Засоби контролю рівня Cluster потужні, бо кожне робоче навантаження проходить через Kubernetes, перш ніж запуститися. Специфікація Пода може бути відхилена політикою допуску ще до того, як запуститься ризикований контейнер. Сервісному акаунту може бути відмовлено в доступі до Secret навіть після того, як застосунок скомпрометовано. NetworkPolicy може зупинити вразливий фронтенд від прямого доступу до простору імен бази даних. Ці засоби контролю не роблять поганий код добрим, але вони можуть запобігти перетворенню вади рівня Code на повну компрометацію середовища.

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

Засіб контролю Cluster	Зменшений ризик	Що він не вирішує
RBAC	Обмежує, що автентифіковані користувачі й сервісні акаунти можуть робити через API Kubernetes.	Сам по собі не зупиняє ін’єкцію на рівні застосунку, небезпечний хмарний IAM чи трафік між Подами.
Політика допуску	Відхиляє ризиковані об’єкти, перш ніж їх збережено чи заплановано, як-от привілейовані Поди чи недовірені образи.	Не патчить вразливі залежності, що вже всередині схваленого образу.
NetworkPolicy	Обмежує спілкування Под-Под та Под-зовнішнє за підтримки мережевим плагіном.	Не замінює авторизацію застосунку чи правила хмарного фаєрвола.
Журналювання аудиту	Створює докази активності API для виявлення, розслідування та відповідності.	Не запобігає дії, якщо не поєднано з політикою чи автоматизацією реагування.
Шифрування etcd	Захищає збережені дані Secret у Kubernetes, якщо сховище чи резервні копії виставлено.	Не зупиняє Под із легітимним доступом до Secret від читання Secret через API.

Корисна звичка досвідченого фахівця — питати: «Яка точка ухвалення рішення в Kubernetes мала зупинити це?». Якщо об’єкт ніколи не мав бути допущений, дивіться на політику допуску. Якщо ідентичність не мала мати доступу до API, дивіться на RBAC. Якщо Под не мав дістатися до іншого сервісу, дивіться на NetworkPolicy й мережевий плагін. Якщо конфіденційний стан було виставлено в спокої, дивіться на шифрування etcd, обробку резервних копій та доступ до сховища. Це питання тримає аналіз сфокусованим на механізмах Kubernetes, а не зісковзує в розпливчасті поради.

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

Перш ніж запускати будь-яку команду в реальному середовищі, передбачте, які докази змінили б ваше рішення. Якщо auth can-i каже, що сервісний акаунт може отримати список Secret, проблема — в авторизації Cluster, навіть якщо код застосунку теж вразливий. Якщо NetworkPolicy існує, але мережевий плагін її не застосовує, об’єкт може створити хибну впевненість. Якщо журнали аудиту показують, що адміністратор-людина створив ризикований RoleBinding під час інциденту, виправлення може стосуватися робочого процесу затвердження та сповіщень не менше, ніж очищення YAML. KCSA очікує саме такої класифікації, заснованої на доказах.

Рівень 3: Container, межа середовища виконання

Рівень Container охоплює те, що є всередині образу, і те, що дозволяє середовище виконання після запуску образу. Сюди входять базові образи, встановлені пакети, походження образу, сканування вразливостей, підписування, налаштований користувач, можливості Linux, профілі seccomp та AppArmor, змінюваність файлової системи, привілейований режим, спільне використання просторів імен хоста та вибір середовища виконання, як-от containerd, CRI-O чи ізольовані середовища виконання. Це місце, де «процес у коробці» стає або корисною межею, або слабкою рекомендацією.

┌─────────────────────────────────────────────────────────────┐
│              CONTAINER LAYER SECURITY                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  IMAGES                                                     │
│  ├── Use minimal base images where practical                │
│  ├── Scan operating system and language packages            │
│  ├── Sign images and verify provenance                      │
│  └── Use immutable references instead of floating tags      │
│                                                             │
│  RUNTIME                                                    │
│  ├── Run as a non-root user                                 │
│  ├── Use a read-only root filesystem when the app allows it │
│  ├── Drop all Linux capabilities, then add only required    │
│  └── Use seccomp or AppArmor profiles                       │
│                                                             │
│  ISOLATION                                                  │
│  ├── Avoid privileged containers                            │
│  ├── Disable hostPID, hostNetwork, and hostIPC by default   │
│  └── Consider sandboxed runtimes for high-risk workloads    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

┌─────────────────────────────────────────────────────────────┐
│              CONTAINER ESCAPE PATH                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Misconfigured Container                                    │
│  │                                                          │
│  ├── privileged: true                                       │
│  │   └── Broad access to host devices and kernel surfaces   │
│  │                                                          │
│  ├── hostPID: true                                          │
│  │   └── Visibility into host process identifiers           │
│  │                                                          │
│  ├── hostNetwork: true                                      │
│  │   └── Direct use of the node network namespace           │
│  │                                                          │
│  └── Combined with a runtime or kernel flaw                 │
│      └── Potential path from container compromise to node   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Тонкий момент полягає в тому, що деякі засоби контролю стосуються двох рівнів одночасно. Підписування образів є питанням рівня Container, бо воно щось доводить про образ, але застосування перевірки підпису під час допуску є механізмом рівня Cluster. Ризик — це походження образу; точка застосування — допуск у Kubernetes. Хороші відповіді на KCSA часто визнають обидва: засіб контролю належить до одного рівня для класифікації ризику й до іншого рівня для впровадження. Уникайте суперечок про єдину мітку, коли краща відповідь — назвати ризик і точку застосування окремо.

Налаштування контейнера	Безпечніше типове значення	Чому налаштування має значення
`runAsNonRoot`	Вимагайте true, коли образ це підтримує.	Скомпрометований процес не має автоматично отримувати права root всередині контейнера.
`readOnlyRootFilesystem`	Увімкніть для сервісів, які пишуть лише в явні томи чи тимчасові каталоги.	У зловмисників і коду з вадами менше місць, щоб закріпити інструменти чи змінити файли середовища виконання.
`allowPrivilegeEscalation`	Установіть false, якщо ретельно перевірене робоче навантаження цього не вимагає.	Процес не має отримувати більше привілеїв, ніж надає його початкова конфігурація контейнера.
`capabilities`	Відкиньте всі, потім додайте лише задокументований мінімальний набір.	Можливості Linux розбивають root-подібні повноваження на менші частини, які не слід надавати недбало.
`privileged`	Тримайте false для звичайних робочих навантажень.	Привілейовані контейнери послаблюють ізоляцію й можуть створити шлях до компрометації вузла.
`seccompProfile`	Використовуйте `RuntimeDefault` як базову лінію в Kubernetes 1.35+, якщо робоче навантаження не потребує власного профілю.	Seccomp зменшує поверхню системних викликів, доступну процесу.

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

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

Зупиніться й передбачте: якщо ви приберете privileged: true з робочого навантаження, але залишите hostNetwork: true й широкий вихідний трафік, який ризик змінився, а який залишається? Перша зміна зменшує доступ до пристроїв хоста й поверхонь ядра, що є покращенням рівня Container. Залишена мережева конфігурація все одно дозволяє процесу використовувати простір імен мережі вузла та широко спілкуватися, тобто рішення про вихідний трафік на рівнях Cluster і Cloud усе ще потребують огляду. Саме тому часткове посилення слід описувати точно, а не рекламувати як «безпечне».

Рівень 4: Code, межа застосунку

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

┌─────────────────────────────────────────────────────────────┐
│              CODE LAYER SECURITY                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  SECURE CODING                                              │
│  ├── Validate input at trust boundaries                     │
│  ├── Encode output for the destination context              │
│  ├── Use parameterized queries for database access          │
│  └── Handle errors without leaking sensitive details        │
│                                                             │
│  DEPENDENCIES                                               │
│  ├── Scan direct and transitive dependencies                │
│  ├── Pin versions and update through reviewed changes       │
│  ├── Verify integrity where package ecosystems support it   │
│  └── Remove unused libraries to reduce attack surface       │
│                                                             │
│  SECRETS                                                    │
│  ├── Never hardcode secrets into source or images           │
│  ├── Use Kubernetes Secrets or external secret stores       │
│  ├── Rotate credentials after exposure or staff changes     │
│  └── Prefer short-lived tokens when the platform supports it│
│                                                             │
│  AUTHENTICATION AND AUTHORIZATION                           │
│  ├── Verify identity with strong authentication mechanisms  │
│  ├── Enforce authorization for every sensitive operation    │
│  └── Keep server-side checks independent of client controls │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Вразливості рівня Code легко недооцінити, бо вони не завжди виглядають як проблеми Kubernetes. Зламана перевірка доступу може дозволити одному орендарю читати дані іншого орендаря. Вада типу server-side request forgery може дозволити зловмиснику дістатися до внутрішніх точок доступу. Вразлива бібліотека журналювання може виконати ввід, контрольований зловмисником. Жорстко закодований пароль може спрацювати будь-де, де розгорнуто застосунок. Kubernetes може зменшити радіус ураження, але він не може вивести бізнес-правило, яке ваш застосунок забув застосувати. Застосунок володіє цими правилами, бо лише застосунок розуміє своїх користувачів, орендарів, транзакції та модель даних.

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

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

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

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

Як рівні взаємодіють

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

┌─────────────────────────────────────────────────────────────┐
│              BREACH IMPACT CASCADE                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CLOUD breach (cloud credentials leaked)                    │
│  └── Attacker may be able to:                               │
│      ├── Reach or modify clusters                           │
│      ├── Attach or inspect storage                          │
│      └── Change network and identity boundaries             │
│                                                             │
│  CLUSTER breach (Kubernetes administrator access)           │
│  └── Attacker may be able to:                               │
│      ├── Deploy malicious containers                        │
│      ├── Read Kubernetes Secrets                            │
│      └── Move across namespaces unless constrained          │
│      (cloud infrastructure may still require separate auth) │
│                                                             │
│  CONTAINER breach (runtime escape or weak isolation)        │
│  └── Attacker may be able to:                               │
│      ├── Affect the node or neighboring workloads           │
│      └── Steal files available to the container or node     │
│      (cluster-wide API access still depends on credentials) │
│                                                             │
│  CODE breach (application vulnerability)                    │
│  └── Attacker may be able to:                               │
│      ├── Access application data and in-process secrets     │
│      └── Act as the application until contained             │
│      (other layers should limit privilege and movement)     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Саме це вирівнювання відрізняє архітектуру безпеки від купи інструментів. Якщо сценарій — «компрометація фронтенду», рівень Code потребує валідації та авторизації, рівень Container потребує виконання від не-root та вузької файлової системи, рівень Cluster потребує сервісних акаунтів із найменшими привілеями та обмежень вихідного трафіку, а рівень Cloud потребує обмеженої ідентичності й спостережуваного доступу до сховища. Єдина панель може повідомляти про всі ці знахідки, але план реагування все одно має називати рівень, бо власність, терміновість і перевірка різняться.

Розбір прикладу: класифікація та локалізація підозрілого Пода

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

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

Крок розв’язання 2: зіставте кожну конкретну знахідку з рівнем, до якого вона належить. Вразлива залежність застосунку чи небезпечний обробник запитів — це Code. Вразливі пакети базового образу та користувач root — це Container. Відсутня NetworkPolicy — це Cluster. Широка роль вузла, яка може читати об’єктне сховище, — це Cloud.

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

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

Крок розв’язання 5: перетворіть інцидент на багаторівневий стандарт. Після негайного реагування команда має визначити бар’єри релізу й типові налаштування платформи: оновлення залежностей для Code, сканування образів і типове виконання від не-root для Container, NetworkPolicies з типовою відмовою та політику допуску для Cluster і вузьку ідентичність робочого навантаження для Cloud. Хід досвідченого фахівця — перетворити разове виправлення на повторюваний засіб контролю, який ловить подібні збої раніше.

┌─────────────────────────────────────────────────────────────┐
│              WORKED EXAMPLE MAPPING                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Finding: broad node role can read object bucket             │
│  Layer:   Cloud                                             │
│  Fix:     narrow cloud IAM and prefer workload identity      │
│                                                             │
│  Finding: namespace has no egress NetworkPolicy              │
│  Layer:   Cluster                                           │
│  Fix:     default-deny egress plus explicit service paths    │
│                                                             │
│  Finding: Pod runs as root and image has package findings    │
│  Layer:   Container                                         │
│  Fix:     patched image, non-root user, runtime hardening    │
│                                                             │
│  Finding: application accepted malicious input               │
│  Layer:   Code                                              │
│  Fix:     validate input and add regression tests            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

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

Практичні патерни класифікації

Деякі елементи безпеки легко класифікувати, бо вони живуть цілком в одному рівні. Правила фаєрвола VPC — це Cloud. RBAC — це Cluster. runAsNonRoot — це Container. Запобігання SQL-ін’єкціям — це Code. Складніші екзаменаційні та реальні випадки поєднують ризик, точку застосування й власника, тож вам потрібен повторюваний метод класифікації, а не завчений список. Класифікація — це інженерна звичка: назвіть порушену межу, назвіть систему, яка застосовує засіб контролю, і назвіть докази, які ви оглянули б.

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

Підказка сценарію	Імовірний рівень	Патерн міркування
«Хмарна роль може створювати балансувальники навантаження в будь-якому проєкті чи акаунті.»	Cloud	Ризик — це інфраструктурна ідентичність і зовнішнє виставлення, навіть якщо балансувальник навантаження стоїть перед сервісами Kubernetes.
«Сервісний акаунт може отримувати список Secret у всіх просторах імен.»	Cluster	Ризик — це авторизація API Kubernetes через RBAC, а не код застосунку, який використовує токен.
«Поду дозволено працювати з `privileged: true`.»	Container і Cluster	Ризикований стан середовища виконання — це Container, тоді як політика допуску — це механізм Cluster, який має це запобігти.
«Базовий образ містить вразливий пакет OpenSSL.»	Container	Вразливий компонент запаковано в образ і він подорожує разом з артефактом середовища виконання.
«Параметр запиту потрапляє в запит до бази даних без зв’язування.»	Code	Застосунок будує небезпечну поведінку з недовіреного вводу.
«Под може дістатися до хмарних метаданих і отримати облікові дані вузла.»	Cloud і Cluster	Облікові дані належать до ідентичності Cloud, тоді як розміщення Пода й мережеві обмеження — це питання Cluster.
«Секрети зберігаються незашифрованими в резервних копіях etcd.»	Cluster	Сховище Kubernetes та обробка резервних копій є частиною захисту стану кластера.

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

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

kubectl version --client
alias k=kubectl
k explain pod.spec.securityContext
k explain pod.spec.containers.securityContext
k auth can-i list secrets --as=system:serviceaccount:demo:frontend -n demo

Ці команди не класифікують магічним чином кожен ризик, але вони показують місця, де рішення про рівень стають конкретними. Поля контексту безпеки описують конфігурацію виконання Container. kubectl auth can-i перевіряє авторизацію Cluster. Жодна з команд не каже, чи є хмарна роль IAM, прикріплена до робочого навантаження, надто широкою, чи валідує застосунок доступ орендаря. Це розділення і є суттю моделі 4 С. Використовуйте вивід команди як доказ для одного рівня, потім свідомо спитайте, що команда не оглянула.

Наприклад, успішна відмова k auth can-i — це добра новина для доступу до API Kubernetes, але вона нічого не каже про те, чи має робоче навантаження змінну середовища з хмарним токеном або чи може застосунок дістатися до внутрішньої точки доступу метаданих. Результат k explain може показати, де runAsNonRoot стоїть у схемі, але він не доводить, що розгорнутий Под справді використовує це налаштування. Уважний фахівець із діагностики записує, який рівень покриває кожна команда, а потім обирає наступну команду, щоб покрити інший рівень.

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

Використовуйте 4 С як контрольний список огляду з доказами, прикріпленими до кожного твердження. Корисна знахідка Cloud називає точну ідентичність, маршрут, правило фаєрвола, шлях метаданих чи дозвіл сховища. Корисна знахідка Cluster називає сервісний акаунт, RoleBinding, правило допуску, NetworkPolicy, об’єкт API чи подію аудиту. Корисна знахідка Container називає образ, користувача, можливість, налаштування файлової системи чи профіль середовища виконання. Корисна знахідка Code називає шлях запиту, залежність, правило авторизації, шлях обробки секрету чи межу даних. Якщо докази не можуть назвати конкретний об’єкт чи поведінку, твердження все ще надто розпливчасте для огляду інциденту.

Відокремте рівень, де живе ризик, від рівня, де застосовано засіб контролю. Непідписаний образ — це ризик ланцюга постачання Container, але допуск Kubernetes може застосувати правило довіри до прийняття Пода. Широка роль IAM вузла — це ризик ідентичності Cloud, але політика вихідного трафіку Cluster може зменшити, чи дістаються Поди до метаданих або хмарних API. Зламана перевірка орендаря — це ризик Code, але ізоляція Cluster може зменшити, до яких сусідніх сервісів дістанеться зловмисник після експлуатації. Зазначення обох боків тримає розмову технічною: «ризик Container, застосований допуском Cluster» зрозуміліше, ніж суперечка про те, чи власником виправлення є лише команда образів, чи лише команда платформи.

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

Небезпечний антипатерн — переоцінювати реальні докази. Чисте сканування образу підтверджує «жодних відомих знахідок не виявлено в цьому образі на час сканування», а не «сервіс безпечний». Приватна точка доступу кластера підтверджує «API-сервер недосяжний із довільних мереж», а не «робочі навантаження не можуть викрасти дані». Керована площина управління підтверджує «провайдер оперує вибраними компонентами площини управління», а не «клієнт не має відповідальності за RBAC чи допуск». Пропатчена вада застосунку підтверджує «один відомий шлях входу Code виправлено», а не «посилення середовища виконання більше не має значення».

Фреймворк ухвалення рішень

Для кожного сценарію напишіть три короткі мітки перед вибором виправлення: порушена межа, точка ухвалення рішення та доказ. Якщо знахідка — «Под може отримати список Secret», порушена межа — це авторизація Cluster, точка ухвалення рішення — це перевірка авторизації API Kubernetes, а доказ походить від kubectl auth can-i, інспектування RBAC чи журналів аудиту. Якщо знахідка — «Под може читати хмарне сховище через облікові дані вузла», порушена межа — це ідентичність Cloud, точка ухвалення рішення — це хмарний IAM і доставка облікових даних, а доказ походить від політики ролі вузла, прив’язки ідентичності робочого навантаження, доступу до метаданих чи хмарних журналів аудиту. Якщо знахідка — «клієнт може читати рахунок іншого клієнта», порушена межа — це авторизація Code, точка ухвалення рішення — це бізнес-логіка застосунку, а доказ походить від трасування запитів, тестів і журналів доступу.

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

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

Чи знали ви?

Модель 4 С з’являється в настановах із безпеки Kubernetes, бо вона дає командам спільний словник для багаторівневих засобів контролю, замість того щоб трактувати Kubernetes як єдину межу безпеки.
Pod Security Standards у Kubernetes визначають три рівні політики з назвами privileged, baseline та restricted, що допомагає командам міркувати про ризик рівня Container через допуск рівня Cluster.
Kubernetes 1.35+ усе ще використовує спільну відповідальність у керованих сервісах, бо провайдери можуть оперувати компонентами площини управління, тоді як клієнти налаштовують робочі навантаження, RBAC, допуск, простори імен і мережеву політику.
Посилення контейнера — це локалізація, а не виправлення застосунку, бо користувачі не-root, файлові системи лише для читання та seccomp зменшують можливості зловмисника після того, як код уже виконується.

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

Помилка	Чому вона трапляється	Як її виправити
Трактувати 4 С як чотири рівноцінні контрольні списки, а не як стек залежностей.	Команди можуть витрачати енергію на видимі засоби контролю, ігноруючи слабкості нижчих рівнів, що обходять усе над ними.	Почніть із фундаменту Cloud, потім політика Cluster, потім посилення Container, потім засоби контролю Code, продовжуючи підтримувати всі рівні.
Припускати, що хмарний провайдер обробляє весь рівень Cluster у керованому Kubernetes.	Керовані сервіси оперують частинами площини управління, але RBAC, допуск, мережева політика та конфігурація робочого навантаження, що належать клієнту, усе одно можуть бути небезпечними.	Прочитайте межу відповідальності провайдера й задокументуйте, які налаштування Kubernetes ваша команда має конфігурувати та аудитувати.
Називати кожен засіб контролю, пов’язаний з образом, «Container», не помічаючи точку застосування.	Сканування, підписування та перевірка допуску образів можуть стосуватися і ризику образу, і політики Kubernetes, тож надмірне спрощення приховує власність.	Зазначте рівень ризику й рівень застосування, коли засіб контролю охоплює обидва, як-от походження Container, застосоване допуском Cluster.
Використовувати RBAC як відповідь на проблеми мережевої авторизації чи авторизації застосунку.	RBAC контролює дії API Kubernetes, а не те, чи може один Под викликати інший сервіс або чи може користувач застосунку читати запис.	Поєднайте RBAC із NetworkPolicy для шляхів трафіку та авторизацією застосунку для бізнес-дій.
Вірити, що контейнери не-root роблять вразливий код безпечним.	Посилення середовища виконання обмежує шкоду, але застосунок усе одно може витікати дані, обробляти зловмисний ввід чи виконувати неавторизовані дії.	Виправте ваду рівня Code й тримайте засоби контролю Container як зменшення радіуса ураження.
Ігнорувати хмарну ідентичність, прикріплену до вузлів чи робочих навантажень.	Под із малими дозволами Kubernetes усе одно може отримати потужні хмарні облікові дані, якщо межі ідентичності слабкі.	Віддавайте перевагу обмеженій ідентичності робочого навантаження, вузьким ролям вузлів, обмеженням метаданих та хмарному журналюванню аудиту.
Виправляти першу видиму знахідку й закривати інцидент надто рано.	Інциденти часто перетинають рівні, тож один патч може залишити відкритим початковий шлях пересування чи шлях виставлення даних.	Побудуйте карту інциденту, що фіксує точку входу, засоби контролю, які дали збій, засоби контролю локалізації та остаточні виправлення на всіх чотирьох рівнях.

Тест

Ваша команда розгортає платіжний API на керованому сервісі Kubernetes. Под використовує пропатчений distroless-образ і працює від імені не-root, але його сервісний акаунт може отримувати список Secret у кожному просторі імен. Під час огляду хтось каже, що контейнер посилений, тож ризик низький. Як вам оцінити це твердження за допомогою моделі 4 С?

Відповідь
Твердження неповне, бо воно вказує на засоби контролю рівня Container, тоді як головна знахідка — це авторизація рівня Cluster. Контейнер distroless не-root зменшує шкоду середовища виконання після компрометації, але він не запобігає тому, щоб робоче навантаження скористалося токеном свого сервісного акаунта Kubernetes для отримання списку Secret. Правильна рекомендація — зберегти посилення Container, звузити RBAC до мінімального простору імен і ресурсів, та перевірити це перевіркою авторизації, як-от `kubectl auth can-i` для відповідного сервісного акаунта.
Розробник повідомляє, що застосунок може читати хмарне об’єктне сховище, хоча жоден RoleBinding у Kubernetes не надає доступу до сховища. Робоче навантаження працює на групі вузлів із широкою хмарною роллю IAM. Який рівень є ймовірною першопричиною й який засіб контролю рівня Cluster усе одно може допомогти локалізувати це?

Відповідь
Імовірна першопричина — це ідентичність рівня Cloud, бо доступ до об'єктного сховища походить від хмарної ролі IAM, а не від RBAC у Kubernetes. Засіб контролю рівня Cluster усе одно може допомогти, якщо він запобігає тому, щоб Поди дістались до точки доступу метаданих, або обмежує шляхи вихідного трафіку залежно від середовища та мережевого плагіна. Тривале виправлення — звузити хмарний IAM, віддати перевагу обмеженій ідентичності робочого навантаження й переконатися, що Поди не успадковують широкі облікові дані вузла без потреби.
Простір імен має NetworkPolicies з типовою відмовою, жорсткий RBAC і зашифровані Secret, але публічна точка доступу має зламану перевірку авторизації, яка дозволяє одному клієнту читати рахунок іншого клієнта. Через який рівень увійшов інцидент і чому засоби контролю Cluster не вирішують це повністю?

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

Відповідь
Обидва інженери бачать частину картини. Походження образу — це ризик рівня Container, бо воно стосується того, який артефакт дозволено запускати. Політика допуску — це механізм застосування рівня Cluster, бо Kubernetes вирішує, чи прийняти Под. Сильна відповідь фіксує обидва: використовуйте допуск Cluster, щоб застосувати вимоги довіри до образів Container, перш ніж робочі навантаження буде заплановано.
Після сканування вразливостей команда перебудовує свій образ, щоб запатчити критичний пакет. Под усе ще працює привілейованим із hostNetwork: true, а простір імен дозволяє весь вихідний трафік. Що команді виправити наступним і чому пропатченого образу недостатньо?

Відповідь
Пропатчений образ адресує ризик Container чи залежності, але залишкові ризики середовища виконання та Cluster усе одно створюють великий радіус ураження. Команда має прибрати привілейований режим і мережу хоста, якщо немає задокументованого винятку, застосувати безпечніші типові налаштування контексту безпеки та додати засоби контролю NetworkPolicy для вихідного й бічного трафіку. Пропатчений образ зменшує один відомий шлях входу, але слабка ізоляція та відкриті мережеві шляхи роблять майбутні невідомі вади небезпечнішими. Порядок має надати пріоритет локалізації, якщо експлуатація активна, та тривалому посиленню під час подальших дій.
Компанія використовує керований сервіс Kubernetes й припускає, що провайдер за замовчуванням шифрує всі Secret у Kubernetes найбезпечнішим можливим способом. Аудит виявляє резервні копії etcd, що містять читабельні значення Secret. Як вам проаналізувати відповідальність та усунення наслідків?

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

Відповідь
Входом був Code, бо вразлива бібліотека дозволила експлуатацію. Засоби контролю Container були слабкими, бо зловмисник міг записати інструменти у файлову систему, тож слід розглянути файлову систему лише для читання, користувача не-root та зменшені можливості. Засоби контролю Cluster були слабкими, бо сервісний акаунт мав міжпросторовий доступ і вихідний трафік був відкритий, тож RBAC і NetworkPolicy потребують затягування. Засоби контролю Cloud також слід перевірити, бо зовнішня передача даних може стосуватися фаєрвола, NAT, шлюзу вихідного трафіку чи політик хмарного журналювання, які мають виявляти чи обмежувати підозрілий вихідний трафік.

Практична вправа: побудувати карту інциденту 4 С

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

Крок 1: класифікуйте кожну знахідку за рівнем

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

Знахідка	Основний рівень	Причина
Залежність має критичне попередження про віддалене виконання коду.	Code	Вразливий компонент є частиною графа залежностей застосунку й може бути запущений через поведінку застосунку.
Образ працює від імені root зі змінюваною кореневою файловою системою.	Container	Конфігурація середовища виконання збільшує те, що проексплуатований код може змінити всередині контейнера.
Простір імен не має NetworkPolicy.	Cluster	Мережева ізоляція Kubernetes відсутня, тож скомпрометований Под може широко спілкуватися.
Сервісний акаунт може отримувати список Secret у всьому кластері.	Cluster	Межа авторизації API Kubernetes надто дозвільна.
Хмарна роль IAM групи вузлів може читати спільне об’єктне сховище.	Cloud	Інфраструктурна ідентичність може дозволити доступ до даних поза RBAC у Kubernetes.

Крок 2: визначте ймовірний ланцюг атаки

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

Крок 3: оберіть негайні дії локалізації

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

Крок 4: оберіть дії остаточного усунення наслідків

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

Крок 5: перевірте за доказами

Використовуйте реальні перевірки, де ваше середовище це підтримує. Перша команда використовує повну назву kubectl; після цього аліас k означає kubectl. Адаптуйте простір імен, сервісний акаунт і назви файлів до вашого лабораторного кластера, якщо ви практикуєтеся самостійно.

kubectl auth can-i list secrets --as=system:serviceaccount:payments:frontend -A
alias k=kubectl
k get networkpolicy -n payments
k get pod -n payments -o jsonpath='{range .items[*]}{.metadata.name}{" runAsNonRoot="}{.spec.securityContext.runAsNonRoot}{"\n"}{end}'
k describe serviceaccount frontend -n payments

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

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

Один із можливих розв'язків

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

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

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

Модуль 1.2: Безпека хмарного провайдера — Глибоке занурення в рівень Cloud, спільну відповідальність, інфраструктурну ідентичність, мережеві межі та фундамент, якому кожен кластер Kubernetes має довіряти, перш ніж засоби контролю Cluster, Container і Code зможуть виконувати свою роботу.

Джерела

Kubernetes Documentation: Security Overview
Kubernetes Documentation: Pod Security Standards
Kubernetes Documentation: Using RBAC Authorization
Kubernetes Documentation: Network Policies
Kubernetes Documentation: Secrets
Kubernetes Documentation: Encrypting Secret Data at Rest
Kubernetes Documentation: Configure a Security Context
Kubernetes Documentation: Seccomp
Kubernetes Documentation: Good Practices for Kubernetes Secrets
CNCF Cloud Native Security Whitepaper
cloud.google.com: shared responsibility — Сторінка спільної відповідальності GKE явно розділяє відповідальність провайдера за базові компоненти й компоненти площини управління від відповідальності клієнта за робочі навантаження й політику RBAC/IAM.
v1-35.docs.kubernetes.io: network policies — Документація NetworkPolicy у Kubernetes v1.35 зазначає, що NetworkPolicy реалізується мережевим плагіном і не має ефекту без підтримки застосування.
v1-35.docs.kubernetes.io: pod security standards — Сторінка Pod Security Standards v1.35 явно перелічує RuntimeDefault та Localhost як дозволені значення seccomp для політики Restricted.
CNCF Cloud Native Security Whitepaper — Він надає ширший контекст безпеки хмарних технологій за межами примітивів Kubernetes і допомагає сформувати рішення щодо багаторівневого захисту.