Модуль 10.2: Хмарне управління та Політика як код

Складність: [COMPLEX] | Час на виконання: 2.5 год | Передумови: Корпоративні Landing Zones (Модуль 10.1), основи Kubernetes RBAC

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

У вересні 2022 року компанія з онлайн-торгівлі пережила витік даних 2.3 мільйона клієнтів. Причина була банальною: розробник створив бакет S3 з публічним доступом для картинок товарів, а потім випадково завантажив туди дамп бази даних. У компанії була активна SCP (Service Control Policy), яка мала забороняти публічні бакети, але вона була написана півтора року тому і не враховувала нові API-виклики Amazon. Водночас у кластері EKS взагалі не було контролю: сервіси типу LoadBalancer вільно створювали публічні балансувальники, а паролі до баз даних просто записувалися відкритим текстом у змінні оточення подів.

Розслідування показало класичну проблему: команда хмарного управління та команда Kubernetes працювали в ізоляції. Одні не знали про існування Kyverno, інші — про SCP. Не було єдиного розуміння, які правила діють і чи ми їм відповідаємо. Витік коштував компанії $4.2 мільйона штрафів та втрату довіри клієнтів.

Policy as Code (Політика як код) вирішує це, ставлячись до правил управління так само, як до коду додатків: версіонування, тестування, код-рев’ю та автоматичне виконання.

У цьому модулі ви навчитеся будувати “піраміду політик” — від хмарних SCP та Azure Policy до внутрішніх правил Kubernetes (Kyverno, OPA Gatekeeper). Ви навчитеся створювати єдину систему управління, яка закриває дірки між хмарою та кластером, і навчитеся керувати винятками, не створюючи дірок у безпеці.

Піраміда політик

Управління в корпоративній хмарі — це не один шар, а цілий пиріг. Кожен шар ловить те, що пропустив попередній.

Identity & Access (IAM): Хто може тиснути кнопки?
Cloud Provider Policies (SCP / Azure Policy): Які кнопки в принципі можна тиснути в цьому акаунті? (напр. заборона публічних бакетів).
IaC Validation (Checkov / tfsec): Чи правильний код інфраструктури МИ написали, перш ніж його запустити?
K8s Admission Control (Kyverno / OPA): Чи можна деплоїти цей YAML-файл у Kubernetes? (напр. заборона контейнерів від root).
Runtime Detection (Falco): Чи не робить працюючий контейнер чогось підозрілого прямо зараз? (напр. запуск шелла всередині бази даних).

Політики хмарних провайдерів

AWS Service Control Policies (SCPs)

Це “стеля” дозволів. Навіть якщо адмін акаунта дав собі всі права, SCP може їх обмежити. Критично для K8s: SCP може заборонити створення кластерів EKS із публічним доступом до API.

Azure Policy

На відміну від AWS, Azure вміє не тільки забороняти (Deny), а й:

Audit: просто попередити.
DeployIfNotExists: автоматично встановити агент моніторингу на кожен новий кластер.
Modify: автоматично додати тег “команда” до кожного ресурсу.

Kubernetes Policy Engines: Kyverno vs OPA Gatekeeper

Хмарні політики зупиняються на порозі кластера. Все, що всередині — територія спеціальних рушіїв.

Характеристика	Kyverno	OPA Gatekeeper
Мова	Чистий YAML	Rego (складна мова запитів)
Мутація	Легко додає default ліміти	Складно
Генерація	Створює ресурси (напр. NetworkPolicy)	Не вміє
Поріг входу	Низький (якщо знаєте K8s)	Високий

Порада: Для 90% компаній Kyverno є кращим вибором через простоту та можливість автоматично виправляти помилки розробників (mutation).

Управління винятками (Exceptions)

Найбільша помилка управління — вимкнути політику повністю, бо “одній команді вона заважає”. Правильний шлях — PolicyException у коді:

Кому дозволено?
Яке правило можна порушити?
Коли закінчується термін дії? (автоматичне видалення винятку через 30 днів).

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

Помилка	Чому це стається	Як виправити
Ізоляція команд	Хмарна та K8s команди не спілкуються	Створіть спільну раду з архітектури та єдиний реєстр політик
Тільки режим аудиту	Страх “щось поламати”	Встановіть термін: 30 днів аудиту, потім — жорстка заборона (`Enforce`)
Відсутність лімітів у K8s	SCP не бачить споживання CPU подів	Використовуйте Kyverno, щоб кожен под мав `resources.limits`
Винятки назавжди	”Тимчасово дозволили і забули”	Кожен виняток має мати дату експірації в метаданих

Тест

1. Чи може SCP в AWS заборонити поду Kubernetes у кластері EKS видаляти файли з S3?

Так, але не прямо. SCP обмежує IAM-роль, яку використовує под. Якщо SCP забороняє дію s3:DeleteObject, под не зможе її виконати, які б права не були прописані в його ServiceAccount.

2. У чому перевага мутаційних (mutation) політик Kyverno?

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

Практична вправа: Єдиний контроль

Встановіть Kyverno у свій кластер.
Напишіть політику, яка забороняє використовувати тег :latest для образів контейнерів.
Напишіть мутаційну політику, яка автоматично додає мітку managed-by: platform до кожного Deployment.
Створіть виняток (PolicyException) для одного конкретного пода, якому ТАКИ ПОТРІБЕН тег latest для тестів.
Згенеруйте звіт про відповідність (PolicyReport) і подивіться, які ресурси в кластері вже порушують правила.

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

Ви навчилися впроваджувати правила, тепер час пов’язати їх із міжнародними стандартами. Переходьте до Модуля 10.3: Безперервний комплаєнс та CSPM — ми навчимося автоматично збирати докази для аудиторів SOC2/HIPAA та інтегрувати Trivy та Falco в єдиний дашборд безпеки.