Используйте временные учётные данные роли IAM

Введение

Обработчику нужен доступ к отчёту через временную идентичность задачи. Вы создадите роль, выберете, кто может её использовать, проверите разрешение чтения и отзовёте доступ перед очисткой.

Сначала выполните работу Предоставьте читателю отчётов минимальные привилегии, чтобы освоить поля политик и границы запросов. Эта новая VM подготавливает профили default, worker и outsider. Используйте /home/labex/project и AWS View; настройка личного аккаунта не нужна. Не раскрывайте файлы учётных данных, кеши CLI и нефильтрованные ответы AssumeRole.

Связь с сертификацией

Обзор лабораторной работы

Определите доверие роли и разрешение чтения

На этом шаге вы создадите ReportReader с политикой доверия, называющей разрешённую вызывающую сторону. Политика доверия — политика ресурса роли: её Principal определяет, кто может принять эту роль. Политика разрешений роли отдельно определяет, что может делать полученный сеанс.

Задаче отчётности теперь нужен временный сеанс роли. Используйте знакомые поля Action и Resource для работы с S3, а отдельную политику доверия — для входа в роль. Перед отзывом доступа вы проверите эти два решения по отдельности.

Роль IAM определяет разрешения и тех, кто может её принять. AWS Security Token Service (STS) выдаёт временные учётные данные сеанса роли — идентичности, отличной от вызывающей стороны.

Подтвердите ARN обработчика, чтобы сравнить его с начальным доверием.

cd /home/labex/project

aws sts get-caller-identity --profile worker --query Arn --output text

Ожидайте arn:aws:iam::123456789012:user/report-worker. Начните с доверия, называющего только оператора. sts:AssumeRole запрашивает сеанс роли; Principal — ARN идентичности, а не имя профиля. Обработчик намеренно ещё не пользуется доверием.

cat > trust.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:user/iam03-operator"},"Action":"sts:AssumeRole"}]}
JSON

aws iam create-role \
  --role-name ReportReader \
  --assume-role-policy-document file://trust.json \
  --query Role.Arn \
  --output text

Ожидайте ARN, заканчивающийся на role/ReportReader. Создание роли не даёт ей разрешений S3. Добавьте одну узкую встроенную политику: роль может выполнять GetObject только для сегодняшнего отчёта, а не записывать его или читать payroll.

cat > role-policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam03-reports/reports/today.txt"}]}
JSON

aws iam put-role-policy \
  --role-name ReportReader \
  --policy-name ReportRead \
  --policy-document file://role-policy.json

aws iam get-role --role-name ReportReader --query Role.AssumeRolePolicyDocument

aws iam get-role-policy \
  --role-name ReportReader \
  --policy-name ReportRead \
  --query PolicyDocument

Прочитайте оба документа. Доверие управляет входом; разрешения роли управляют операциями сеанса. Обработчик ещё не пользуется доверием. Проверьте этот барьер, выбирая только безопасное возвращаемое поле ARN.

aws sts assume-role --profile worker --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name report-run --query AssumedRoleUser.Arn --output text || true

Ожидайте AccessDenied. Не удаляйте фильтр запроса: нефильтрованный успешный ответ включает секреты.

Авторизуйте вызывающую сторону и используйте профиль роли

На этом шаге вы позволите обработчику запрашивать ReportReader, обновите доверие роли и используете профиль роли. Оба тестовых пользователя получат одинаковое разрешение вызывающей стороны; только доверенный обработчик должен получить сеанс роли.

Напишите политику вызывающей стороны, чей Resource — точный ARN роли, затем прикрепите её к обработчику.

cat > assume-policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"sts:AssumeRole","Resource":"arn:aws:iam::123456789012:role/ReportReader"}]}
JSON

aws iam put-user-policy \
  --user-name report-worker \
  --policy-name AssumeReportReader \
  --policy-document file://assume-policy.json

Чтобы изолировать проверку доверия, дайте постороннему пользователю то же узкое разрешение вызывающей стороны. Этот временный пользователь для сравнения не указан в документе доверия.

aws iam put-user-policy \
  --user-name outsider \
  --policy-name AssumeReportReader \
  --policy-document file://assume-policy.json

aws sts assume-role --profile worker --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name before-trust --query AssumedRoleUser.Arn --output text || true

Ожидайте AccessDenied: Allow его идентичности не отменяет существующее доверие, называющее только оператора. Замените это доверие нужным обработчиком и обновите роль.

cat > trust.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:user/report-worker"},"Action":"sts:AssumeRole"}]}
JSON

aws iam update-assume-role-policy \
  --role-name ReportReader \
  --policy-document file://trust.json

aws sts assume-role --profile outsider --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name outsider-test --query AssumedRoleUser.Arn --output text || true

Ожидайте AccessDenied, хотя политика идентичности постороннего пользователя разрешает AssumeRole. Его ARN не пользуется доверием. Повторите как обработчик:

aws sts assume-role \
  --profile worker \
  --role-arn arn:aws:iam::123456789012:role/ReportReader \
  --role-session-name report-run \
  --query AssumedRoleUser.Arn \
  --output text

Доверие роли определило, какая вызывающая сторона может войти. Allow идентичности не может его обойти. При доверии в том же аккаунте, прямо называющем пользователя, это доверие может предоставить вход без отдельного Allow идентичности; одинаковые разрешения вызывающих сторон здесь помогают изолировать сравнение доверия.

Ожидайте ARN, заканчивающийся на assumed-role/ReportReader/report-run. Имя сеанса помогает различать использования роли в записях активности. Учётные данные роли истекают; профиль роли CLI ниже получает временные учётные данные за вас.

