何か作業を行う際に、作業用のIAMロールへ スイッチロール(AssumeRole)するケースは多いと思います。 そのときの権限は基本的には 「そのロールにアタッチされたポリシー」です。
ですが、その権限を AssumeRole 時に狭められることを最近(今更)知りました。 「セッションポリシー」というものを使って スイッチロール先での権限を狭められるとのこと。
今回はこのセッションポリシーを適用して スイッチロール(AssumeRole)を試してみました。
まずは普通にAssumeRole
まずは aws sts assume-role コマンドを使った いつもどおりのスイッチロールを紹介します。
以下シンプルなコマンドサンプルです。
### スイッチ先のロールARN
role_arn="arn:aws:iam::123456789012:role/example-dev-role"
### AssumeRole
resp=$(aws sts assume-role --output json \
--role-arn "${role_arn}" \
--role-session-name "develop")
### 環境変数に認証情報を登録
export AWS_ACCESS_KEY_ID=$(echo "$resp" | jq -r ".Credentials.AccessKeyId")
export AWS_SECRET_ACCESS_KEY=$(echo "$resp" | jq -r ".Credentials.SecretAccessKey")
export AWS_SESSION_TOKEN=$(echo "$resp" | jq -r ".Credentials.SessionToken")
### 確認
aws sts get-caller-identity --output yaml
# Account: '123456789012'
# Arn: arn:aws:sts::123456789012:assumed-role/example-dev-role/develop
# UserId: AROAEXAMPLE:developちなみにMFAが必要な場合、 aws sts assume-role 部分は 以下のようなコマンドになります。 --token-code にMFAデバイスに表示されている数字を入れます。
serial_number="arn:aws:iam::111111111111:mfa/example-user"
token_code="123456"
aws sts assume-role --output json \
--role-arn "${role_arn}" \
--role-session-name "develop" \
--serial-number "${serial_number}" \
--token-code "${token_code}"権限を狭めてAssumeRole
権限を狭めるには セッションポリシー を使います。 これは AssumeRoleの際にパラメータとして設定できます。
セッションポリシーは リソースベースのポリシーと アイデンティティベースのポリシーを制限する役割を持っています。 以下ベン図が分かりやすいです。
管理ポリシーを使って権限を狭める
例として、 ReadOnlyAccess の範囲内に狭めたい場合のコマンドを記載します。 policy-arns パラメータに管理ポリシーのARNリストを記載してあげます。
### スイッチ先のロールARN
role_arn="arn:aws:iam::123456789012:role/example-dev-role"
### AssumeRole
resp=$(aws sts assume-role --output json \
--role-arn "${role_arn}" \
--role-session-name "readonly" \
--policy-arns arn="arn:aws:iam::aws:policy/ReadOnlyAccess")
### 環境変数に認証情報を登録
export AWS_ACCESS_KEY_ID=$(echo "$resp" | jq -r ".Credentials.AccessKeyId")
export AWS_SECRET_ACCESS_KEY=$(echo "$resp" | jq -r ".Credentials.SecretAccessKey")
export AWS_SESSION_TOKEN=$(echo "$resp" | jq -r ".Credentials.SessionToken")これにより、仮にIAMロール先が AdministratorAccess 権限を持っていたとしても、 変更アクションは取れなくなります。
aws sns create-topic --name example-topic
# An error occurred (AuthorizationError) when calling the CreateTopic operation:
# User: arn:aws:sts::123456789012:assumed-role/example-dev-role/readonly is not authorized to perform:
# SNS:CreateTopic on resource: arn:aws:sns:ap-northeast-1:123456789012:example-topic
# because no session policy allows the SNS:CreateTopic action「セッションポリシーで sns:CreateTopic アクションが許可されていない」と メッセージにも出てきます。
インラインポリシーも使える
policy パラメータにインラインポリシーを指定できます。 以下コマンド例です。
### スイッチ先のロールARN
role_arn="arn:aws:iam::123456789012:role/example-dev-role"
inline_policy=$(cat <<EOS
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DescribeRegions",
"Resource": "*"
}
]
}
EOS
)
### AssumeRole
resp=$(aws sts assume-role --output json \
--role-arn "${role_arn}" \
--role-session-name "list-region" \
--policy "${inline_policy}")
### 環境変数に認証情報を登録
export AWS_ACCESS_KEY_ID=$(echo "$resp" | jq -r ".Credentials.AccessKeyId")
export AWS_SECRET_ACCESS_KEY=$(echo "$resp" | jq -r ".Credentials.SecretAccessKey")
export AWS_SESSION_TOKEN=$(echo "$resp" | jq -r ".Credentials.SessionToken")上記の例は極端ですが、 ec2:DescribeRegions しかできない AssumeRole となります。
aws ec2 describe-regions
# Regions:
# - Endpoint: ec2.ap-south-1.amazonaws.com
# OptInStatus: opt-in-not-required
# RegionName: ap-south-1
# - Endpoint: ec2.eu-north-1.amazonaws.com
# OptInStatus: opt-in-not-required
# RegionName: eu-north-1
# - Endpoint: ec2.eu-west-3.amazonaws.com
# ...(略)...
aws ec2 describe-vpcs
# An error occurred (UnauthorizedOperation) when calling the DescribeVpcs operation:
# You are not authorized to perform this operation.
# User: arn:aws:sts::123456789012:assumed-role/example-dev-role/list-region is not authorized to perform: ec2:DescribeVpcs
# because no session policy allows the ec2:DescribeVpcs actionおわりに
以上、セッションポリシーを使って スイッチロール先での作業権限を狭めてみました。
基本的には最小権限を意識して 「アイデンティティベースのポリシー」や「リソースベースのポリシー」 を設計するのは変わらないです。 利用者側でよりセキュアにAWS利用する際のTipsとして 抑えておくと良いでしょう。
10
