Предоставьте приложению EC2 доступ к S3 через IAM

Введение

Вашему приложению EC2 нужно читать отчёт из S3. Вы назначите приложению роль IAM через профиль экземпляра, проверите фактическое чтение отчёта и увидите, что происходит при отзыве разрешения.

Вы должны знать запуск EC2, User Data и основы политик IAM. Эта новая среда предоставляет образ приложения, сеть, пару ключей и бакет S3 с синтетическими данными. Вы создадите экземпляр приложения и его ресурсы авторизации.

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

Эта лабораторная закрепляет минимальные привилегии и роли рабочих нагрузок, поддерживая задачу 2.3 целей безопасности AWS Certified Cloud Practitioner и задачу 3.3 целей вычислений.

Запустите приложение без роли

На этом шаге вы запустите сервер отчётов и увидите, что приложение пока не может читать S3.

Начните в рабочем каталоге и загрузите предоставленные идентификаторы образа, сети и бакета отчётов:

cd /home/labex/project

source launch.env

Проверьте предоставленный скрипт запуска. Он задаёт бакет S3 и ключ объекта для приложения, но не предоставляет учётных данных:

cat role-user-data.sh

Запустите сервер с именем role-server и этой конфигурацией:

aws ec2 \
  run-instances \
  --image-id "$AMI_ID" \
  --instance-type t3.micro \
  --subnet-id "$SUBNET_ID" \
  --security-group-ids "$SECURITY_GROUP_ID" \
  --key-name report-key \
  --count 1 \
  --user-data file://role-user-data.sh \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=role-server}]'

Сохраните его идентификатор:

INSTANCE_ID=$(aws ec2 \
  describe-instances \
  --filters Name=tag:Name,Values=role-server \
  --query 'Reservations[0].Instances[0].InstanceId' \
  --output text)

aws ec2 \
  wait instance-running \
  --instance-ids "$INSTANCE_ID"

Откройте AWS View, нажмите Refresh resources, выберите role-server и нажмите Check application. Подтвердите HTTP 200 и Role report server. Затем нажмите Read S3 report. Ожидаются HTTP 503 и Application storage unavailable: работающее приложение пока не имеет учётных данных роли.

Приложение на EC2 может получить временные учётные данные назначенной роли через метаданные экземпляра. Его AWS SDK использует эти данные для подписи запросов API. Официальное руководство по ролям EC2 объясняет этот процесс. Вы настроите роль вместо копирования учётных данных терминала в приложение.

Предоставьте доступ через профиль экземпляра

На этом шаге вы создадите политики доверия и разрешений роли, добавите роль в профиль экземпляра и свяжете профиль с сервером.

Политика доверия определяет, кто может принять роль. Создайте политику JSON, которая доверяет сервису EC2. Here-document с разделителем в кавычках сохраняет JSON буквально:

cat > ec2-trust.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "ec2.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
JSON

Создайте роль report-reader с этой политикой доверия:

aws iam \
  create-role \
  --role-name report-reader \
  --assume-role-policy-document file://ec2-trust.json

Политика разрешений определяет, что может делать принятая роль. Приложению нужен только s3:GetObject для report.csv. ARN объекта включает бакет и ключ. В отличие от предыдущего here-document с кавычками, маркер JSON без кавычек ниже подставляет вместо $REPORT_BUCKET предоставленное имя бакета:

cat > read-report.json <<JSON
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::$REPORT_BUCKET/report.csv"
  }]
}
JSON

Проверьте полученный ARN ресурса:

cat read-report.json

Добавьте эту встроенную политику к своей роли:

aws iam \
  put-role-policy \
  --role-name report-reader \
  --policy-name ReadReport \
  --policy-document file://read-report.json

Профиль экземпляра передаёт роль IAM в EC2. При использовании CLI роль и профиль создаются отдельно. Для ясности создайте профиль с тем же именем:

aws iam \
  create-instance-profile \
  --instance-profile-name report-reader

