Модуль 7.3: Workload Identity та безпека в AKS

Складність: [QUICK] | Час на виконання: 1.5 год | Передумови: Модуль 7.1 (Архітектура AKS)

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

У січні 2023 року медична SaaS-компанія виявила, що пароль до їхньої бази даних Azure SQL зберігався у звичайному секреті Kubernetes (base64-кодування, не шифрування) понад два роки. Пароль потрапив туди під час нічної міграції і про нього просто забули. Коли молодший інженер випадково скинув вивід kubectl get secrets -o yaml у публічний Slack-канал під час дебагу, автоматичний бот знайшов пароль за 18 хвилин. Хакери встигли викрасти 340 000 записів пацієнтів до того, як витік помітили. Штрафи та витрати на суди склали понад $8 мільйонів.

Ця історія дуже поширена. Секрети Kubernetes — це не шифрування, а лише кодування. Будь-хто з доступом до неймспейсу може їх прочитати. Справжнє рішення — взагалі не тримати паролі в Kubernetes. Azure пропонує архітектуру “без паролів” через три сервіси: Entra Workload Identity (дає поду ідентичність без пароля), Secrets Store CSI Driver (вставляє паролі з Key Vault прямо в пам’ять подів) та Microsoft Defender for Containers (стежить за підозрілою поведінкою).

У цьому модулі ви навчитеся повністю відмовлятися від статичних паролів. Ви зрозумієте шлях від застарілого Pod Identity до сучасного Workload Identity, навчитеся підключати Azure Key Vault до ваших подів та налаштуєте Azure Policy, щоб жоден розробник не міг випадково запустити небезпечний под у вашому кластері.

Від Pod Identity до Workload Identity

Раніше Azure використовував систему Pod Identity (v1), яка перехоплювала мережеві запити подів. Це було складно і часто ламалося. Entra Workload Identity (v2) — це сучасний стандарт, побудований на базі протоколу OIDC.

Ніхто нікого не перехоплює: Довіра налаштовується один раз між вашим кластером та Azure.
Жодних паролів: Под отримує цифровий жетон (token) від Kubernetes, а Azure обмінює його на свій ключ.
Безпека: Доступ прив’язаний до конкретного неймспейсу та ServiceAccount.

Secrets Store CSI Driver + Azure Key Vault

Це найкращий спосіб передати секрети в додаток.

Як це працює:

Ви кладете пароль у Azure Key Vault (хмарний сейф).
Створюєте SecretProviderClass у Kubernetes, де вказуєте, які паролі вам потрібні.
Коли под запускається, спеціальний драйвер сам заходить у Key Vault, бере пароль і кладе його як файл у пам’ять пода (/mnt/secrets/db-pass).
Як тільки под вмирає — файл зникає. У Kubernetes Secret нічого не зберігається.

Azure Policy: Правила гри

У великому кластері ви не можете перевіряти кожен YAML-файл вручну. Azure Policy робить це за вас автоматично.

Що варто заборонити відразу:

Запуск контейнерів від імені root.
Використання привілейованих контейнерів (які можуть зламати вузол).
Використання образів не з вашого приватного реєстру ACR.
Створення балансувальників із публічними IP без дозволу.

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

Помилка	Чому це стається	Як виправити
Паролі в base64 секретах	”Так звичніше працювати”	Використовуйте CSI Driver + Key Vault для реальних секретів
Забута мітка `use: true`	Webhook не бачить ServiceAccount	Для Workload Identity обов’язково додайте мітку `azure.workload.identity/use: "true"`
Права Admin для Key Vault	Спроба уникнути помилок доступу	Надавайте роль `Key Vault Secrets User` — вона дозволяє тільки читати, а не видаляти
Deny-policy без тестування	”Хочу бути в безпеці негайно”	Спочатку вмикайте політику в режимі `Audit`, перевірте, що вона нічого не зламала, а потім — у `Deny`

Тест

1. Що таке 'Federated Credential' і навіщо він потрібен?

Це “довіреність”, яку ви створюєте в Azure. Вона каже: “Я довіряю цьому конкретному кластеру Kubernetes. Якщо прийде под із неймспейсу prod із паспортом my-app — дай йому доступ до моїх ресурсів”. Це прибирає потребу в секретних паролях для додатків.

2. Чим Azure Policy кращий за ручну перевірку маніфестів?

Azure Policy працює на рівні API-сервера (Admission Control). Він фізично не дозволить створити ресурс, який порушує правила, навіть якщо розробник спробує це зробити через kubectl або Helm.

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

Увімкніть Workload Identity на вашому кластері.
Створіть Managed Identity в Azure та надайте їй доступ до Key Vault.
Налаштуйте зв’язок (Federated Credential) між вашим ServiceAccount та цією ідентичністю.
Розгорніть под із CSI драйвером.
Перевірте, що секрет з’явився у файлі /mnt/secrets/api-key всередині контейнера.
Спробуйте видалити цей файл вручну — подивіться, що станеться.

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

Переходьте до Модуля 7.4: Сховища, спостережуваність та масштабування в AKS — ви навчитеся обирати між Azure Disks та Azure Files, налаштовувати глибокий моніторинг через Container Insights та опануєте автомасшабування KEDA.