Модуль 4.5: Моделювання загроз і теорія ланцюжка постачання

Складність: [СЕРЕДНЯ] — основа безпекового мислення

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

Передумови: Модуль 4.1: Поверхні атаки, Модуль 4.4: Загрози ланцюжка постачання

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

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

1. Спроєктувати модель загроз Kubernetes, яка зіставляє активи, потоки даних, точки входу, межі довіри та сценарії зловживання на всіх рівнях 4C.
2. Оцінити межі довіри ланцюжка постачання та вирішити, де підписи, атестації, SBOM, політики допуску та засоби контролю під час виконання дають корисну перевірку.
3. Порівняти категорії STRIDE з прикладами Kubernetes, щоб не моделювати лише ті загрози, які вже знайомі вашій команді.
4. Розставити пріоритети для пом’якшень за відповідальним, впливом і залишковим ризиком замість того, щоб створювати довгий перелік контролів, який ніхто не може впровадити.
5. Діагностувати слабкий дизайн безпеки ланцюжка постачання, визначивши, яка межа відмовила і які докази довели б, що артефакту можна довіряти.

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

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

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

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

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

Спосіб мислення під час моделювання загроз

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

Слабка модель загроз починається з інструментів. Вона каже: «Ми використовуємо Trivy, Kyverno та Falco, тож маємо безпеку ланцюжка постачання». Сильніша модель загроз починається з історії того, як програмне забезпечення стає робочим навантаженням. Вона запитує, хто може змінити сирцевий код, хто може змінити збирання, хто може опублікувати образ, хто може схвалити Деплоймент і хто може спостерігати за робочим навантаженням після допуску.

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

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

+-------------------------------------------------------------+
|                 THREAT MODELING WORKFLOW                    |
+-------------------------------------------------------------+
|                                                             |
|  1. IDENTIFY ASSETS                                         |
|     What would hurt if it were stolen, changed, or lost?    |
|     Examples: secrets, customer data, images, source code.  |
|                                                             |
|  2. MAP DATA FLOWS                                          |
|     How do code, credentials, artifacts, and requests move? |
|     Examples: commit -> CI -> registry -> admission -> pod. |
|                                                             |
|  3. MARK TRUST BOUNDARIES                                   |
|     Where does responsibility or security context change?   |
|     Examples: developer laptop to repo, registry to cluster.|
|                                                             |
|  4. MODEL ABUSE CASES                                       |
|     How could an attacker misuse a normal path?             |
|     Examples: poisoned dependency, stolen CI token, tag swap.|
|                                                             |
|  5. ASSIGN MITIGATIONS                                      |
|     Which control reduces which risk, and who owns it?      |
|     Examples: signed images, SBOMs, RBAC, NetworkPolicies.  |
|                                                             |
+-------------------------------------------------------------+

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

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

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

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

Модель 4C для загроз Kubernetes

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

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

+------------------------------------------------------------------+
|                          THE 4C MODEL                            |
+------------------------------------------------------------------+
|                                                                  |
|  +------------------------------------------------------------+  |
|  | CLOUD                                                      |  |
|  | IAM, networks, managed Kubernetes settings, storage, DNS.  |  |
|  | A cloud role with broad permissions can turn one pod       |  |
|  | compromise into account-wide damage.                       |  |
|  |                                                            |  |
|  |  +------------------------------------------------------+  |  |
|  |  | CLUSTER                                              |  |  |
|  |  | API server, etcd, RBAC, admission, audit, kubelets.   |  |  |
|  |  | A permissive ClusterRole can make a small foothold    |  |  |
|  |  | become a platform-wide control problem.               |  |  |
|  |  |                                                      |  |  |
|  |  |  +------------------------------------------------+  |  |  |
|  |  |  | CONTAINER                                      |  |  |  |
|  |  |  | Image contents, runtime settings, capabilities, |  |  |  |
|  |  |  | seccomp, AppArmor, read-only filesystems.       |  |  |  |
|  |  |  |                                                |  |  |  |
|  |  |  |  +------------------------------------------+  |  |  |  |
|  |  |  |  | CODE                                     |  |  |  |  |
|  |  |  |  | Source, dependencies, build scripts,      |  |  |  |  |
|  |  |  |  | package managers, and application logic.  |  |  |  |  |
|  |  |  |  +------------------------------------------+  |  |  |  |
|  |  |  +------------------------------------------------+  |  |  |
|  |  +------------------------------------------------------+  |  |
|  +------------------------------------------------------------+  |
|                                                                  |
|  Key idea: a trusted Kubernetes deployment can still run          |
|  untrusted code if the supply chain admitted bad inputs earlier.  |
|                                                                  |
+------------------------------------------------------------------+

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

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

Рівень 4C	Приклад відмови ланцюжка постачання	Що має запитати модель загроз
Code	Акаунт супровідника залежності скомпрометовано, і він публікує шкідливий пакет.	Чи залежності закріплені, переглянуті, скановані та обмежені довіреними реєстрами?
Container	Тег базового образу перезаписано після того, як прикладна команда його схвалила.	Чи на образи посилаються за дайджестом і чи перевіряють їх перед допуском?
Cluster	Вебхук допуску довіряє будь-якому образу, підписаному ключем CI, навіть із незахищених гілок.	Чи перевіряє допуск походження, гілку, ідентичність збирача та контекст політики?
Cloud	Под досягає сервісу метаданих інстансу й отримує широкі хмарні облікові дані.	Чи обмежені ідентичності робочого навантаження і чи обмежений або прихований доступ до метаданих?

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