Добавьте роль в профиль:

aws iam \
  add-role-to-instance-profile \
  --instance-profile-name report-reader \
  --role-name report-reader

Свяжите профиль с существующим экземпляром и сохраните идентификатор связи для удаления ресурсов:

ASSOCIATION_ID=$(aws ec2 \
  associate-iam-instance-profile \
  --instance-id "$INSTANCE_ID" \
  --iam-instance-profile Name=report-reader \
  --query 'IamInstanceProfileAssociation.AssociationId' \
  --output text)

Проверьте связь:

aws ec2 \
  describe-iam-instance-profile-associations \
  --association-ids "$ASSOCIATION_ID" \
  --query 'IamInstanceProfileAssociations[].{Instance:InstanceId,State:State,Profile:IamInstanceProfile.Arn}'

Подтвердите associated и профиль report-reader. Обновите AWS View и нажмите Read S3 report. Ожидается HTTP 200 с period,total и Q1,320. Приложение использует учётные данные роли из SDK для получения реального объекта S3. Если связь ещё распространяется, немного подождите и повторите запрос.

Роль разрешает читать один объект, а не предоставляет доступ ко всему бакету или права администратора. Руководство по профилям экземпляров объясняет передачу ролей через профили и задержку распространения изменений связи.

Наблюдайте отзыв разрешения

На этом шаге вы удалите разрешение роли на отчёт и отличите ошибку авторизации от ошибки приложения.

Удалите только созданную вами встроенную политику:

aws iam \
  delete-role-policy \
  --role-name report-reader \
  --policy-name ReadReport

Выведите оставшиеся встроенные политики роли:

aws iam \
  list-role-policies \
  --role-name report-reader

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

В AWS View нажмите Check application и подтвердите HTTP 200: сервер по-прежнему работает. Затем нажмите Read S3 report. Ожидаются HTTP 403 и Access denied. Если изменения разрешений ещё не распространились, немного подождите и повторите запрос. Успешная проверка состояния вместе с отказом S3 указывает на авторизацию, а не на остановленный экземпляр или отсутствующее приложение.

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

Удалите экземпляр и роль

На этом шаге вы удалите свою связь, сервер, профиль и роль.

Разорвите связь профиля с помощью сохранённого идентификатора:

aws ec2 \
  disassociate-iam-instance-profile \
  --association-id "$ASSOCIATION_ID"

Завершите экземпляр приложения:

aws ec2 \
  terminate-instances \
  --instance-ids "$INSTANCE_ID"

aws ec2 \
  wait instance-terminated \
  --instance-ids "$INSTANCE_ID"

Удалите роль из больше не используемого профиля экземпляра:

aws iam \
  remove-role-from-instance-profile \
  --instance-profile-name report-reader \
  --role-name report-reader

Удалите пустой профиль:

aws iam \
  delete-instance-profile \
  --instance-profile-name report-reader

Встроенная политика уже удалена при отзыве разрешения. Удалите свою роль:

aws iam \
  delete-role \
  --role-name report-reader

Подтвердите, что экземпляр завершён:

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'

Проверьте отсутствие роли и профиля с указанными именами:

aws iam \
  list-roles \
  --query "Roles[?RoleName=='report-reader'].RoleName"

aws iam \
  list-instance-profiles \
  --query "InstanceProfiles[?InstanceProfileName=='report-reader'].InstanceProfileName"

Оба списка должны быть []. Обновите AWS View и подтвердите, что сервер больше не является работающей целью. Оставьте подготовленные данные S3, сеть и пару ключей на месте.

Итоги

Вы создали доверие EC2 и разрешение читать один объект S3 для роли IAM, передали роль через профиль экземпляра и проверили фактическое чтение отчёта приложением. Затем вы отозвали разрешение и отличили отказ S3 от работоспособного приложения. Наконец, вы удалили экземпляр, профиль и роль.

Предоставьте роли экземпляра доступ к S3