PassRole в AWS: как дать EC2 доступ к приватному S3

PassRole — это разрешение IAM, которое позволяет пользователю передать роль сервису AWS (например, EC2) для временного доступа к ресурсам. В этой статье подробно показано, как создать роль с правами только для чтения S3, как дать пользователю право передавать эту роль, как прикрепить роль к запущенному экземпляру EC2 и как протестировать конфигурацию. Также приведены чеклисты, сценарии тестирования и рекомендации по безопасности.

Введение в IAM и роли

IAM — это сервис управления доступом в облаке. Он отвечает за аутентификацию (кто вы) и авторизацию (что вам разрешено). Основные сущности IAM: пользователи, группы и роли. Роль — это «объект» с набором прав, который не привязан к конкретному человеку: её могут принимать (assume) пользователи, сервисы или приложения, получая при этом временные учётные данные.

Определения в одну строку

• Роль — временные права, которыми могут воспользоваться сервисы или сущности.
• PassRole — разрешение передавать роль сервису при настройке ресурса.

Что мы рассмотрим

• Что такое iam:PassRole и зачем оно нужно
• Пошаговая настройка роли EC2S3Access и доверительной политики
• Создание политики для IAM пользователя с правом PassRole
• Прикрепление роли к запущенному EC2-экземпляру
• Тестирование и проверка поведения доступа
• Практические рекомендации по безопасности и контроль доступа

Зачем нужен PassRole

Когда вы создаёте или настраиваете AWS-сервис (например, EC2, Lambda, ECS), часто нужно указать роль, которую сервис будет использовать. Сервис будет «принимать» эту роль и действовать от её имени. Разрешение iam:PassRole контролирует, кто из пользователей может указать такую роль при создании или изменении ресурса. Без этого права пользователь может создавать ресурсы, но не сможет привязать к ним определённую роль.

Важно

• PassRole не даёт права использовать роль напрямую — оно даёт право передать роль сервису.
• Контролируйте ресурс (ARN роли) в разрешении iam:PassRole, чтобы пользователь мог передавать только конкретные роли.

Когда PassRole полезен и когда может подвести

Полезно

• При выдаче минимально необходимых прав: администратор разрешает разработчику запускать EC2 с ролью, которая даёт доступ только к S3.
• Когда инфраструктура создаётся через консоль или IaC и требуется безопасность на уровне «кто может передать роль».

Может подвести

• Если правило iam:PassRole слишком широкое, злоумышленник сможет передать роль сервису, который потом выполнит нежелательные операции.
• Если роль имеет права администратора, а PassRole разрешён многим пользователям, это приводит к большим рискам.

Демонстрация: концепция и архитектура

Цель: настроить роль так, чтобы только EC2-экземпляр получал доступ к приватному S3-бакету, а обычные пользователи системы — нет. Для этого:

1. Создаём роль EC2S3Access и прикрепляем к ней политику AmazonS3ReadOnlyAccess.
2. Устанавливаем доверительную (trust) политику, позволяющую сервису ec2.amazonaws.com принимать роль.
3. Создаём IAM-политику для конкретного пользователя, разрешающую запуск и управление EC2, а также только передачу роли EC2S3Access через iam:PassRole.
4. Прикрепляем роль к запущенному экземпляру EC2 (instance profile).
5. На экземпялре проверяем доступ к S3 через aws cli.

Создание роли

Step 1. Откройте консоль IAM под аккаунтом администратора и выберите Roles. Нажмите Create role.

Step 2. В разделе Select trusted entity выберите Trusted entity type: AWS service и Use case: EC2.

Step 3. В разделе Add permissions прикрепите политику S3ReadOnlyAccess и нажмите Next.

Step 4. Дайте роли имя EC2S3Access и при необходимости описание. Консоль автоматически генерирует доверительную политику примерно такого вида:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Principal": {
                "Service": [
                    "ec2.amazonaws.com"
                ]
            }
        }
    ]
}

Step 5. Нажмите Create role и зафиксируйте ARN роли для дальнейшего использования.

Совет

• Храните ARN роли в инфраструктурном коде (IaC) и ограничьте доступ к нему.

Добавление IAM-политики для пользователя с правом PassRole

