AWS Solutions Architect · Урок

Роли IAM для сервисных аккаунтов (IRSA)

Связывайте детально настроенные роли IAM с сервисными аккаунтами Kubernetes с помощью IRSA, чтобы поды могли обращаться к сервисам AWS без разрешений на уровне узлов.

«Роли IAM для сервисных аккаунтов (IRSA)» — бесплатный урок AWS Solutions Architect на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения AWS Solutions Architect, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс AWS Solutions Architect содержит 4 уроков всего.

Проблема IAM для подов

Когда под, работающий в EKS, должен обратиться к API AWS — например, прочитать данные из S3 или записать их в DynamoDB, — ему нужны учетные данные AWS. Наивный подход заключается в создании пользователя IAM и жестком задании его ключей доступа в переменных окружения. Это небезопасно и нарушает принцип минимально необходимых привилегий, поскольку все поды на одном узле используют общие учетные данные. IAM Roles for Service Accounts (IRSA) решает эту проблему, напрямую связывая детально настроенные роли IAM с сервисными аккаунтами Kubernetes.

Как работают роли IAM для сервисных аккаунтов: федерация OIDC

Роли IAM для сервисных аккаунтов работают через федерацию OpenID Connect (OIDC). EKS создает поставщика OIDC для вашего кластера. Когда под ссылается на сервисный аккаунт, аннотированный ARN роли IAM, EKS внедряет в под подписанный спроецированный токен сервисного аккаунта. AWS SDK в поде обменивает этот токен на временные учетные данные AWS с помощью API AssumeRoleWithWebIdentity службы AWS STS — долгосрочные ключи не требуются.

# View the OIDC issuer URL for your cluster
aws eks describe-cluster \
  --name my-cluster \
  --query 'cluster.identity.oidc.issuer' \
  --output text

# Example output:
# https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEIDSTRING

Шаг 1: связать поставщика OIDC

Перед использованием ролей IAM для сервисных аккаунтов необходимо связать издателя OIDC EKS с доверенным поставщиком удостоверений в вашей учетной записи AWS. Это создает ресурс поставщика OIDC IAM, который AWS STS сможет распознавать. Команда eksctl выполняет эту операцию автоматически. После создания поставщика его можно проверить в консоли IAM в разделе Identity Providers.

# Associate the OIDC provider using eksctl (simplest method)
eksctl utils associate-iam-oidc-provider \
  --region us-east-1 \
  --cluster my-cluster \
  --approve

# Verify the provider was created
aws iam list-open-id-connect-providers \
  --query 'OpenIDConnectProviderList[].Arn'

Шаг 2: создать роль IAM

Роль IAM для сервисных аккаунтов должна иметь политику доверия, разрешающую поставщику OIDC принять эту роль, с ограничением для конкретных пространства имен Kubernetes и сервисного аккаунта. В условии используется утверждение sub токена OIDC, которому присваивается значение system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME. Это гарантирует, что роль смогут принять только поды, использующие этот конкретный сервисный аккаунт, а не любой под в кластере.

# Trust policy for the IRSA role (JSON)
# {
#   "Version": "2012-10-17",
#   "Statement": [{
#     "Effect": "Allow",
#     "Principal": {
#       "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEID"
#     },
#     "Action": "sts:AssumeRoleWithWebIdentity",
#     "Condition": {
#       "StringEquals": {
#         "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEID:sub":
#           "system:serviceaccount:production:s3-reader"
#       }
#     }
#   }]
# }

Шаг 3: аннотировать сервисный аккаунт

Создайте Kubernetes ServiceAccount в целевом пространстве имен и добавьте ему аннотацию с ARN роли IAM. Когда под ссылается на этот сервисный аккаунт, EKS автоматически внедряет токен OIDC и две переменные окружения (AWS_WEB_IDENTITY_TOKEN_FILE и AWS_ROLE_ARN). AWS SDK автоматически обнаруживает их и обращается к STS для получения временных учетных данных — вносить изменения в код приложения не требуется.

# Create and annotate the Kubernetes service account
kubectl create serviceaccount s3-reader -n production

kubectl annotate serviceaccount s3-reader \
  -n production \
  eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/S3ReaderRole

# Verify the annotation
kubectl describe serviceaccount s3-reader -n production

Шаг 4: указать сервисный аккаунт в подах

В спецификации пода или развертывания задайте для serviceAccountName имя аннотированного сервисного аккаунта. При планировании пода EKS автоматически подключает токен OIDC по пути /var/run/secrets/eks.amazonaws.com/serviceaccount/token и задает необходимые переменные окружения. Любой вызов AWS SDK внутри пода будет прозрачно использовать учетные данные связанной роли IAM без явной настройки учетных данных.

# Pod spec using IRSA service account
apiVersion: v1
kind: Pod
metadata:
  name: s3-app
  namespace: production
spec:
  serviceAccountName: s3-reader
  containers:
  - name: app
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/my-app:latest
    # AWS SDK auto-detects IRSA — no credential config needed
    # AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN are injected

Роли IAM для сервисных аккаунтов и роль IAM узла: ключевые различия

