みなさんは、信頼ポリシーを活用したことはありますか？
IAMロール作成時などに見たことある方もいるかもしれません。
そもそもIAMロールって？
「ロール」＝「権限」
- 「AWS では、すべてのリソース操作は IAM ポリシーによって評価され、明示的に許可されていない操作はデフォルトで拒否される。そのため、AWS の各サービスを利用するには、IAM ポリシーで必要な権限が付与されている必要がある。」
- 「EC2インスタンスを起動する」「S3バケットにファイルを置く」などの全ての操作に必要なもの
- サービスなどに紐づけて使用する
- ロールは ポリシー を集めたセット
→ 権限がなければ何も操作できません！権限を与えられることで初めてうごかすことができます！
私が信頼ポリシーに触れたきっかけは、EC2の稼働状況をSlackへ通知するアプリを作成する必要があったからでした。
（完成形↓）
このアプリを構築するにあたり、複数のAWSアカウントにあるEC2の稼働状況を見に行く必要がありました。
ここで必要になったのが、sts:AssumeRoleです！
「Assume」＝「引き継ぐ」
＝＞別のAWSアカウントのロール(権限)を一時的に引き継いで、使用することができます！
Assumeしてリソース処理するまでには、３つのポリシーが必要です。
①："Account Y"のロールを使いたい(引き継ぎたい)と言うポリシー（許可ポリシー）
②："Account X"が自分(ロール)を使っていいよ(引き継いでいいよ)と言うポリシー（信頼ポリシー）
③：リソースの操作ができるようになるポリシー（許可ポリシー）
①と②はこんなイメージです↓
まず①では、Account X側で許可ポリシーを作成します。
ここでは「Account Yの××ロールを引き継ぎたい」という内容を書いておきます。
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::<Account_Y>:role/<××Role>"
]
}
これに対し②では、信頼ポリシーに「Account Xがこの××ロールを引き継いでもよいよ」という内容を書きます。
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<Account_X>:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
これにより、Account XがAccount Yの××ロールを一時的に使用することができます！
（↑図にて、Lambdaがヘルメット(××ロール)を被った状態）
あとは③で、××ロールにEC2情報を見るための許可ポリシーを設定すれば…
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::30days-s3notify"
]
}
一時的な認証情報を受け取ることができました🎉
実際に構築していたところ、
[ERROR] ClientError: An error occurred (AccessDenied) when calling the AssumeRole operation:
とたくさん怒られました。
もしそうなってしまっても、
①：ロールを使いたい(引き継ぎたい)と言う 許可ポリシー
②：自分(ロール)を使っていいよ(引き継いでいいよ)と言う 信頼ポリシー
③：リソースの操作に必要な 許可ポリシー
+AssumuRoleコマンド実行時のロール名（shellやLambdaコード内）
を押さえておけばほぼ解決できるので、焦らずこまめに確認することをおすすめします、！
余談
信頼ポリシーでは、ワイルドカード(*)のような極端な許可を設定することができません。
引き継いで使用する側のアカウントなどはある程度指定する必要がありました。
以上、お付き合いいただきありがとうございました！
参考になれば幸いです！