はじめに
マルチアカウントでのAWSアカウントはどのように運用していますか？
以下イメージのようにJumpアカウントを設けて、IAM Userの一元化を行っているケースが多いと思います。
この構成を取る際に、セキュリティを考慮し、IAM GroupがSwitch出来るRoleを絞るために、IAM GroupにアタッチするPolicyでSwitch先のRoleを絞っていると思います。
しかし、先日組織のセキュリティポリシー上このJumpアカウント側のPolicyをカスタマイズ出来ないケースに遭遇しました。
このポリシーに準拠したうえで、IAM GroupがSwitch出来るRoleを絞るために、IAM Role側の信頼関係を用いて制御しました。
本記事では、このIAM Role側の信頼関係用いたSwitch Role制御の実装方法に関してご紹介させて頂きます。
信頼関係を用いた制御
実装イメージとしては以下のようになります。
ポイントとしては、以下2つです。
- ユーザに役割を示すタグをつける
※IAM Groupにはタグをつけることが出来ないため、IAM Userにタグをつけます。
そのタグをベースに信頼関係にてSwitchさせるかどうかの制御をしています。 - IAM Roleの信頼関係でユーザのタグにより、Roleの引き渡しを制御する
それぞれのポイントに分けて、紹介させて頂きます。
ユーザにつけるタグ
ユーザには以下のようにタグをつけます。
グループ名をKeyとし、役割をValueに入れています。
上記の場合、infraGroupに所属し、開発(dev)、本番(prod)環境に対して、adminという役割を持つ形となります。
IAM Roleの信頼関係に関わってくるのですが、「：」を用いて役割所掌をつなげています。
IAM Roleの信頼関係
IAM Roleの信頼関係は以下のようになります。
"Statement": [
{
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:iam::jumpアカウント:user/*"
},
"ForAnyValue:StringLike": {
"aws:PrincipalTag/infraGroup": [
"*dev-admin*"
]
}
},
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::jumpアカウント:root" }
ここが本構成の最重要ポイントととなります。
IAM Userと関連する部分にフォーカスして紹介させて頂きます。
"StringLike": {
Condition句の一部となります。
JumpアカウントのIAM UserからのみこのRoleを引き受けることを許可しています。
"ForAnyValue:StringLike": {
Condition句の一部となりです。
IAM UserにinfraGroupタグが設定されており、そのタグ値に「dev-admin」が含まれる場合のみ、このRoleを引き受けることを許可しています。
"*dev-admin*"のように「*」で囲んでいるのは、「prod」等他の環境に対しても権限を持つ場合IAM Userのタグにて「:」でつなげています。
例：「dev-admin:prod-admin」
そのため、前段や後段に「:」がある可能性があるため「*]で囲っています。
まとめ
今回は、Jumpアカウントを用いたマルチアカウント環境下で、信頼関係を用いてSwitch Roleを制御する方法をご紹介させて頂きました。
素直に考えるとPolicyで制御しちゃえばいいんですが、このやり方の優位性は同じIAM Groupに所属させたうえで、Assume Role先を制御できるので、Groupから一段掘り下げて細かく制御することができる部分にあります。なので、無駄にGroupを乱立させなくてよいというメリットが出てきます。
Jumpアカウントを構成したマルチアカウント環境下で、Switch Roleのご利用をご検討の際は、ご紹介させて頂いた内容を参考にして頂けると幸いです。
※ 本ブログに記載した内容は個人の見解であり、所属する会社、組織とは全く関係ありません。