При использовании роли IAM узла каждый под на узле получает одинаковые разрешения — взломанный под может получить доступ ко всем сервисам AWS, к которым разрешен доступ узлу. При использовании ролей IAM для сервисных аккаунтов каждый под через свой сервисный аккаунт принимает только необходимую ему роль. Это реализует принцип минимально необходимых привилегий на уровне пода и ограничивает масштаб последствий любого инцидента безопасности. AWS рекомендует использовать роли IAM для сервисных аккаунтов вместо ролей на уровне узлов во всех новых развертываниях EKS.

Использование eksctl для создания ролей IAM для сервисных аккаунтов

eksctl может одной командой с использованием create iamserviceaccount создать связь с OIDC, роль IAM, политику доверия и аннотацию ServiceAccount Kubernetes. Это самый простой способ настроить роли IAM для сервисных аккаунтов без ручного написания JSON политики доверия. Вы указываете пространство имен, имя сервисного аккаунта и ARN политики IAM, которую нужно присоединить, а eksctl выполняет все остальные действия.

# Create everything needed for IRSA in one command
eksctl create iamserviceaccount \
  --name s3-reader \
  --namespace production \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve \
  --override-existing-serviceaccounts

Роли IAM для сервисных аккаунтов для дополнений AWS

Для работы многих дополнений и контроллеров EKS требуются роли IAM для сервисных аккаунтов: Cluster Autoscaler должен иметь разрешение на вызов API автоматического масштабирования EC2, AWS Load Balancer Controller — разрешение на создание ресурсов ELB и управление ими, external-dns — доступ на запись в Route 53, а драйвер EBS CSI — разрешение на создание и подключение томов EBS. Всегда используйте роли IAM для сервисных аккаунтов для этих системных компонентов — никогда не предоставляйте такие разрешения на уровне роли IAM узла.

# Create IRSA for the EBS CSI driver
eksctl create iamserviceaccount \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --role-name AmazonEKS_EBS_CSI_DriverRole

Обновление токенов и ротация учетных данных

Токены ролей IAM для сервисных аккаунтов имеют короткий срок действия и автоматически ротируются контроллером проецирования токенов Kubernetes до истечения срока их действия. Аудитория токена по умолчанию — sts.amazonaws.com, а срок действия — 24 часа, но контроллер обновляет токены по истечении 80% их срока действия. Учетные данные AWS STS, полученные через роли IAM для сервисных аккаунтов, также являются временными и обычно действуют 1 час. Благодаря автоматической ротации отпадает необходимость вручную обновлять ключи доступа IAM с длительным сроком действия.

# Inspect the projected service account token inside a pod
kubectl exec -n production s3-app -- \
  cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token

# Decode the JWT header and payload to see expiry and audience
# jwt.io or: base64 -d <<< "PAYLOAD_SECTION"

Аудит использования ролей IAM для сервисных аккаунтов с помощью CloudTrail

Каждый раз, когда под принимает роль IAM через роли IAM для сервисных аккаунтов, AWS CloudTrail записывает событие AssumeRoleWithWebIdentity. Событие содержит ARN принятой роли, субъект токена OIDC (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) и исходный IP-адрес. Это обеспечивает полный журнал аудита: какие поды, к каким сервисам AWS и когда обращались. Такой журнал критически важен для соблюдения нормативных требований и расследования инцидентов в регулируемых средах.

# Search CloudTrail for IRSA calls
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \
  --start-time '2024-01-01T00:00:00Z' \
  --query 'Events[].{Time:EventTime,Role:CloudTrailEvent}' \
  --output table

Быстрая проверка

Проверьте, насколько хорошо Вы усвоили рассмотренные на этом уроке концепции AWS Solutions Architect (SAA-C03).

Итоги урока

На этом уроке Вы узнали, что роли IAM для сервисных аккаунтов используют федерацию OIDC для обмена токенов сервисных аккаунтов Kubernetes на временные учетные данные AWS, политики доверия ролей IAM ограничивают доступ конкретным пространством имен и сервисным аккаунтом, а роли IAM для сервисных аккаунтов обеспечивают минимально необходимые привилегии для каждого пода и значительно превосходят роли IAM на уровне узлов. Далее мы рассмотрим Metrics, Namespaces и Dimensions CloudWatch для наблюдения за ресурсами AWS.

Часто задаваемые вопросы

Урок «Роли IAM для сервисных аккаунтов (IRSA)» бесплатный?

Да — полный текст урока «Роли IAM для сервисных аккаунтов (IRSA)» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс AWS Solutions Architect, подпишись на CoddyKit PRO. Курс AWS Solutions Architect содержит 4 уроков всего.

Чему я научусь в уроке «Роли IAM для сервисных аккаунтов (IRSA)»?

Связывайте детально настроенные роли IAM с сервисными аккаунтами Kubernetes с помощью IRSA, чтобы поды могли обращаться к сервисам AWS без разрешений на уровне узлов. Ты практикуешь AWS Solutions Architect с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать AWS Solutions Architect?

Предыдущий опыт не требуется. AWS Solutions Architect на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.

Сколько времени занимает урок «Роли IAM для сервисных аккаунтов (IRSA)»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке AWS Solutions Architect?

Да. Каждый урок AWS Solutions Architect включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

Плоскость управления и рабочие узлы EKS
Профили Fargate для бессерверных подов
Сеть EKS: VPC CNI и балансировка нагрузки
Роли IAM для сервисных аккаунтов (IRSA)

← Назад к AWS Solutions Architect