Управління доступом до AWS для застосунків, що працюють у Kubernetes, може бути непростим завданням. Ви хочете забезпечити безпеку, але також прагнете спростити процес. Існують два основні підходи до надання дозволів AWS вашим EKS-подам: IAM ролі для облікових записів служб (IRSA) та новий підхід — AWS Pod Identity. Сьогодні ми розглянемо обидва варіанти та пояснимо, чому Pod Identity може стати тим «подихом свіжого повітря», який ви давно очікували.
Класичний підхід: IAM ролі для облікових записів служб (IRSA)
IRSA була основним рішенням протягом тривалого часу. Вона використовує OpenID Connect (OIDC) для встановлення довірчого зв'язку між вашим кластером EKS та AWS IAM. Подумайте про це як про рукостискання між вашим кластером і AWS. Ось спрощена схема:
- Ми налаштовуємо провайдера OIDC в IAM, тим самим вказуючи AWS довіряти вашому кластеру EKS.
- Створюємо обліковий запис служби Kubernetes, який виступає в ролі ідентичності для ваших подів у кластері.
- Потім створюємо роль IAM з політикою довіри, яка вказує: «Цей OIDC провайдер може використовувати мене».
- Нарешті, зв'язуємо обліковий запис служби з роллю IAM.
Коли под, що використовує цей обліковий запис служби, потребує доступу до AWS, AWS SDK автоматично отримує тимчасові облікові дані для відповідної ролі IAM. Це працює, але вимагає чимало налаштувань.
Простий підхід: AWS Pod Identity
Тепер з'являється Pod Identity. Він використовує інший, більш спрощений підхід. Замість того, щоб покладатися на OIDC, він використовує агент, що працює на кожному вузлі вашого кластера EKS. Цей агент виступає як локальний посередник для облікових даних.
Ось спрощена схема:
- Ви безпосередньо асоціюєте роль IAM з обліковим записом служби Kubernetes. Немає потреби в налаштуванні OIDC!
- Коли под потребує облікових даних AWS, агент вступає в гру, визначає відповідну роль IAM на основі інформації про под і надає необхідні тимчасові облікові дані.
Це як мати надійного охоронця, який безпосередньо обробляє запити доступу до AWS.
Попередні умови та обмеження
- Версії кластерів Amazon EKS 1.24 та старіші, а також робочі вузли кластера, які є Linux Amazon EC2 інстансами.
- EKS Pod Identities недоступні для AWS Outposts, Amazon EKS Anywhere та Kubernetes-кластерів, що створюються та працюють на Amazon EC2. Компоненти EKS Pod Identity доступні лише на Amazon EKS.
- Ви не можете використовувати EKS Pod Identities для подів, що працюють на чому завгодно, окрім Linux Amazon EC2 інстансів. Лінукс та Windows поди, що працюють на AWS Fargate, не підтримуються. Поди, що працюють на Windows Amazon EC2 інстансах, не підтримуються.
Міграція від IRSA до Pod Identity
Крок 1: Встановіть Pod Identity, як описано в посібнику.
Крок 2: Змініть політику довіри ролі IAM, як вказано нижче, щоб зміна видалила URL провайдера OIDC з політики довіри. Політика ролі IAM залишатиметься без змін.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
Крок 3: Оновіть існуючий обліковий запис служби, видаливши анотацію IAM ролі з облікового запису служби вашої служби.
Крок 4: Тепер створіть pod-identity-association з обліковим записом служби, як описано в посібнику тут.
Крок 5: Оновіть це для всіх облікових записів служби вашого робочого навантаження після перевірки з одним з облікових записів служби. Ви повинні мати змогу отримати доступ до сервісів AWS з пода.
Чому Pod Identity може стати вашим новим найкращим другом
Ось де Pod Identity дійсно блищить:
- Спрощена конфігурація: Налаштування OIDC може бути досить складним. Pod Identity повністю усуває це, значно спрощуючи процес налаштування. Це як перейти від збору меблів IKEA до покупки вже зібраних меблів.
- Незалежне управління: З Pod Identity управління IAM та EKS може здійснюватися більш незалежно.
Ваша команда IAM може керувати ролями, не торкаючись вашого кластера EKS, і навпаки. Це величезна перевага для організацій, де ці напрямки обробляються окремими командами. Можна вважати це чітким розподілом обов'язків. - Більша повторна використаність: Ви можете використовувати один і той самий IAM принципал у кількох кластерах EKS, що спрощує управління IAM по всій інфраструктурі. Це особливо корисно, якщо у вас багато кластерів EKS. Більше не потрібно дублювати конфігурації!
Хто отримує найбільшу вигоду?
Pod Identity особливо корисна для:
- Організацій з окремими командами IAM та EKS: Вона спрощує співпрацю та зменшує залежності.
- Організацій, які керують кількома кластерами EKS: Це спрощує управління IAM на великому масштабі.
- Кожного, хто шукає простіший варіант IRSA: Це пропонує більш простий та менш складний підхід.
Підсумок
І IRSA, і Pod Identity є дієвими рішеннями для надання дозволів AWS вашим подам EKS. Однак Pod Identity пропонує переконливу альтернативу завдяки спрощеній конфігурації, незалежному управлінню та покращеній повторній використаності. Якщо ви шукаєте чистіший та більш впорядкований підхід, Pod Identity однозначно варто розглянути. Це може стати рішенням, яке зробить ваше життя (і вашу інфраструктуру) трохи легшим.
Посилання:
https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html
Перекладено з: Simplifying AWS Access for Your EKS Pods: Pod Identity vs. IRSA