Завдання для активного навчання: Команда блокує привілейовані контейнери, вимагає некореневих користувачів і використовує кореневі файлові системи лише для читання. Її CI-конвеєр усе ще збирає неперевірені зміни робочих процесів із pull request’ів. Який рівень 4C має найслабше припущення і як ця слабкість могла б обійти посилення контейнера?

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

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

STRIDE у застосуванні до Kubernetes

STRIDE — це фреймворк моделювання загроз, який допомагає командам не зосереджуватися лише на атаках, які вони вже знають. Категорії — це Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service і Elevation of Privilege (підміна, підробка, заперечення, розкриття інформації, відмова в обслуговуванні та підвищення привілеїв). Цінність не в тому, щоб запам’ятати слова. Цінність у тому, щоб використовувати кожну категорію як підказку, що змушує поставити інший тип безпекового запитання.

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

Категорія STRIDE	Запитання Kubernetes	Сценарій ланцюжка постачання	Корисні докази або контроль
Spoofing	Чи могло б щось видавати себе за довіреного користувача, ноду, сервіс або артефакт?	Зловмисник публікує corp-logging у публічному реєстрі пакетів, і збирання підтягує його замість внутрішнього пакета.	Обмеження реєстру, цілісність lock-файлу, приватні репозиторії пакетів і перегляд залежностей.
Tampering	Чи міг би зловмисник змінити дані, конфігурацію або артефакти непомітно?	Робочий процес CI змінює образ після проходження тестів, але до підписання.	Захищені робочі процеси, ізольовані збирачі, відтворювані збірки, атестації походження та перегляд коду.
Repudiation	Чи міг би хтось заперечити внесення зміни через відсутність доказів?	Продакшн-образ існує в реєстрі, але ніхто не може довести, який коміт чи робочий процес його створив.	Підписане походження, незмінні логи, події аудиту та логи прозорості.
Information Disclosure	Чи могли б чутливі дані витекти звичайними або випадковими шляхами?	SBOM розкриває внутрішні назви пакетів, або скомпрометований Под читає змонтовані сервісні облікові дані.	Мінімізація секретів, RBAC, редагування логів, обережна публікація SBOM і обмежені за обсягом токени.
Denial of Service	Чи могла б залежність, образ або робоче навантаження вичерпати спільні ресурси?	Шкідливий пакет запускає інтенсивну роботу процесора під час старту на сотнях реплік.	Запити та ліміти ресурсів, контроль розгортань, сканування залежностей і захисні бар’єри допуску.
Elevation of Privilege	Чи міг би низькопривілейований компонент отримати більше повноважень, ніж задумано?	Підписаний образ працює із сервісним акаунтом, який може переглядати Secret у різних просторах імен.	RBAC з найменшими привілеями, межі простору імен, Pod Security Standards та обмеження ідентичності робочого навантаження.

Поширена помилка початківця — перетворити STRIDE на вправу зі словника. Запитувати «Що означає T?» — це перевірка пам’яті, а не безпекового мислення. Корисна вправа STRIDE запитує: «Цей шлях збирання дозволяє учаснику змінити робочий процес і опублікувати образ; які категорії STRIDE застосовні, які докази виявили б проблему і яке пом’якшення закриває найважливіший пробіл?»

Категорії STRIDE можуть перекриватися, і це прийнятно. Скомпрометований CI-токен може включати Spoofing, бо зловмисник діє як CI-система, Tampering, бо образ змінено, Repudiation, бо логи можуть не ідентифікувати дійову особу, та Elevation of Privilege, бо образ досягає потужної ідентичності виконання. Мета не в тому, щоб помістити кожен інцидент в одну ідеальну коробку. Мета в тому, щоб модель ставила достатньо різних запитань.

В оглядах Kubernetes STRIDE працює найкраще, коли кожну категорію пов’язано з межею довіри. Spoofing на межі «розробник — сирцевий код» може включати викрадені облікові дані чи непідписані коміти, тоді як Spoofing на межі «реєстр — кластер» може включати реєстр-двійник або шлях недовіреного репозиторію. Tampering у Git відрізняється від Tampering у реєстрі образів, і ці відмінності визначають, чи найкращим пом’якшенням є CODEOWNERS, незмінні теги, закріплення за дайджестом чи перевірка під час допуску.

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

Межі довіри ланцюжка постачання

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

У ланцюжку постачання Kubernetes межі з’являються ще до того, як кластер щось побачить. Ноутбук розробника, репозиторій сирцевого коду, CI-система, збирач, реєстр пакетів, реєстр образів, контролер допуску та середовище виконання — усі вони мають різних власників і різні безпекові припущення. Зріла модель загроз називає ці припущення замість того, щоб ховати їх усередині узагальненої коробки «CI/CD».