Настройте подготовленный профиль report-role для автоматического запроса этих временных учётных данных. source_profile выбирает вызывающую сторону, а role_arn — целевую роль. Эти настройки не содержат секретных значений. CLI безопасно хранит временный кеш; не выводите его.

aws configure set role_arn arn:aws:iam::123456789012:role/ReportReader --profile report-role

aws configure set source_profile worker --profile report-role

aws configure set role_session_name report-run --profile report-role

aws sts get-caller-identity --profile report-role --query Arn --output text

Снова ожидайте ARN assumed-role. CLI выполняет аутентификацию STS внутренне для этого профиля. Сама идентичность обработчика имеет разрешение AssumeRole, а не разрешение S3 роли.

aws s3api get-object --profile worker --bucket labex-iam03-reports --key reports/today.txt direct-worker.txt || true

Ожидайте AccessDenied. Принятие роли не прикрепляет её разрешения обратно к исходному пользователю.

Проверьте границы ресурсов и действий сеанса роли

На этом шаге вы используете профиль роли для задачи отчётности и подтвердите, что он не может выполнять постороннюю работу. Успешный запрос AssumeRole доказывает только вход в роль; фактические запросы S3 доказывают её действующий доступ.

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam03-reports \
  --key reports/today.txt today.txt

cat today.txt

Ожидайте Daily orders: 145. Попробуйте два существующих ресурса вне точного ARN объекта роли.

aws s3api get-object --profile report-role --bucket labex-iam03-reports --key private/payroll.txt private-denied.txt || true

aws s3api get-object --profile report-role --bucket labex-iam03-reference --key reference.txt reference-denied.txt || true

Оба должны вернуть AccessDenied. Затем попробуйте перезаписать сегодняшний отчёт предоставленной неутверждённой заменой. GetObject не авторизует PutObject.

aws s3api put-object --profile report-role --bucket labex-iam03-reports --key reports/today.txt --body upload.txt || true

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam03-reports \
  --key reports/today.txt today.txt

cat today.txt

Ожидайте AccessDenied для PutObject и неизменённое Daily orders: 145. Отсутствующий локальный файл, ошибка просроченных учётных данных или недоступный сервис — другая диагностика, не доказывающая границу разрешений. AWS View показывает сохранённое доверие, политику роли и фактическое чтение сеанса роли; раскройте сегодняшний отчёт, чтобы изучить байты.

Отзовите доступ роли и выполните очистку

На этом шаге вы удалите разрешение роли на отчёт перед удалением данных. Удаление разрешения роли и предотвращение новых принятий — отдельные действия; одна очистка локального кеша не отзывает разрешения на стороне сервера.

Удалите ReportRead, пока роль и отчёт ещё существуют, затем повторите чтение через профиль роли.

aws iam delete-role-policy --role-name ReportReader --policy-name ReportRead

aws s3api get-object --profile report-role --bucket labex-iam03-reports --key reports/today.txt revoked.txt || true

Ожидайте AccessDenied. Удалите оба разрешения вызывающих сторон и замените прямое доверие обработчику доверием только оператору. Одно удаление Allow идентичности не отзывает прямое разрешение доверия в том же аккаунте. Затем проверьте, что обработчик не может получить свежий сеанс.

aws iam delete-user-policy --user-name report-worker --policy-name AssumeReportReader

aws iam delete-user-policy --user-name outsider --policy-name AssumeReportReader

cat > trust.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:user/iam03-operator"},"Action":"sts:AssumeRole"}]}
JSON

aws iam update-assume-role-policy \
  --role-name ReportReader \
  --policy-document file://trust.json

aws sts assume-role --profile worker --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name after-revocation --query AssumedRoleUser.Arn --output text || true

Ожидайте AccessDenied, пока роль ещё существует. Удаляйте роль только после этих функциональных проверок отзыва.

aws iam delete-role --role-name ReportReader

aws iam list-roles --query 'Roles[].RoleName'

aws s3api delete-object --bucket labex-iam03-reports --key reports/today.txt

aws s3api delete-object --bucket labex-iam03-reports --key private/payroll.txt

aws s3api list-objects-v2 --bucket labex-iam03-reports

Ожидайте пустой список ролей и KeyCount: 0 в ответе объектов. Удалите пустой собственный бакет, затем подтвердите, что эталонный ресурс всё ещё существует с исходными байтами.

aws s3api delete-bucket --bucket labex-iam03-reports

aws s3api list-buckets --query 'Buckets[].Name'

aws s3api get-object --bucket labex-iam03-reference --key reference.txt reference.txt

cat reference.txt

Остаётся только эталонный бакет с Platform reference: keep. Эти успешные запросы устанавливают удаление и сохранение. Временная среда освобождает подготовленные идентичности и временные файлы учётных данных при завершении. Вы удалили роль и разрешения вызывающих сторон, созданные для этого упражнения.

Резюме

Вы отделили доверие роли от политики разрешений, доказали, что одно разрешение вызывающей стороны не может обойти доверие, и использовали STS через профиль роли CLI. Сеанс роли мог читать только свой отчёт и не мог записывать или читать посторонние данные. Вы удалили разрешения роли и вызывающих сторон перед ограниченной очисткой. Предпочитайте временные роли постоянным ключам рабочих нагрузок и изучайте фактическую идентичность и разрешённые и запрещённые запросы при диагностике доступа.

Подробнее см. в документации AWS: Роли IAM, доверие и временные учётные данные.