インスタンスプロファイル作成とAWS Systems Managerの設定をAWS CLIを使ってやってみようとしたら、IAM ロールとポリシーとAssumeRoleでハマったのでやってみた順番で整理してみた
みなさんどうも、新卒エンジニアのたいがーです?
何が起こったのかと言いますと、タイトル通りです。AWS CLIでインスタンスプロファイルとAWS Systems Manager(以下、SSM)の設定をしようとして、とても詰まりました。
私が"どういうところにハマったか、どう解決したか"、実際の流れに沿って書いていきたいと思います。
そもそも何があったのか
始めは、AWS CLIを使ってCloud Formationのテンプレートからスタックを作成しようとしていました。
今回のテンプレートでは、スタック実行前にインスタンスプロファイルを作成する必要があったため、IAMロールを新たに作成しなければなりません。全てAWS CLIを使って済ませたかった私は、コマンドリファレンスの中からIAMロールを作成するコマンドを見つけ、実行しようとします。
しかし、このコマンドでは、assume role policy documentを用意した状態で実行する必要がありました。さて、インスタンスプロファイルに追加するIAMロールのassume role policy documentには何を書いたらいいのでしょう。
この答えを知るには、インスタンスプロファイルを知る必要があると思った私は調べ始めます。その後、IAMロールとインスタンスプロファイルを作成、IAMロールを追加。そしてついに、そのテンプレートからEC2インスタンスを起動することができました。
次に、作ったインスタンスにAWS Systems Manager(以下、SSM)を設定したいなと思ったのですが…インスタンスプロファイルに設定したIAMロールを変更しようとするとエラーが…そのエラー原因はすぐに分かったので、ようやくSSMが設定できそうだ…！
と思ったのに、やっぱりSSMの設定ができていない？！なぜ？！
とまぁこんな感じです。今は、SSMの設定も終了することが来ました。
今回、私が詰まった原因
様々な要因はあるものの、主な原因は"IAMポリシーとIAMロールの違いを明確に認識できていなかったこと"と"AssumeRoleへの理解が足りていなかったこと"の二つです。
私が悩んだ流れに沿って、順に復習していきたいと思います。が、その前に"IAMポリシーとIAMロールの違い"と"AssumeRole"をざっくり復習していきましょう。
IAMポリシーとIAMロールの違いについて
- IAM Policyは、できること/できないことを定義し、UserやRoleに紐付けて使う
- IAM Roleは、Policyを紐付けて、誰か/AWSのサービス ができることを定義する
IAMRoleにPolicyを紐付ける、という関係性を理解したあなたは、もう私と同じミスをしないはずです。
AssumeRoleについて
IAMロールに設定された権限を持った一時キーを入手することを「役割(role)の引き受け(assume)」と言います。
権限を持った一時キーを入手することで、操作することを可能にするということですね。
この2点を理解した上でここからを読み進めていただくと、すんなり理解できるはずです！それでは、どんどん振り返っていきましょう。
取り組んだことを振り返ろう
まずは、インスタンスプロファイルにおけるIAMロールの作成です。
インスタンスプロファイルにおけるIAMロール
そもそもインスタンスプロファイルとは何でしょうか。
インスタンスプロファイルは IAM ロールのコンテナであり、インスタンスの起動時に EC2 インスタンスにロール情報を渡すために使用できます。
『インスタンスプロファイルの使用』より
先ほども記載した通り、IAMロールは"Policyを紐付けて、誰か/AWSのサービス ができることを定義する"ことです。
今回は、他のリソースへの権限をつけないため、assume role policy documentはこのように記載します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
次に作成したドキュメントでIAMロールを作成します。
$ aws iam create-role --role-name role-for-ec2 --assume-role-policy-document file://assume-role-policy.json
次に、インスタンスプロファイルを作成し、それに先ほど作成したIAMロールを追加します。
$ aws iam create-instance-profile --instance-profile-name for-ec2 $ aws iam add-role-to-instance-profile --instance-profile-name for-ec2 --role-name role-for-ec2
これで、インスタンスプロファイルを作成できたので、CloudFormationからインスタンスを起動できました。
次はSSMを設定していきますが、ここで注意する点が一つあります。
インスタンスプロファイルに含めることができるIAMロールは一つだけ
インスタンスプロファイルに含めることができる IAM ロールは 1 つのみです。ただし、1 つのロールを複数のインスタンスプロファイルに含めることはできます。このインスタンスプロファイルあたり 1 ロールの制限は、緩和できません。既存のロールを削除してから、別のロールをインスタンスプロファイルに追加することはできます。
最初、私はこのことを知らなかったため、もう一つIAMロールを作成し、Instance profileにを追加しようとしたのですが、エラーが起こりました。
インスタンスプロファイルに追加しているIAMロール自体を変更する必要がありそうですね。先ほどのassume role policy documentを書き換えましょう。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ec2.amazonaws.com",
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
こうすることで、インスタンスがSSMに接続できるようにします。先ほど設定したrole policyを作り替えたJSONファイルにupdateします。
$ aws iam update-assume-role-policy --role-name role-for-ec2 --policy-document file://assume-role-policy.json
これでようやくSSMに接続できそうだと思い、マネジメントコンソールから確認してみましたが…いまだ表示されず。
最後にもう一つ、やることが残っていました。IAM ポリシーに関してです。
The first policy, AmazonSSMManagedInstanceCore, enables an instance to use AWS Systems Manager service core functionality.
"IAM Policyは、できること/できないことを定義し、UserやRoleに紐付けて使う"ということで、IAMロールにインスタンスがSSMのコア機能を使用できることを定義していきます。
$ aws iam attach-role-policy --role-name role-for-ec2 --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
もしここまでの手順でSSMの初期設定がうまくいかない場合は、下のエントリからご確認ください。
これでようやく、SSMを使うようにできました！
AWS CLIとマネジメントコンソールの違い
マネジメントコンソールで進めている時にはなんとなくで理解している部分が少なからずあります。
しかし、AWS CLIを使うことでより理解が深まるような気がするので、もっと使っていきたいなと思っています！
以上、たいがーでした?