+--------------------------------------------------------------------------------+
|                         SUPPLY CHAIN TRUST BOUNDARIES                          |
+--------------------------------------------------------------------------------+
|                                                                                |
|  Developer        Source Repo          Build System          Image Registry     |
|      |                 |                    |                      |            |
|      | Boundary 1      | Boundary 2         | Boundary 3           |            |
|      v                 v                    v                      v            |
|  Commit push ---> Pull request ---> Build and sign image ---> Store artifact    |
|                                                                                |
|  Boundary 1: Developer -> Source Repo                                          |
|    Risk: stolen credentials, compromised workstation, unreviewed source.        |
|    Control: MFA, signed commits, branch protection, required review.           |
|    Evidence: commit signature, review record, protected branch settings.       |
|                                                                                |
|  Boundary 2: Source Repo -> Build System                                       |
|    Risk: malicious workflow, dependency confusion, unsafe build context.        |
|    Control: protected workflow files, pinned dependencies, isolated builders.  |
|    Evidence: provenance showing source commit, builder identity, parameters.   |
|                                                                                |
|  Boundary 3: Build System -> Image Registry                                    |
|    Risk: tag overwrite, image tampering, stolen push credential.               |
|    Control: immutable tags, digest references, image signing, short tokens.    |
|    Evidence: signature, registry audit log, immutable digest, transparency log.|
|                                                                                |
|  Image Registry       Admission Control       Runtime                          |
|        |                    |                    |                              |
|        | Boundary 4         | Boundary 5         |                              |
|        v                    v                    v                              |
|  Image pull -----> Policy decision -----> Running workload                      |
|                                                                                |
|  Boundary 4: Registry -> Cluster                                               |
|    Risk: cluster pulls the wrong image, an old image, or an unsigned image.     |
|    Control: allowed registries, signature verification, SBOM requirements.     |
|    Evidence: admission decision, digest, attestation, vulnerability status.     |
|                                                                                |
|  Boundary 5: Admission -> Runtime                                              |
|    Risk: accepted workload behaves maliciously or receives excessive access.   |
|    Control: NetworkPolicy, RBAC, seccomp, AppArmor, runtime detection.         |
|    Evidence: audit logs, Falco alerts, network telemetry, service account use. |
|                                                                                |
+--------------------------------------------------------------------------------+

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

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

Межа	Слабке припущення	Сильніше запитання	Приклад пом’якшення
Розробник до Source	«Коміт у Git, тож він легітимний.»	Чи можемо довести дійову особу і вимагати перегляд для чутливих шляхів?	MFA, підписані коміти, CODEOWNERS, захищені гілки.
Source до Build	«CI відпрацював, тож збирання заслуговує на довіру.»	Чи можемо довести робочий процес, коміт, збирач та вхідні залежності?	Походження у стилі SLSA, закріплені дії, ізольовані збирачі.
Build до Registry	«Назва тега правильна.»	Чи можемо довести, що цей дайджест — схвалений артефакт?	Незмінні теги, закріплення за дайджестом, підписання, логи аудиту реєстру.
Registry до Cluster	«Воно прийшло з нашого реєстру.»	Чи задовольняє артефакт політику для цього простору імен і робочого навантаження?	Перевірки допуску на підписи, атестації, SBOM і CVE.
Admission до Runtime	«Воно пройшло допуск, тож воно безпечне назавжди.»	Які обмеження зменшують радіус ураження, якщо артефакт шкідливий?	NetworkPolicy, RBAC з найменшими привілеями, моніторинг під час виконання, Pod Security Standards.

Розв’язаний приклад: Команда розгортає payments-api:stable із приватного реєстру. Образ підписаний, але реєстр дозволяє перезапис тега, а допуск перевіряє лише те, що тег вказує на підписаний образ. Зловмисник із викраденими обліковими даними реєстру публікує шкідливий образ під тим самим тегом після схвалення. Перевірка підпису все одно проходить, якщо зловмисник може підписувати або якщо реєстр приймає раніше підписаний артефакт під тим самим тегом.

Виправлення — це не «використовувати більше сканування» як перший крок. Відмова межі — це Build-to-Registry і Registry-to-Cluster, тож команда має використовувати незмінні теги, розгортати за дайджестом, обмежити дозволи на push до реєстру, аудитувати записи в реєстр і змусити допуск перевіряти дайджест і політику походження. Засоби контролю під час виконання все ще мають значення, але вони зменшують радіус ураження після того, як неправильний артефакт уже перетнув межу.

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

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

Походження, SBOM та атестації

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

SBOM, або Software Bill of Materials (специфікація складу програмного забезпечення), відповідає на інше запитання: що міститься всередині артефакту? Він перелічує пакети, версії й часто транзитивні залежності. Походження та SBOM доповнюють одне одного. Походження каже, як артефакт було зроблено; SBOM каже, які інгредієнти він містить. Жоден із них сам по собі не доводить, що робоче навантаження нешкідливе, але обидва покращують якість безпекових рішень.

Атестація — це підписане твердження про артефакт. Наприклад, атестація могла б стверджувати, що дайджест образу sha256:... було зібрано з конкретного коміту конкретним робочим процесом CI або що сканування вразливостей завершилося без критичних знахідок. Політика допуску може потім оцінити це підписане твердження замість того, щоб довіряти змінному ярлику, людському коментарю в релізному тікеті чи тегу, який міг змінитися.

+-------------------------------------------------------------------+
|                         PROVENANCE CHAIN                          |
+-------------------------------------------------------------------+
|                                                                   |
|  Weak claim:                                                      |
|    "This image is named registry.example.com/payments:prod."       |
|                                                                   |
|  Stronger claim:                                                  |
|    "This exact digest was built by the protected release workflow  |
|     from commit abc123 on the main branch using an isolated        |
|     builder, and the statement was signed by the CI identity."     |
|                                                                   |
|  Provenance evidence answers:                                     |
|    WHO built it?        CI identity or builder service account.    |
|    WHAT source?         Repository URL, branch, commit SHA.        |
|    HOW was it built?    Workflow, build command, builder image.    |
|    WHEN was it built?   Timestamp and build run identifier.        |
|    WHERE was it built?  Trusted builder, runner, or build service. |
|    WHY trust it?        Signature, policy match, immutable log.    |
|                                                                   |
|  SBOM evidence adds:                                              |
|    WHAT is inside?      Packages, versions, licenses, dependencies.|
|                                                                   |
+-------------------------------------------------------------------+