Теперь создадим политику, которая позволит конкретному IAM-пользователю управлять EC2 и передавать только роль EC2S3Access.

Step 1. В IAM выберите Policies и Create policy.

Step 2. Перейдите на вкладку JSON и вставьте следующую политику (замените account_ID на ваш ID аккаунта, при необходимости поменяйте имя роли):

{
   "Version": "2012-10-17",
   "Statement": [{
    "Effect":"Allow",
    "Action":["ec2:*"],
    "Resource":"*"
    },
    {
    "Effect":"Allow",
    "Action":"iam:PassRole",
    "Resource":"arn:aws:iam::account_ID:role/EC2S3Access"
    }]
}

Step 3. Добавьте теги при необходимости и нажмите Next: Review.

Step 4. Дайте политике имя, например iam_user_policy, и нажмите Create policy.

Step 5. Прикрепите созданную политику к целевому IAM-пользователю.

Рекомендация

• Не давайте ec2:* без необходимости. В идеале перечислите только нужные экшены (RunInstances, DescribeInstances, ModifyInstanceAttribute и т.д.).

Прикрепление роли к экземпляру EC2

Роль можно указать при запуске инстанса или привязать к уже запущенному.

В нашем примере инстанс уже запущен. В консоли EC2 выберите инстанс, затем Action > Security > Modify IAM role. В выпадающем списке выберите EC2S3Access и сохраните изменения.

Важно

• При изменении роли у запущенного экземпялра может потребоваться короткое время, чтобы новые временные креденшелы появились внутри ОС.

Тестирование конфигурации

Подготовка

1. Создайте приватный S3-бакет в аккаунте администратора.
2. На целевом EC2 установите AWS CLI и убедитесь, что на нём нет локальных статических ключей, которые могли бы маскировать роль.

Проверка на инстансе

Войдите на EC2 и выполните:

$ aws s3 ls

Вы должны увидеть список бакетов (включая ваш приватный бакет) — доступ получен через роль.

Проверка с другой машины

Сконфигурируйте AWS CLI с тем же IAM-пользователем, но на другой машине, где роль EC2 не применяется, и выполните ту же команду. Ожидаемо вы получите ошибку разрешения доступа.

Пояснение

• На EC2 доступ реализован через временные креды, предоставленные ролью EC2S3Access.
• На других машинах у IAM-пользователя нет разрешения на доступ к S3 и/или он не использует роль EC2.

Критерии приёмки

• Роль EC2S3Access создана и содержит политику доступа только к S3 (чтение).
• Доверительная политика роли ограничивает приём только ec2.amazonaws.com.
• IAM-пользователь имеет политику с iam:PassRole строго для arn:…:role/EC2S3Access.
• Прикреплённая роль позволяет EC2 успешно выполнять aws s3 ls, а тот же IAM-пользователь с личными учётными данными с другой машины не может получить доступ к тем же бакетам.

Контрольный чеклист перед развертыванием

• Проверить ARN роли и заменить account_ID в IAM-политике.
• Ограничить действие ec2:* до минимально необходимых экшенов.
• Убедиться, что роль не содержит избыточных прав (административных).
• Настроить логирование CloudTrail для действий sts:AssumeRole и iam:PassRole.
• Тестировать доступ из EC2 и из внешней среды.

Методология безопасного использования PassRole

1. Принцип наименьших привилегий: роль должна содержать только нужные права.
2. Явное ограничение iam:PassRole по ARN роли, а не “*”.
3. Разделение обязанностей: кто создаёт роль, кто может её передавать.
4. Мониторинг и оповещения при вызове sts:AssumeRole или iam:PassRole.

Альтернативные подходы

• Instance profile без использования iam:PassRole при запуске инстанса самим администратором (тогда обычные пользователи не нуждаются в PassRole).
• Использование AWS Systems Manager Session Manager для доступа к EC2 без SSH и без передачи ролей пользователям.
• Временные ключи через STS AssumeRole для сервисов вне AWS, если требуется межаккаунтный доступ.

Паттерны зрелости использования ролей

