IAM User vs IAM Role — в чём разница?

Trust policy роли

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "vendor-tenant-42" }
      }
    }
  ]
}

Ключевое различие

IAM User — постоянная identity для человека или legacy-системы; у неё могут быть console password и access key/secret access key, которые живут до ротации. IAM Role — identity без собственных долгоживущих credentials; её принимает доверенный principal через sts:AssumeRole и получает временные ключи (AccessKeyId, SecretAccessKey, SessionToken) со сроком жизни 15 минут — 12 часов.

Когда что использовать

• Workload в AWS (EC2, Lambda, ECS task, EKS pod через IRSA) — только role, ключи на инстансе не хранить.
• Люди — IAM Identity Center (SSO) + федерация поверх ролей, не пароли IAM users.
• Cross-account доступ — role с trust policy в целевом аккаунте + sts:AssumeRole у вызывающего.
• Сторонний вендор — role с sts:ExternalId в Condition, чтобы избежать confused deputy.

Принятие роли через CLI

aws sts assume-role \
  --role-arn arn:aws:iam::444455556666:role/DeployRole \
  --role-session-name ci-build-123 \
  --duration-seconds 3600 \
  --external-id vendor-tenant-42

Подводные камни

• Long-lived access keys у IAM user часто утекают в git/CI; AWS не умеет их инвалидировать автоматически без ротации.
• В trust policy с "AWS": "arn:aws:iam::ACCOUNT:root" разрешается принять роль любому principal в том аккаунте, у которого есть sts:AssumeRole.
• Без ExternalId для вендора возможна confused-deputy атака.
• Permissions у session ограничены пересечением permissions роли и optional session policy в assume-role --policy.
• Session не наследует MFA автоматически — для требования MFA нужен Condition: aws:MultiFactorAuthPresent = true.
• Role chaining ограничивает duration максимум 1 час, даже если у роли MaxSessionDuration больше.

• Использовать IAM users для EC2 или Lambda workloads.
• Путать trust policy и permissions policy роли.
• Хранить long-lived access keys в коде.

• Отличает permanent credentials от temporary STS credentials.
• Понимает assume role и trust relationship.
• Выбирает roles для AWS workloads.