Суть сеньйорного рівня в тому, що докази мають бути релевантними політиці. Підписана атестація, яка каже «CI зібрав цей образ», може бути надто слабкою, якщо будь-яка гілка може запустити ту саму ідентичність CI. Сильніша політика могла б вимагати захищеного релізного робочого процесу, гілки main, переглянутого коміту, схваленого збирача та відсутності критичних вразливостей із доступними виправленнями. Модель загроз має визначати, які твердження мають значення для рівня ризику робочого навантаження.

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

Тип доказу	На яке запитання відповідає	Що сам по собі не доводить
Підпис образу	Чи було цей дайджест підписано довіреною ідентичністю?	Що сирцевий код переглянуто, безпечний або зібраний зі схваленої гілки.
Атестація походження	Який сирцевий код, робочий процес і збирач виробили цей артефакт?	Що залежності вільні від вразливостей чи шкідливої поведінки.
SBOM	Які пакети та версії присутні в артефакті?	Що поведінка пакета безпечна або що збирання не було підроблено.
Сканування вразливостей	Чи присутні відомі вразливості за базою сканера?	Що невідомі вразливості чи шкідлива логіка відсутні.
Лог аудиту реєстру	Хто публікував, видаляв чи змінював теги артефактів?	Що сам вміст артефакту заслуговує на довіру.

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

Для міркувань рівня KCSA зосередьтеся на твердженні та межі. Якщо межа — Registry-to-Cluster, релевантними можуть бути підпис образу й атестація походження. Якщо межа — Admission-to-Runtime, важливішими стають RBAC, NetworkPolicy, seccomp та логи аудиту. Якщо межа — Source-to-Build, захищені робочі процеси, закріплення залежностей та ізольовані збирачі можуть мати більше значення, ніж налаштування об’єкта Kubernetes.

Бар’єри політики на межі кластера

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

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

+--------------------------------------------------------------------+
|                         POLICY GATE MODEL                          |
+--------------------------------------------------------------------+
|                                                                    |
|  Pod creation request                                              |
|          |                                                         |
|          v                                                         |
|  +-------------------+    fail -> image is not from an allowed      |
|  | Registry policy   |            registry or required repository   |
|  +---------+---------+                                             |
|            | pass                                                   |
|            v                                                       |
|  +-------------------+    fail -> image reference is mutable or      |
|  | Digest policy     |            digest does not match approval     |
|  +---------+---------+                                             |
|            | pass                                                   |
|            v                                                       |
|  +-------------------+    fail -> digest lacks trusted signature     |
|  | Signature policy  |            from an accepted identity          |
|  +---------+---------+                                             |
|            | pass                                                   |
|            v                                                       |
|  +-------------------+    fail -> provenance does not match source,  |
|  | Attestation check |            branch, workflow, or builder       |
|  +---------+---------+                                             |
|            | pass                                                   |
|            v                                                       |
|  +-------------------+    fail -> critical vulnerability, missing    |
|  | SBOM and scan     |            SBOM, or stale scan evidence       |
|  +---------+---------+                                             |
|            | pass                                                   |
|            v                                                       |
|  +-------------------+    fail -> privileged pod, broad identity,    |
|  | Runtime hardening |            missing seccomp, unsafe volume     |
|  +---------+---------+                                             |
|            | pass                                                   |
|            v                                                       |
|      Pod admitted                                                  |
|                                                                    |
+--------------------------------------------------------------------+

Інструменти, такі як Kyverno, OPA Gatekeeper, Ratify, Connaisseur та компоненти, пов’язані із Sigstore, можуть реалізувати частини цієї моделі. KCSA не вимагає глибокої роботи з конкретними вендорами, але очікує, що ви розумієте патерн контролю. Кластер отримує запит, оцінює докази та політику і або відхиляє робоче навантаження, або дозволяє йому працювати за визначених обмежень.

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

Ось невеликий запускний приклад, що показує тип властивості Пода, яку рушій політики міг би відхилити. Ця команда створює локальний файл маніфесту і використовує клієнтську перевірку kubectl для підтвердження того, що YAML структурно валідний. У реальному кластері Kubernetes 1.35+ контролер допуску вирішував би, чи прийнятні політика образу, контекст безпеки та правила простору імен.

cat > unsafe-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: unsigned-mutable-image
  namespace: default
spec:
  containers:
    - name: app
      image: docker.io/library/nginx:latest
      securityContext:
        runAsUser: 0
        allowPrivilegeEscalation: true
EOF

kubectl apply --dry-run=client -f unsafe-pod.yaml

Після того як kubectl було представлено, приклади KubeDojo часто використовують псевдонім k для швидкості. Якщо ви використовуєте його локально, визначте його явно командою alias k=kubectl перед запуском команд. Псевдонім не змінює поведінку Kubernetes; він лише скорочує введення команд під час практики та робить приклади легшими для перегляду.

alias k=kubectl
k apply --dry-run=client -f unsafe-pod.yaml

Орієнтована на політику модель загроз не сказала б просто «відхилити цей Под, бо він поганий». Вона пояснила б, що latest — це змінний тег, що docker.io/library може не бути схваленим реєстром для продакшну, що runAsUser: 0 означає запуск процесу від root, а allowPrivilegeEscalation: true збільшує вплив, якщо образ скомпрометовано. Це пояснення пов’язує політику з ризиком, що робить політику захищуваною, коли вона блокує Деплоймент.

