IAM ロールで一時認証情報を使う

はじめに

ワーカーには、一時的な処理用アイデンティティを通じたレポートへのアクセスが必要です。ロールを作成し、誰が使えるかを選び、読み取り権限をテストして、削除前にアクセスを取り消します。

最初に レポートの読み取り役に最小権限を与える を完了し、ポリシーのフィールドとリクエストの境界について学んでください。この新しい VM には default、worker、outsider プロファイルが準備済みです。/home/labex/project と AWS View を使ってください。個人アカウントの設定は不要です。認証情報ファイル、CLI キャッシュ、フィルターしていない AssumeRole 応答は非公開に保ってください。

認定試験との関連

ラボの概要

ロールの信頼と読み取り権限を定義する

このステップでは、許可する呼び出し元を指定した信頼ポリシーで ReportReader を作成します。信頼ポリシーはロールのリソースポリシーです。その Principal は、誰がロールを引き受けられるかを識別します。ロールの権限ポリシーは、結果として得られるセッションが何を行えるかを別に定義します。

レポート処理には、一時的なロールセッションが必要になります。S3 の操作には既知の Action と Resource を使い、ロールに入れるかどうかは別の信頼ポリシーで定めます。アクセスを取り消す前に、この二つの判断を個別にテストします。

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

末尾が role/ReportReader の ARN を想定します。ロールを作成しても、S3 権限は与えられません。限定したインラインポリシーを一つ追加します。ロールは今日のレポートだけを GetObject でき、書き込みや給与情報の読み取りはできません。

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

外部ユーザーのアイデンティティポリシーが AssumeRole を許可していても、AccessDenied を想定します。その 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 がなくても入り口の許可を与えられます。ここで同じ呼び出し元の許可を与えたのは、信頼の比較を明確にするためです。

末尾が assumed-role/ReportReader/report-run の ARN を想定します。セッション名は、操作記録でロールの使用を区別するのに役立ちます。ロールの認証情報には有効期限があります。次の 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

再び assumed-role の ARN を想定します。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

PutObject の AccessDenied と、変更されていない 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 を持つ参照用バケットだけが残ります。これらの正常な問い合わせによって、削除と保持を確認できます。使い捨ての環境は、終了時に準備済みアイデンティティと一時認証情報ファイルを回収します。この演習用に作成したロールと呼び出し元の許可を削除できました。

まとめ

ロールの信頼と権限ポリシーを分け、呼び出し元の許可だけでは信頼を回避できないことを証明し、CLI ロールプロファイルを通じて STS を使いました。ロールセッションは、自分のレポートだけを読み取れ、書き込みや無関係なデータの読み取りはできませんでした。範囲を限定した削除の前に、ロールと呼び出し元の両方の許可を取り消しました。恒久的なワークロードキーより一時的なロールを優先し、アクセスを診断するときは実際のアイデンティティと許可・拒否されるリクエストを確認してください。

詳しくは、AWS 公式ドキュメントを参照してください：IAM ロール、信頼、一時的な認証情報.