Модуль 5.3: Ідентифікація в EKS: IRSA vs Pod Identity
Складність: [QUICK] | Час на виконання: 1.5 год | Передумови: Модуль 5.1 (Архітектура та Control Plane EKS)
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»У 2022 році медична SaaS-компанія, що працювала на EKS, виявила, що кожен под у їхньому кластері мав повний доступ до бакетів S3 з історіями хвороб пацієнтів. Причина була болісно простою: розробники приєднали IAM-роль із правами s3:* до самих серверів (вузлів) кластера. Оскільки дані метаданих EC2 доступні всім подам на вузлі, будь-який под — навіть сторонній агент логування — міг читати та видаляти конфіденційні дані. Це виявили під час аудиту, а на виправлення (переписування прав для 60 мікросервісів) пішло три місяці.
Це проблема “радіусу ураження на рівні вузла”. Без по-подової ідентифікації кожен под отримує всі права, які є у сервера. Рішення — надати кожному поду свою власну ідентичність AWS, щоб він мав доступ тільки до того, що йому реально потрібно.
EKS пропонує два способи зробити це: IRSA (IAM Roles for Service Accounts), що працює з 2019 року, та EKS Pod Identity — новий, набагато простіший спосіб, запущений наприкінці 2023-го. У цьому модулі ви зрозумієте, як працюють обидві системи, коли яку обирати та як легко перейти на новий стандарт. Ви також навчитеся читати помилки STS, які часто збивають з пантелику навіть досвідчених адмінів.
Проблема: IAM на рівні вузла — це небезпечно
Розділ «Проблема: IAM на рівні вузла — це небезпечно»Коли ви даєте права серверу (Node), ці права стають спільними для всіх мешканців цього сервера.
- Pod A (сайт): не потребує доступу до хмари.
- Pod B (база): потребує доступу до S3.
- РЕЗУЛЬТАТ: Якщо зловмисник зламає Pod A, він отримає доступ до S3 через права вузла.
По-подова ідентифікація прибирає цей ризик: кожен под отримує свій власний тимчасовий ключ.
IRSA: Старий стандарт (OIDC)
Розділ «IRSA: Старий стандарт (OIDC)»IRSA базується на довірі між вашим кластером та AWS через протокол OIDC.
Як це працює:
- Ви створюєте OIDC-провайдера для свого кластера в IAM.
- Створюєте IAM-роль, яка каже: “Я довіряю ServiceAccount
my-app”. - Додаєте анотацію
eks.amazonaws.com/role-arnу Kubernetes. - При запуску под отримує файл-жетон (JWT), який обмінює на справжні ключі AWS.
Мінуси IRSA: Треба керувати OIDC для кожного кластера, складні “Trust Policies”, які важко копіювати між середовищами.
EKS Pod Identity: Сучасний підхід
Розділ «EKS Pod Identity: Сучасний підхід»Це нове рішення від AWS, яке працює набагато простіше. Замість складних налаштувань OIDC, ви використовуєте спеціальний агент на кожному вузлі.
Чому Pod Identity кращий:
- Ніяких OIDC: не треба створювати провайдери в IAM.
- Універсальні ролі: одну й ту саму роль можна використовувати в десяти різних кластерах без зміни її налаштувань.
- Керування через API: ви просто кажете AWS: “зв’яжи цю роль із цим ServiceAccount у цьому кластері”.
- Все в CloudTrail: кожна видача ключа чітко логується.
Що обрати?
Розділ «Що обрати?»| Функція | IRSA | EKS Pod Identity |
|---|---|---|
| Складність | Висока | Низька |
| Для кого | K8s < 1.24 або Fargate | Рекомендовано для всього іншого |
| Швидкість | Залежить від лімітів STS | Швидше (кешування на вузлі) |
| Fargate | Так | Ні (поки що) |
Типові помилки
Розділ «Типові помилки»| Помилка | Чому це стається | Як виправити |
|---|---|---|
| Права на рівні Node Role | ”Бо так швидше працює” | Залишайте на Node Role тільки мінімум (ECR, Logs, EBS). Решту — тільки подам |
Забутий sts:TagSession | Нова вимога для Pod Identity | Завжди додавайте sts:TagSession у Trust Policy вашої ролі для Pod Identity |
| Старий AWS SDK у коді | Програма не знає про новий метод | Оновіть бібліотеки (напр. Boto3 1.34+ для Python), щоб вони бачили креденшали Pod Identity |
| Відсутність агента | Pod Identity не працює без Add-on | Встановіть EKS Add-on eks-pod-identity-agent на всі вузли |
Тест
Розділ «Тест»1. Чому Pod Identity не працює на AWS Fargate?
Тому що Pod Identity потребує спеціального агента (DaemonSet), який працює на кожному вузлі. У Fargate немає “вузлів”, якими ви могли б керувати, тому там досі потрібно використовувати IRSA.
2. Що станеться, якщо я видалю 'Pod Identity Association' в AWS CLI для працюючого додатка?
Поди, що вже працюють, будуть мати доступ до закінчення терміну дії їхнього поточного ключа (зазвичай до 1 години). Але наступний запит на оновлення ключа видасть помилку, і додаток втратить доступ до хмари.
Практична вправа: Міграція на Pod Identity
Розділ «Практична вправа: Міграція на Pod Identity»- Встановіть агент:
aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent. - Оновіть IAM-роль: змініть Trust Policy, щоб вона довіряла сервісу
pods.eks.amazonaws.comі дозволяла діїsts:AssumeRoleтаsts:TagSession. - Створіть зв’язок:
aws eks create-pod-identity-association --cluster-name my-cluster --namespace default --service-account my-sa --role-arn .... - Видаліть анотацію IRSA з вашого ServiceAccount і переконайтеся, що под все ще має доступ до S3.
Наступний модуль
Розділ «Наступний модуль»Ви налаштували ідентичність, тепер час подумати про дані. Переходьте до Модуля 5.4: Сховища та управління даними в EKS, щоб опанувати EBS, EFS та підключення S3 як файлової системи для ваших подів.