Бар’єр політики	Зменшена загроза	Приклад причини відхилення	Відповідальний
Дозволені реєстри	Підтягування артефактів із недовірених джерел	Образ має походити з registry.example.com/prod.	Платформа
Вимога дайджесту	Перезапис тега або випадковий дрейф	Робоче навантаження має посилатися на дайджест @sha256: для продакшну.	Платформа
Перевірка підпису	Непідписаний або підроблений артефакт	Дайджест образу не має підпису від довіреної релізної ідентичності.	Безпека
Перевірка походження	Збирання з неправильної гілки чи робочого процесу	Атестація не показує захищений релізний робочий процес.	Безпека і Платформа
Вимога SBOM	Невідомі залежності у продакшні	Для цього дайджесту образу немає атестації SBOM.	Безпека
Посилення під час виконання	Збільшений радіус ураження після компрометації	Под має працювати від некореневого користувача й забороняти підвищення привілеїв.	Платформа

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

Розв’язаний приклад: моделювання платіжного сервісу

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

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

+--------------------------------------------------------------------------------+
|                         PAYMENT SERVICE THREAT MODEL                           |
+--------------------------------------------------------------------------------+
|                                                                                |
|  Business assets:                                                              |
|    Payment tokens, customer identifiers, transaction logs, refund workflow.     |
|                                                                                |
|  Platform assets:                                                              |
|    Kubernetes service account, namespace policies, database Secret, API key.    |
|                                                                                |
|  Supply chain assets:                                                          |
|    Source repository, CI workflow, build runner, signing identity, registry.    |
|                                                                                |
|  Delivery flow:                                                                |
|                                                                                |
|    Developer -> Pull Request -> Protected Branch -> CI Build -> Registry        |
|         |             |                 |              |             |          |
|         |             |                 |              |             v          |
|         |             |                 |              |        Admission       |
|         |             |                 |              |             |          |
|         |             |                 |              |             v          |
|         +-------------+-----------------+--------------+------> Running Pod     |
|                                                                    |           |
|                                                                    v           |
|                    User -> Ingress -> payment-api -> PostgreSQL -> Processor   |
|                                                                                |
|  Key trust boundaries:                                                         |
|    1. Developer identity to source repository.                                  |
|    2. Source repository to build system.                                        |
|    3. Build system to registry and signing service.                             |
|    4. Registry to admission controller.                                         |
|    5. Admitted pod to database, network, and cloud identity.                    |
|                                                                                |
+--------------------------------------------------------------------------------+

Тепер застосуйте STRIDE для створення сценаріїв зловживання. Для Tampering зловмисник змінює крок збирання, щоб додати двійковий файл для викрадення облікових даних до підписання образу. Для Spoofing зловмисник публікує пакет, що виглядає як внутрішній допоміжний пакет для платежів. Для Information Disclosure програма логує токени платіжного процесора під час обробки помилок. Для Elevation of Privilege Под використовує сервісний акаунт, який може читати Secret в інших просторах імен.

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

Сценарій зловживання	Категорія STRIDE	Межа	Краще пом’якшення
Зловмисник змінює робочий процес CI, щоб додати бекдор до підписання образу.	Tampering і Repudiation	Source до Build	Захищені файли робочих процесів, обов’язковий перегляд, ізольований збирач, перевірка походження.
Публічний пакет затіняє внутрішній пакет під час збирання.	Spoofing і Tampering	Source до Build	Обмеження реєстру, lock-файли, перегляд залежностей, приватний репозиторій пакетів.
Тег реєстру перезаписано після схвалення релізу.	Tampering	Build до Registry	Незмінні теги, розгортання за дайджестом, логи аудиту реєстру, перевірки дайджесту при допуску.
Под читає Secret бази даних і надсилає його на зовнішню кінцеву точку.	Information Disclosure	Admission до Runtime	Монтування секретів із найменшими привілеями, NetworkPolicy для вихідного трафіку, виявлення під час виконання.
Скомпрометований сервісний акаунт програми переглядає Secret у різних просторах імен.	Elevation of Privilege	Runtime до Cluster API	RBAC, обмежений простором імен, окремі сервісні акаунти, сповіщення аудиту.
Шкідлива залежність змушує кожну репліку споживати процесор.	Denial of Service	Code до Runtime	Ліміти ресурсів, стратегія розгортання, сканування залежностей, канаркове розгортання.

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

Загроза	Пом’якшення	Відповідальний	Залишковий ризик
Підробка робочого процесу до підписання	Вимагати перегляд файлів робочих процесів і перевіряти захищене релізне походження при допуску.	Платформа	Компрометація CI-провайдера залишається можливою і переглядається під час оцінки ризику вендора.
Сплутування залежностей	Використовувати обмеження реєстру, lock-файли та приватні простори імен пакетів для внутрішніх пакетів.	Прикладна	Шкідливе оновлення від легітимного супровідника все ще можливе.
Перезапис тега	Розгортати за дайджестом і ввімкнути незмінні теги для релізних репозиторіїв.	Платформа	Процес аварійного відкату все одно має уникати змінних скорочень.
Витік секретів зі скомпрометованого Пода	Обмежити монтування секретів, застосувати NetworkPolicy для вихідного трафіку та сповіщати про незвичні призначення DNS чи HTTP.	Платформа і Безпека	Схвалений вихідний трафік до платіжного процесора все одно можна зловжити без виявлення на рівні програми.
Надмірно широкий сервісний акаунт	Прив’язувати лише необхідні дієслова та ресурси в просторі імен.	Платформа	Нові функції можуть потребувати перегляду, щоб уникнути розповзання дозволів.
Критична вразливість у базовому образі	Сканувати в CI та вимагати свіжий доказ сканування перед допуском.	Безпека	Невідомі вразливості потребують процесу виправлення та обмежень під час виконання.

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

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

