問題点～EC2に（恐らく）アドミン権限が付与されている～

EC2からS3にファイルをアップしたり削除したり、東京リージョンにあるインスタンス一覧を表示したりできるようにしてある。
しかし、aws configureでAdministratorAccessポリシーが付与されているiamユーザのアクセスキー、シークレットキーを登録してしまっているのだ。
これだとEC2からAWS全サービスにアクセスできてしまうのでは？
あとでaws configureについてもっと調べるが、現状はよろしくない。
なのでaws configureで登録したデータを初期化し、必要な権限をロールで付与することにする。

ちなみにEC2に付与するIAMロールにベストプラクティスというのはあるのだろうか。
ちょこっと調べたが、どうやら必要最小限の権限を付与するのがよいようだ。
IAM ロールを作成するとき、アプリケーションが必要とする特定の API コールへのアクセスを制限する最小権限の IAM ポリシーを関連付けます。
https://console.aws.amazon.com/iam/home?region=ap-northeast-1#/groups/Administrators

作業記録

・ロール作成

ロール名：HdoraRoleForEC2
ポリシーアタッチ：AmazonS3FullAccess, CloudWatchAgentServerPolicy, AmazonSSMManagedInstanceCore

・対象EC2にアタッチ
略

考察

CloudWatchAgentServerPolicy, AmazonSSMManagedInstanceCoreはCloudWatchエージェント関連。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/create-iam-roles-for-cloudwatch-agent.html

S3はとりあえずはフルアクセスであけた。
今後、可能であれば徐々に権限を絞ってフルアクセスでの許可は避けたいところ。
細かく権限絞れるようになりたいな、そっちのほうがかっこいいし。

はじめ、セッションマネージャを許可する為AmazonEC2RoleforSSMもアタッチしていたが、外してもセッションマネージャできてしまう。
？と思い、ポリシーをオンオフして試していったが、どうやらAmazonSSMManagedInstanceCoreで許可しているようだ。
セッションマネージャ許可のポリシーってどれ使うのが正なのかしっかり調べたいところ。
高速セットアップで自動的に作られたロール「AmazonSSMRoleForAutomationAssumeQuickSetup」で今まで許可していたが、これはあまりよくないという記事も見かけるし。

課題は残ったものの、アドミン権限をEC2からはく奪できたのは大きい。
今後も理解を深めていこうと思う。