この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
福岡オフィスの梶原です。
先日、AWS CLIでSwitch Role してさらに Switch Role してみた。を公開してエゴサしてると
「EC2に割り当てたRoleの場合はどうすんの?」ってつぶやきを発見しました。
あーそういう事か、確かにEC2にAPIキーを置くとかありえんよねー。 ということで、調べました!
まぁ、最悪できんでも、EC2のロールで、一時クレデンシャル取って、それをaws sts assume-role
でRole取得の際に指定して、うわーーーそんなん、めんどい、やっぱ終了
と、思っていたところ
つ AWS CLIでインスタンスプロファイルからのAssumeRoleが簡単になりました | DevelopersIO
ということで
source_profile = role-a
ってしていたところを
credential_source = Ec2InstanceMetadata
に置き換えれば、一時クレデンシャルを取得してあーだこーだってことをやってくれるみたいです。。なんて楽。
図にするとこんな感じです
やってみる
引き受け元のEC2RoleAはEC2に割り当て
EC2RoleAのポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
引受先のEC2RoleBのポリシーでEC2RoleA
を引き受け先に設定
EC2RoleBのポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"arn:aws:iam::xxxxxxxxxxx:role/EC2RoleA"
},
"Action": "sts:AssumeRole"
}
]
}
とし ~/.aws/config を作成して
[profile ec2-role-b]
role_arn = arn:aws:iam::XXXXXXXXXXXX:role/EC2RoleB
credential_source=Ec2InstanceMetadata
とすれば
profileでec2-role-b
を指定して、EC2上で実行してみます。
まずは、通常通りEC2上で認証の確認
$ aws sts get-caller-identity
{
"Account": "XXXXXXXXXXXX",
"UserId": "HOGEHOGE:<<インスタンスID>>",
"Arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/EC2RoleA/<<インスタンスID>>"
}
EC2に割り当てられたRoleが使用されています。 profileを指定して
$ aws sts get-caller-identity --profile ec2-role-b
{
"Account": "XXXXXXXXXXXX",
"UserId": "XXXXXXXXXXXX:botocore-session-1234567890",
"Arn": "arn:aws:sts::XXXXXXXXXXXX:assumed-role/EC2RoleB/botocore-session-1234567890"
}
EC2に割り当てたRoleAを使ってRoleBにスイッチロールできました! RoleAは権限なし、RoleBにS3の読み取り権限をつけて、実行などして、確認してみてください。
まとめ
当然ですが、共有アカウントのような使い方は推奨しません(勘のいい子は嫌いだよ 適切に権限を割り当て、複数のAWS環境へのサービスや、権限を一時的に割り当てたいとかにIAMRoleがごちゃごちゃになることは避けられそうです。