この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
2019/6/14更新 元のブログタイトルは「AmazonEC2RoleforSSMが非推奨になります」です。 ドキュメントから AmazonEC2RoleforSSM を非推奨とする文言がなくなっているため、タイトルを修正しました。 最新の情報については、ドキュメントを参照ください。
こんにちは、中川です。
これまでAWS管理ポリシーの AmazonEC2RoleforSSM を使用して、SystemsManagerでEC2のオペレーションをできるように許可していました。 しかし、AmazonEC2RoleforSSM は、許可している権限の範囲が広いので、将来的には AmazonEC2RoleforSSM の使用が非推奨となるアナウンスがありました。
Create an IAM Instance Profile for Systems Manager 原文
This approach of adding multiple required and optional IAM policies to an instance profile replaces the practice of using of a single managed policy, AmazonEC2RoleforSSM. While that policy supported all SSM Agent operations on an instance, the scope of its permissions was too broad for many operational scenarios. AmazonEC2RoleforSSM is no longer recommended and will be deprecated in the future.
Google翻訳
インスタンスプロファイルに複数の必須およびオプションのIAMポリシーを追加するというこのアプローチは、 単一の管理ポリシーであるAmazonEC2RoleforSSMの使用方法に代わるものです。このポリシーはインスタンス上のすべてのSSM Agent操作をサポートしていましたが、その権限の範囲は多くの運用シナリオにとっては広すぎるものでした。 AmazonEC2RoleforSSMは推奨されなくなり、将来は非推奨になります。
代わりにこれからは、新しいポリシー AmazonSSMManagedInstanceCore をベースに、ゼロからカスタムポリシーを作ることが推奨になるようです。 そこで AmazonEC2RoleforSSM と AmazonSSMManagedInstanceCore を比較して、何が変わったか見ていきたいと思います。
確認してみた
ポリシーのdiff差分をとりました。
$ diff -u AmazonEC2RoleforSSM.json AmazonSSMManagedInstanceCore.json
--- AmazonEC2RoleforSSM.json 2019-06-11 09:05:22.000000000 +0900
+++ AmazonSSMManagedInstanceCore.json 2019-06-11 09:05:12.000000000 +0900
@@ -9,6 +9,7 @@
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:GetManifest",
+ "ssm:GetParameter",
"ssm:GetParameters",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
@@ -42,53 +43,6 @@
"ec2messages:SendReply"
],
"Resource": "*"
- },
- {
- "Effect": "Allow",
- "Action": [
- "cloudwatch:PutMetricData"
- ],
- "Resource": "*"
- },
- {
- "Effect": "Allow",
- "Action": [
- "ec2:DescribeInstanceStatus"
- ],
- "Resource": "*"
- },
- {
- "Effect": "Allow",
- "Action": [
- "ds:CreateComputer",
- "ds:DescribeDirectories"
- ],
- "Resource": "*"
- },
- {
- "Effect": "Allow",
- "Action": [
- "logs:CreateLogGroup",
- "logs:CreateLogStream",
- "logs:DescribeLogGroups",
- "logs:DescribeLogStreams",
- "logs:PutLogEvents"
- ],
- "Resource": "*"
- },
- {
- "Effect": "Allow",
- "Action": [
- "s3:GetBucketLocation",
- "s3:PutObject",
- "s3:GetObject",
- "s3:GetEncryptionConfiguration",
- "s3:AbortMultipartUpload",
- "s3:ListMultipartUploadParts",
- "s3:ListBucket",
- "s3:ListBucketMultipartUploads"
- ],
- "Resource": "*"
}
]
}変更箇所は以下のとおりです。
- AmazonSSMManagedInstanceCore に以下のActionが追加
- "ssm:GetParameter"
- AmazonEC2RoleforSSM から以下のActionが削除
- "cloudwatch:PutMetricData"
- "ec2:DescribeInstanceStatus"
- "ds:CreateComputer"
- "ds:DescribeDirectories"
- "logs:CreateLogGroup"
- "logs:CreateLogStream"
- "logs:DescribeLogGroups"
- "logs:DescribeLogStreams"
- "logs:PutLogEvents"
- "s3:GetBucketLocation"
- "s3:PutObject"
- "s3:GetObject"
- "s3:GetEncryptionConfiguration"
- "s3:AbortMultipartUpload"
- "s3:ListMultipartUploadParts"
- "s3:ListBucket"
- "s3:ListBucketMultipartUploads"
CloudWatch や S3 のポリシーがなくなっていることがわかりました。 AmazonEC2RoleforSSM でこれらのアクションを使用している場合、AmazonSSMManagedInstanceCore と別に必要なポリシーを割り当てて許可していく必要があります。
さいごに
AmazonEC2RoleforSSMは将来的に非推奨になり、AmazonSSMManagedInstanceCoreをベースにカスタムポリシーを作ることが推奨されるようになります。 運用の負荷は増えますが、IAMのベストプラクティスとしてポリシーは最小権限を付与するべきですので、この変更自体はもっともだと思います。 AmazonEC2RoleforSSMが急に使用できなくなることはないでしょうが、これを機会にEC2のポリシーを見直すと良いのではと思いました。
8
