Модуль 4.3: Інтеграція хмарного IAM для Kubernetes

Складність: [MEDIUM] | Час на виконання: 2.5 год | Передумови: Модуль 4.1 (Керований vs Власний Kubernetes)

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

У січні 2023 року розробник медичного стартапу мав надати поду Kubernetes доступ до S3-бакета з історіями хвороб. Він пішов найшвидшим шляхом: створив IAM-користувача, згенерував секретний ключ, вставив його в Kubernetes Secret і підключив до пода. Це зайняло 5 хвилин. Але через тиждень цей ключ випадково потрапив у публічний репозиторій GitHub у файлі налаштувань Helm. Зловмисники вкрали його за лічені хвилини. Оскільки у користувача були права адміна (щоб “точно працювало”), хакери викрали дані 340 000 пацієнтів. Компанія отримала штраф у $4.8 мільйона.

Проблема була не в “неуважності”. Проблема була в архітектурі: передача статичних паролів — це завжди ризик. Хмарна інтеграція IAM вирішує це назавжди. Замість паролів ви передаєте ідентичність. Под каже хмарі: “Я — обробник платежів”, а хмара відповідає: “Я вірю тобі, ось тимчасовий ключ на 15 хвилин”.

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

Проблема: Статичні ключі в кластері

Коли ви кладете AWS_ACCESS_KEY_ID у Kubernetes Secret:

Він лежить у базі etcd у нешифрованому вигляді (за замовчуванням).
Він ніколи не закінчується.
Його важко ротувати (треба перезапускати поди).
Якщо один под зламали — ключ працює з будь-якої точки світу.

Рішення: Федерація ідентичності (OIDC)

Сучасний підхід базується на довірі між Kubernetes та хмарним провайдером через протокол OIDC.

Як це працює (крок за кроком):

Pod запускається зі спеціальним ServiceAccount.
Kubernetes видає поду тимчасовий цифровий жетон (JWT токен).
Под показує цей жетон хмарному сервісу STS (Security Token Service).
Хмара перевіряє підпис жетона (чи справді його видав ваш кластер).
Якщо все ок, хмара дає поду тимчасові креденшали (діють 15-60 хв).

Результат: Жодних паролів у кластері. Жодних паролів у Git. Автоматична ротація кожні 15 хвилин.

Реалізація у різних хмарах

AWS: IRSA (IAM Roles for Service Accounts)

Ви створюєте IAM-роль і в її “Trust Policy” пишете: “я довіряю ServiceAccount my-app у неймспейсі prod”. Потім просто додаєте одну анотацію в Kubernetes:

annotations:
  eks.amazonaws.com/role-arn: arn:aws:iam::12345678:role/my-role

Google Cloud: Workload Identity

Найпростіша реалізація. Ви просто “зв’язуєте” сервісний акаунт Google із сервісним акаунтом Kubernetes однією командою CLI.

Azure: Workload Identity

Використовує Managed Identities. Ви створюєте “Federated Credential”, який пов’язує ідентичність Azure із токеном вашого кластера.

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

Помилка	Чому це стається	Як виправити
Використання Default SA	Поди використовують його за замовчуванням	Завжди створюйте окремий ServiceAccount для кожного додатка
Права `FullAccess`	”Щоб не розбиратися з помилками”	Надавайте доступ тільки до конкретного бакета або таблиці
Одна роль на весь кластер	Зручно один раз налаштувати	Кожен додаток має мати свою роль (Blast Radius isolation)
Забута анотація	Код видає помилку “No credentials found”	Перевірте, чи правильно вказано ARN ролі в анотації ServiceAccount

Тест

1. Чому тимчасові креденшали OIDC безпечніші за звичайні Access Keys?

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

2. Що таке 'Confused Deputy' (заплутаний заступник) у контексті IAM?

Це ситуація, коли сервіс із високими правами (напр. CI/CD) виконує дії за запитом менш привілейованого користувача, не перевіряючи, чи має той користувач право на цю дію. По-подова ідентифікація (IRSA) вирішує це, бо хмара перевіряє права саме того пода, який робить запит.

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

Створіть IAM-роль у вашій хмарі з доступом “тільки читання” до одного S3/GCS бакета.
Налаштуйте довіру (Trust Relationship) між вашим кластером та цією роллю.
Створіть ServiceAccount у Kubernetes з необхідною анотацією.
Запустіть под із цим ServiceAccount.
Зайдіть у под (kubectl exec) і спробуйте виконати aws s3 ls або gcloud storage ls. Переконайтеся, що ви бачите файли, не вводячи жодних паролів.

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

Переходьте до Модуля 4.4: Cloud-Native мережі та топології VPC — ви навчитеся проєктувати мережі для Kubernetes так, щоб у вас ніколи не закінчувалися IP-адреси і трафік між кластерами був захищеним.