Чем IAM-пользователь отличается от IAM-роли и когда стоит использовать роль вместо постоянных ключей доступа?

Короткий ответ

Пользователь — постоянная идентичность с долгоживущими учётными данными, привязанная к человеку или сервису; роль — набор разрешений, который можно временно «принять» (assume), получив краткоживущие токены без хранения постоянных секретов. Роль предпочтительнее везде, где это возможно.

Как это работает подробнее

при назначении политики пользователю разрешения привязаны к его постоянным учётным данным; при assume role выдаются временные токены (обычно на 15 минут — несколько часов), которые автоматически истекают.

Пример кода

example.txtКопировать

# Плохо: статичный ключ в переменных окружения
export AWS_ACCESS_KEY_ID=AKIA...EXAMPLE
export AWS_SECRET_ACCESS_KEY=example-secret
# Хорошо: роль присвоена инстансу, временные креды берутся автоматически
aws sts get-caller-identity
# Arn: arn:aws:sts::111122223333:assumed-role/app-role/i-0abcd1234

Что использовать на практике

• Рекомендация. для людей используют SSO/федерацию с временными ролями вместо постоянных IAM-пользователей; для приложений на виртуальных машинах/контейнерах — привязку роли к инстансу/сервис-аккаунту, а не хранение ключей в коде или переменных окружения.
• Проверка. get-caller-identity должен показывать assumed-role, а не IAM user, а токены должны обновляться автоматически без участия приложения.

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

• Риск. создавать IAM-пользователя с долгоживущим ключом для сервиса, который мог бы использовать роль инстанса
• Риск. хранить ключи доступа в репозитории или конфиге
• Риск. не ротировать постоянные ключи годами.