Побудова практичної моделі загроз

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

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

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

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

Крок моделювання	Результат	Перевірка якості
Визначити обсяг моделі	Робоче навантаження, простір імен, конвеєр, реєстр, ідентичності та зовнішні залежності.	Чи зміг би інший інженер сказати, що включено й виключено?
Визначити активи	Дані, облікові дані, артефакти, сирцевий код, визначення збирання, політики, логи.	Чи включає перелік активи ланцюжка постачання, а не лише дані під час виконання?
Зіставити потоки	Шлях коміту, шлях збирання, шлях розгортання, шлях запиту, шлях секрету.	Чи позначено межі довіри там, де змінюється власність або безпековий контекст?
Створити сценарії зловживання	Сценарії на основі STRIDE, прив’язані до меж і активів.	Чи зрозумів би рецензент, як зловмисник досягає успіху?
Обрати пом’якшення	Контролі, відповідальні, докази, стан розгортання та залишковий ризик.	Чи зіставляється кожен головний контроль із конкретною загрозою?
Тригери перегляду	Події, що вимагають оновлення моделі.	Чи спрацював би перегляд через новий реєстр, CI-систему чи чутливу функцію?

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

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

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

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

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

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

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

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

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

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

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

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

Загроза	Рівень 4C	Пом’якшення	Відповідальний
Скомпрометований вебхук допуску мутує робочі навантаження у небезпечні форми.	Cluster	Ізолювати простір імен вебхука, використовувати mTLS, обмежити RBAC, аудитувати зміни та надавати перевагу поведінці fail-closed для критичної політики.	Платформа
Отруєння реєстру чи перезапис тега змінює довірений образ програми.	Code і Container	Використовувати незмінні теги, посилання за дайджестом, підписання образів, логи аудиту реєстру та перевірку дайджесту при допуску.	Платформа і Безпека
Втеча з ноди чи контейнера розширює скомпрометований образ до доступу до хоста.	Container	Забезпечити Pod Security Standards, seccomp, AppArmor, скинуті можливості, некореневих користувачів і кореневі файлові системи лише для читання.	Платформа
Викрадений kubeconfig дає зловмиснику прямий доступ до API-сервера.	Cluster	Використовувати короткоживучі облікові дані, вхід через OIDC, MFA, RBAC із найменшими привілеями та сповіщення аудиту про незвичні дієслова.	Безпека
Шкідлива залежність потрапляє під час збирання і працює всередині схваленого образу.	Code	Використовувати lock-файли, приватні реєстри, перегляд залежностей, генерацію SBOM та допуск, що враховує походження.	Прикладна і Безпека
Крадіжка облікових даних CI/CD дозволяє зловмиснику збирати чи публікувати артефакти.	Code і Cluster	Використовувати ефемерні збирачі, федерацію OIDC, короткоживучі токени, захищені робочі процеси та обмежені за обсягом дозволи реєстру.	Платформа
Витік даних etcd розкриває Secret і конфігурацію Kubernetes.	Cluster	Увімкнути шифрування у спокої, обмежити доступ до etcd, вимагати mTLS та обмежити мережеву відкритість площини управління.	Платформа
Зловживання сервісом хмарних метаданих перетворює компрометацію Пода на доступ до хмарного акаунта.	Cloud	Використовувати ідентичність робочого навантаження, приховування метаданих або обмеження IMDS, вузькі ролі IAM та контролі вихідного трафіку.	Хмара і Платформа
Надмірно широкий сервісний акаунт дозволяє скомпрометованому Поду читати непов’язані ресурси.	Cluster	Прив’язувати мінімальні дієслова та ресурси, розділяти сервісні акаунти за робочим навантаженням і аудитувати розповзання привілеїв.	Платформа
Відсутність аудиторського сліду заважає реконструкції інциденту після підозрілого Деплойменту.	Cluster і Code	Зберігати логи аудиту API, логи CI, логи реєстру, підписане походження та історію розгортань.	Безпека

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

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

Чи знали ви?

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

• SLSA зосереджується на цілісності збирання: фреймворк допомагає командам міркувати про стійкість до підробки, походження та довіру до платформи збирання, що є центральними запитаннями, коли політика допуску залежить від доказів про артефакт.

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

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

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