• Уровень 1 (Базовый): роли с широкими правами, PassRole ограничен незначительно. Подходит для небольших проектов, но рискован.
• Уровень 2 (Контролируемый): роли ограничены по сервисам, iam:PassRole предоставлен для отдельных ролей.
• Уровень 3 (Зрелый): роли минимальны, аудит и мониторинг включены, автоматические проверки IaC обнаруживают избыточные права.

Риски и меры смягчения

Риски

• Чрезмерно широкое iam:PassRole позволит злоумышленнику прикреплять роли с лишними правами.
• Роль с правами изменения сетевых настроек или создания IAM может привести к компрометации.

Митигаторы

• Ограничивать ресурс в iam:PassRole.
• Ревью и анализ политик перед развертыванием.
• Включить CloudTrail и настроить оповещения на нестандартные вызовы sts:AssumeRole.

Тестовые сценарии и приёмочные критерии

1. Тест: EC2 с ролью может выполнить aws s3 ls. Ожидаемый результат: список бакетов. Критерий приёмки: PASSED.
2. Тест: IAM-пользователь с политикой но без роли на другой машине выполняет aws s3 ls. Ожидаемый результат: AccessDenied. Критерий приёмки: PASSED.
3. Тест: Попытка пользователя передать роль, не указанную в iam:PassRole (другая роль). Ожидаемый результат: AccessDenied. Критерий приёмки: PASSED.
4. Тест аудита: CloudTrail показывает вызов iam:PassRole и sts:AssumeRole с корректным временем и источником. Критерий приёмки: PASSED.

Роли и ответственность

Администратор

• Создаёт роль и trust policy.
• Контролирует, какие роли доступны для передачи.

Разработчик / Operator

• Запускает EC2 с заданной ролью (если есть право PassRole).
• Тестирует доступ с инстанса.

Security Engineer

• Проверяет политики на соответствие принципу наименьших привилегий.
• Настраивает логирование и оповещения.

Шаблон Playbook для быстрого внедрения

1. Создать роль EC2S3Access с AmazonS3ReadOnlyAccess.
2. Проверить и сохранить ARN роли.
3. Создать IAM политику для пользователя с ec2: ограниченным набором действий и iam:PassRole для ARN роли.
4. Прикрепить политику к пользователю.
5. Прикрепить роль к EC2 или запустить новый инстанс с ролью.
6. Выполнить тесты подключения к S3 и сверить логи CloudTrail.
7. Провести ревью прав и задокументировать изменение.

Security hardening рекомендации

• Запретить iam:PassRole для групп пользователей и давать его по необходимости.
• Разделить роли по зонам ответственности: роли для доступа к S3, роли для администратора сети и т.д.
• Регулярно сканировать политики на наличие wildcard-ресурсов.
• Включить MFA для операций изменения IAM, если применимо.

Конфиденциальность и соответствие

• Передача ролей не изменяет конфиденциальность данных в S3. Контроль доступа зависит от политик роли и прав бакета.
• Проверьте требования соответствия (GDPR, ISO), если бэкенд S3 хранит персональные данные: применяйте шифрование, версии объектов и политики хранения.

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

Что такое разница между PassRole и AssumeRole

PassRole разрешает передать роль сервису при создании ресурса. AssumeRole — это действие, выполняемое сервисом или субъектом, чтобы принять роль и получить временные креденшелы.

Могу ли я ограничить PassRole до конкретных операций

Нет, iam:PassRole касается возможности передать роль, а не конкретных сервисных операций. Ограничьте ресурс (ARN роли), чтобы контролировать, какие роли можно передавать.

Нужно ли удалять роль после тестирования

Да, если роль создавалась временно, её следует удалить или заменить на более ограниченную. Всегда документируйте роли и их назначение.

Заключение

PassRole — важный инструмент для безопасного делегирования прав в AWS. Он позволяет разграничить ответственность: администратор создаёт и ограничивает роль, а пользователи могут запускать сервисы с нужными правами без получения постоянных ключей. Сочетание ограниченных ролей, узконаправленных прав iam:PassRole и мониторинга обеспечивает гибкий и безопасный доступ.

Важное примечание

• Всегда применяйте принцип наименьших привилегий и ограничивайте iam:PassRole по ARN роли.