Помилка	Чому вона трапляється	Як її виправити
Моделювання лише запущеного кластера й ігнорування CI/CD	Платформні команди часто бачать об’єкти Kubernetes чіткіше, ніж системи контролю версій, робочих процесів, реєстру та підписання.	Включіть до моделі сирцевий код, робочий процес, збирач, реєстр, підписання, допуск і виконання.
Трактування підписаних образів як автоматично безпечних	Підпис відчувається повною відповіддю, особливо коли команди не розрізняють ідентичність і політику.	Перевіряйте твердження про походження, такі як гілка, робочий процес, ідентичність збирача та статус захищеного релізу.
Розгортання змінних тегів у продакшні	Теги зручні для людей та інструментів розгортання, тож команди забувають, що назви можуть зміщуватися.	Розгортайте за дайджестом і використовуйте незмінні релізні теги там, де теги все ще потрібні людям.
Написання сценаріїв зловживання без відповідальних	Воркшопи можуть видавати хороші сценарії, не пов’язуючи їх із командами, що можуть змінювати системи.	Призначте кожне пом’якшення команді й зафіксуйте, чи воно заплановане, забезпечується примусово чи прийняте як залишковий ризик.
Плутання сканування вразливостей із виявленням шкідливого ПЗ	Багато шкідливих змін не мають відомих CVE і не будуть вловлені базами вразливостей пакетів.	Поєднуйте сканування з переглядом, походженням, обмеженнями поведінки та моніторингом під час виконання.
Забування про залишковий ризик	Команди можуть вважати систему безпечною, бо контролі існують, навіть коли важливі прогалини лишаються.	Документуйте прийняті ризики, тригери перегляду, компенсувальні контролі та відповідальних за рішення.
Використання STRIDE як контрольного списку для запам’ятовування	Учні можуть називати категорії, все ще не помічаючи, як зловмисник зловживає реальною межею.	Перетворіть кожну категорію STRIDE на сценарій, прив’язаний до активу, межі та об’єкта Kubernetes.
Залишення політик допуску в постійному режимі аудиту	Політика лише для аудиту фіксує порушення, але не зупиняє запуск небезпечних робочих навантажень.	Використовуйте режим аудиту для міграції, потім забезпечуйте примус у продакшн-просторах імен, щойно команди матимуть чіткий шлях до відповідності.

Тест

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

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

2. Ваша команда розгорнула сервіс, використовуючи `registry.example.com/orders:stable`. Під час інциденту дайджест за `stable` відрізняється від дайджесту, записаного в релізному тікеті. Яка межа довіри відмовила і що б ви змінили перед наступним розгортанням?

Межа Build-to-Registry або Registry-to-Cluster відмовила, бо змінний тег дозволив посиланню на артефакт дрейфувати після перегляду. Перед наступним розгортанням вимагайте, щоб продакшн-навантаження посилалися на образи за дайджестом, увімкніть незмінні теги для релізних репозиторіїв, обмежте дозволи на push і змусьте допуск перевіряти, що запитаний дайджест відповідає політиці та доказам походження. Саме лише сканування не виправляє проблему ідентичності, бо неправильний артефакт усе одно може бути сканований і допущений.

3. Ваша команда розгорнула оновлення логувального сайдкара, і Поди в кількох просторах імен починають надсилати DNS-запити на невідомий зовнішній домен. Образ пройшов сканування вразливостей і прийшов зі схваленого реєстру. Які частини моделі загроз допомагають вам відреагувати?

Почніть з меж Code і Registry-to-Cluster, потім перейдіть до радіуса ураження під час виконання. Перевірте походження для образу сайдкара, нещодавні зміни залежностей, логи аудиту реєстру та докази допуску. Потім огляньте контролі під час виконання: NetworkPolicy для вихідного трафіку, дозволи сервісного акаунта, логи DNS та події Falco чи аудиту. Сценарій показує, чому схваленого реєстру та сканування вразливостей недостатньо; шкідлива поведінка може не мати відомого CVE і все одно потребувати мережевих обмежень і виявлення під час виконання.

4. Ваша команда розгорнула новий робочий процес CI, що збирає образи для pull request'ів і продакшн-релізів. Учасник може змінити файл робочого процесу в тому самому pull request, що запускає збирання. Які категорії STRIDE застосовні і яке пом'якшення ви б визначили пріоритетним?

Tampering застосовне, бо робочий процес можна змінити, щоб змінити збирання. Repudiation застосовне, якщо отриманому артефакту бракує надійних доказів про робочий процес і дійову особу. Elevation of Privilege може застосовуватися, якщо робочий процес може отримати доступ до облікових даних підписання чи реєстру. Пріоритизуйте захист файлів робочих процесів обов’язковим переглядом чи CODEOWNERS, відокремлення збирань pull request від релізного підписання, використання короткоживучих обмежених за обсягом облікових даних і перевірку походження при допуску.

5. Ваша команда розгорнула програму з вузьким контекстом безпеки контейнера, але сервісний акаунт Пода може переглядати й читати Secret у кожному просторі імен. Згодом в образі виявляють шкідливу залежність. Що має сказати модель загроз про радіус ураження?

Посилення контейнера зменшує деякі ризики рівня хоста, але надмірно широкий сервісний акаунт створює радіус ураження рівня Cluster. Модель має зафіксувати, що компрометація рівня Code може використати ідентичність Kubernetes Пода, щоб розкрити Secret у різних просторах імен. Негайне виправлення — це RBAC із найменшими привілеями зі специфічним для робочого навантаження сервісним акаунтом, а також сповіщення аудиту про незвичний доступ до Secret. Посилення під час виконання та перевірка ланцюжка постачання лишаються корисними, але вони не компенсують широкі дозволи API.

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

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

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

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

8. Ваша команда розгорнула платіжний сервіс, що може досягати сервісу хмарних метаданих зі своєї мережі Пода. Образ програми підписаний, сканований і зібраний із захищених гілок. Чому модель загроз усе ще неповна і який рівень потребує уваги?

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

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

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

Сценарій: Застосунок має три сервіси: frontend, написаний на TypeScript, api, написаний на Go, і worker, написаний на Python. Команда використовує GitHub Actions для CI/CD, збирає образи спільним збирачем, публікує образи у приватний реєстр ECR і розгортає в кластер EKS, використовуючи GitOps. Застосунок зберігає дані профілю клієнта в PostgreSQL і викликає зовнішнього платіжного провайдера.

Крок 1: Визначте обсяг та активи

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

Приклади активів можуть включати дані профілю клієнта, токени API платіжного провайдера, облікові дані PostgreSQL, файли робочих процесів GitHub Actions, ідентичність збирача, ідентичність підписання образів, дайджести образів ECR, маніфести репозиторію GitOps, сервісні акаунти Kubernetes та логи аудиту. Мета — включити шлях, що створює робоче навантаження, а не лише робоче навантаження після його запуску.

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

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

Орієнтир для розв'язання Кроку 1

Сильна відповідь називає простір імен shop, репозиторій GitHub, робочі процеси GitHub Actions, спільний збирач, репозиторій ECR, репозиторій GitOps, кластер EKS, базу даних PostgreSQL і вихідний трафік до платіжного провайдера. Вона включає активи, такі як дані профілю клієнта, платіжні токени, облікові дані бази даних, визначення робочих процесів, ідентичність збирача, ідентичність підписання образів, дайджести образів, сервісні акаунти Kubernetes, NetworkPolicies та логи аудиту. Вона також зазначає, що поза обсягом, наприклад, непов’язані простори імен чи непродакшн-середовища попереднього перегляду, щоб перегляд мав чітку межу.

Крок 2: Зіставте потоки даних та артефактів

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

Ваш потік має включати робочу станцію розробника, репозиторій сирцевого коду, pull request, робочий процес CI, збирач, реєстр пакетів, реєстр образів, репозиторій GitOps, допуск Kubernetes, запущені Поди, базу даних і платіжного провайдера. Ви можете спростити назви, але не згортайте весь шлях доставки в одну коробку «CI/CD».

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

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

Орієнтир для розв'язання Кроку 2

Розумний потік — це Developer -> Pull Request -> Protected Branch -> GitHub Actions -> Shared Runner -> Package Registry -> ECR -> GitOps Repository -> Kubernetes Admission -> Running Pods, з окремим шляхом запиту User -> Ingress -> Frontend -> API -> PostgreSQL і Payment Provider. Хороші примітки до меж згадують ідентичність розробника до репозиторію, репозиторій до робочого процесу, робочий процес до збирача, збирач до реєстру, реєстр до GitOps, GitOps до допуску та допущений Под до бази даних чи зовнішнього вихідного трафіку. Точний формат діаграми має менше значення, ніж те, чи видимі зміни довіри.

Крок 3: Створіть сценарії зловживання STRIDE

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

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

Сценарій зловживання	STRIDE	Межа	Вплив	Кандидатний контроль
Учасник змінює релізний робочий процес, щоб впровадити бекдор до підписання.	Tampering	Source до Build	Підписаний шкідливий образ досягає продакшну.	Захищені робочі процеси, обов’язковий перегляд, допуск за походженням.

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

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

Орієнтир для розв'язання Кроку 3

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

Крок 4: Побудуйте таблицю пом’якшень і власності

Перетворіть ваші сценарії зловживання на таблицю впровадження. Включіть відповідального, поточний статус, докази перевірки та залишковий ризик. Використовуйте реалістичні статуси, такі як Enforced, Audit, Planned чи Accepted.

Використайте цей контрольний список, щоб переконатися, що таблиця може спонукати до інженерної роботи, а не стати переліком контролів, якими ніхто не володіє.

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

Орієнтир для розв'язання Кроку 4

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

Крок 5: Перегляньте модель як рецензент з безпеки

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

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

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

Орієнтир для розв'язання Кроку 5

Сильний перегляд міг би визначити Source-to-Build як найслабшу межу, якщо файли робочих процесів можуть бути змінені тим самим pull request, що запускає збирання, або Registry-to-Cluster, якщо продакшн усе ще розгортає змінні теги. Головне пом’якшення має бути виправдане тим, де воно перериває шлях зловмисника, а не популярністю інструмента. Відповідь має розрізняти докази допуску, такі як дайджест, підпис, походження та SBOM, і контролі радіуса ураження під час виконання, такі як RBAC, NetworkPolicy, seccomp, ліміти ресурсів та обмеження хмарного IAM.

Джерела

• Документація Kubernetes: огляд хмарної безпеки
• Документація Kubernetes: Pod Security Standards
• Документація Kubernetes: динамічний контроль допуску
• Документація Kubernetes: авторизація RBAC
• Документація Kubernetes: мережеві політики
• Документація Kubernetes: Seccomp
• Документація Kubernetes: шифрування даних Secret у спокої
• Специфікація SLSA
• Документація Sigstore
• Документація OpenSSF Scorecard
• Документ CNCF про безпеку ланцюжка постачання ПЗ
• cisa.gov: aa20 352a — Це реальний історичний інцидент із названим продуктом, датою, ураженими секторами та механізмом доставки.
• training.linuxfoundation.org: kubernetes and cloud native security associate kcsa — Це названа заявка щодо обсягу програми/іспиту, і сторінка іспиту Linux Foundation перелічує ці домени безпосередньо.
• kubernetes.io: overview — Це названа заявка щодо безпекового фреймворку, і офіційна документація Kubernetes явно зазначає 4C.
• learn.microsoft.com: threat modeling tool threats — Це названий фреймворк моделювання загроз із канонічним розширенням категорій.
• tag-security.cncf.io: sscbpv2 — Документ CNCF визначає походження та пояснює перевірку метаданих походження за політикою.
• Хмарна безпека та Kubernetes — Офіційні настанови Kubernetes щодо меж довіри, контролів ланцюжка постачання та рівнів безпеки під час виконання.

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

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