CloudWatch エージェント用にどちらのポリシーを使おうかな
コンバンハ、千葉（幸）です。
EC2 インスタンスに CloudWatch エージェントをインストールして使用する場合、EC2 インスタンスにアタッチされた（インスタンスプロファイルに関連づけられた）IAM ロールに必要な権限を与える必要があります。
CloudWatch エージェント用の AWS 管理ポリシーとしては以下２つが用意されています。
CloudWatchAgentAdminPolicyCloudWatchAgentServerPolicy
名前もよく似ているし、ポリシーの中身もそこまで大きな差異はありません。
果たしてこれらの違いは何なのか？どちらを選ぶべきなのか？ふと疑問に思ったため、少し調べてみました。
先にまとめ
CloudWatchAgentAdminPolicyとCloudWatchAgentServerPolicyの一番の違いはパラメータストアへの書き込み権限があるかどうか。Admin の方にのみある- パラメータストアへの書き込みを行うのは設定ファイルを他のサーバーに展開したい時。書き込み権限は、必要な時に限定されたサーバーでのみ持たせることが望ましい
- 書き込み権限は大抵の場合なくても困らないので
CloudWatchAgentServerPolicyを使おう
CloudWatch エージェントと関連コンポーネントのおさらい
少しだけ CloudWatch エージェントについておさらいしておきましょう。
ここでは、EC2 インスタンスに CloudWatch エージェントをインストールして使用するケースを想定します。（オンプレミスのサーバーに導入することも可能ですが、ここでは割愛します。）
CloudWatch エージェントをインストールしたインスタンスでは、エージェント用の設定ファイルが必要になります。CloudWatch エージェントからどこに対してどんな情報を出力するのか、などを定義するのが設定ファイルの役割です。
設定ファイルは JSON 形式で作成します。ウィザードに従って自動で生成することもできますし、独自に作成することもできます。
設定ファイルの管理には AWS Systems Manager のパラメータストアを用いるのが一般的です。ここに共通の設定ファイルを格納しておき、各インスタンスからそれを読み込ませる（ダウンロードさせる）ことで複数台に共通の設定を配布できます。場合によっては1台で作成した設定ファイルをパラメータストアに書き込む、ということもあるかもしれません。 *1
こういった、情報の出力やパラメータストアへの読み書きには然るべき権限が必要です。CloudWatch エージェントがインストールされたインスタンスに権限を与える必要があります。
そのためには、EC2 インスタンスにアタッチした IAM ロールに適切なポリシーを割り当てる必要があります。もちろん自身で独自のポリシーを作成してアタッチすることもできますが、あらかじめ AWS 側で用意された管理ポリシーを使う方が楽ちんです。その管理ポリシーとしてCloudWatchAgentAdminPolicyとCloudWatchAgentServerPolicyがあるため、何が違くてどちらを使うのがいいのか、というのが今回の話です。
CloudWatchAgentAdminPolicy と CloudWatchAgentServerPolicy の差分比較
それぞれ2024/06/28時点で最新のバージョンを用いて比較します。
CloudWatchAgentAdminPolicyバージョン2
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CWACloudWatchPermissions",
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"ec2:DescribeTags",
"logs:PutLogEvents",
"logs:PutRetentionPolicy",
"logs:DescribeLogStreams",
"logs:DescribeLogGroups",
"logs:CreateLogStream",
"logs:CreateLogGroup",
"xray:PutTraceSegments",
"xray:PutTelemetryRecords",
"xray:GetSamplingRules",
"xray:GetSamplingTargets",
"xray:GetSamplingStatisticSummaries"
],
"Resource": "*"
},
{
"Sid": "CWASSMPermissions",
"Effect": "Allow",
"Action": [
"ssm:GetParameter",
"ssm:PutParameter"
],
"Resource": "arn:aws:ssm:*:*:parameter/AmazonCloudWatch-*"
}
]
}CloudWatchAgentServerPolicyバージョン3
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "CWACloudWatchServerPermissions",
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"ec2:DescribeVolumes",
"ec2:DescribeTags",
"logs:PutLogEvents",
"logs:PutRetentionPolicy",
"logs:DescribeLogStreams",
"logs:DescribeLogGroups",
"logs:CreateLogStream",
"logs:CreateLogGroup",
"xray:PutTraceSegments",
"xray:PutTelemetryRecords",
"xray:GetSamplingRules",
"xray:GetSamplingTargets",
"xray:GetSamplingStatisticSummaries"
],
"Resource": "*"
},
{
"Sid": "CWASSMServerPermissions",
"Effect": "Allow",
"Action": [
"ssm:GetParameter"
],
"Resource": "arn:aws:ssm:*:*:parameter/AmazonCloudWatch-*"
}
]
}ポリシーの内容を変数に格納し、差分比較した結果は以下のとおりです。（ちょっと見づらいですね。）
% diff <(echo "$admin") <(echo "$server")
5c5
< "Sid": "CWACloudWatchPermissions",
---
> "Sid": "CWACloudWatchServerPermissions",
8a9
> "ec2:DescribeVolumes",
25c26
< "Sid": "CWASSMPermissions",
---
> "Sid": "CWASSMServerPermissions",
28,29c29
< "ssm:GetParameter",
< "ssm:PutParameter"
---
> "ssm:GetParameter"VS Code を使って差分を取ってみた画像が以下です。左が Admin の方のポリシーです。
SID の違いは権限には影響を及ぼさないので、実質的に差分は以下となります。
CloudWatchAgentAdminPolicyには……ssm:PutParameterの許可があるec2:DescribeVolumesの許可がない
注目すべきは前者のパラメーターストアへの書き込み権限です。 *2
書き込み権限は不必要に与えるべきではありません。どんな場合に必要になるのでしょうか。
CloudWatch エージェントでパラメータストアへの書き込みが必要になるのはどんな時？
考え方としては以下のドキュメントが参考になります。
ここでは以下の記述があります。
Parameter Store に書き込む機能は、広範で強力なアクセス許可です。このアクセス許可は、必要な場合にのみ使用します。デプロイの複数のインスタンスにアタッチしないでください。CloudWatch エージェント設定を Parameter Store に保存する場合は、以下をお勧めします。
- この設定を実行するインスタンスを 1 つセットアップします。
- このインスタンスでのみ Parameter Store への書き込みアクセス許可を持つ IAM ロールを使用します。
- CloudWatch エージェント設定ファイルの使用中および保存中のみ、Parameter Store への書き込みアクセス許可を持つ IAM ロールを使用します。
（中略）
Parameter Store への書き込みアクセス許可により、広範なアクセスが提供されます。このロールは、すべてのサーバーにアタッチせずに、管理者のみ使用できるようにします。エージェント設定ファイルを作成し、Parameter Store にコピーしたら、インスタンスからこのロールをデタッチし、代わりに
CloudWatchAgentServerRoleを使用してください。
特定のインスタンス（ここでは勝手に「代表インスタンス」と呼ぶ）で設定ファイルをカスタマイズしている。その設定内容が固まったら複数のインスタンスに同様の設定を展開したい。効率的に配布するために代表インスタンスから設定ファイルをパラメータストアに書きこみ *3、他のインスタンスはそれを読み取る。カスタマイズの役目を終えたら、代表インスタンスからは書き込み権限を剥奪する。という内容が示されています。
不要な書き込み権限を与えるべきではない、というのはしっくりきます。
そもそも、「代表インスタンス」を使わなくても事足ります。ローカル（作業者の端末など）で設定ファイルをカスタマイズし、ローカルからパラメータストアに格納する。インスタンスからはそれを読み取らせ、もしさらなるカスタマイズが必要であればローカルで修正後、同様の手順を繰り返す。というやり方もできます。（設定ファイルをウィザードから生成したい、という場合はローカルでの作業は少し難しくなるかもしれません。）
CloudWatch エージェントの機能としてパラメータストアに書き込みが必要なケースは無く、あくまで設定ファイルの管理においてのみ必要となります。上記で言う「代表インスタンス方式」を取りたい、ということでなければCloudWatchAgentAdminPolicyをアタッチする必要はないでしょう。
CloudWatchAgentAdminPolicy と CloudWatchAgentServerPolicy の歴史を確認
管理ポリシーは更新を加える度にバージョン管理されます。せっかくなのでそれぞれのポリシーの歴史を簡単に確認しておきます。
以下の AWS CLI コマンドを用います。
CloudWatchAgentAdminPolicyのバージョン履歴
% aws iam list-policy-versions \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentAdminPolicy \
--query 'Versions[*].{VersionId: VersionId, CreateDate: CreateDate, IsDefaultVersion: IsDefaultVersion}' \
--output table
----------------------------------------------------------------
| ListPolicyVersions |
+----------------------------+--------------------+------------+
| CreateDate | IsDefaultVersion | VersionId |
+----------------------------+--------------------+------------+
| 2024-02-05T20:59:57+00:00 | True | v2 |
| 2018-03-07T00:52:31+00:00 | False | v1 |
+----------------------------+--------------------+------------+2018年3月に初めて作成されています。この時点でメトリクスやログ出力、パラメータストアの読み書きなど主要な権限は揃っています。
2024年2月に更新が入り、この時には以下の権限が追加されています。
- CloudWatchロググループの保存期間を変更する権限
- X-Ray関連の権限
（↓左がバージョン1です。）
ここでの権限の追加は、それぞれ以下のアップデートに対応したものかと思います。
- 2022年2月：ログ保持期間設定機能
- 2023年8月：X-Ray対応
こうして見るとアップデート直後に AWS 管理ポリシーに反映されたわけではないですね。（特に、前者のログ保持期間の設定に必要なlogs:PutRetentionPolicyは長いこと「AWS管理ポリシーのみでは権限不足で追加でポリシー作成してアタッチが必要」と説明されていました。何ならすでに解消されたはずの2024年6月現在のドキュメントでもそう書いてあるように読めます。）
CloudWatchAgentServerPolicyのバージョン履歴
% aws iam list-policy-versions \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--query 'Versions[*].{VersionId: VersionId, CreateDate: CreateDate, IsDefaultVersion: IsDefaultVersion}' \
--output table
----------------------------------------------------------------
| ListPolicyVersions |
+----------------------------+--------------------+------------+
| CreateDate | IsDefaultVersion | VersionId |
+----------------------------+--------------------+------------+
| 2024-02-06T16:37:37+00:00 | True | v3 |
| 2019-10-17T23:08:51+00:00 | False | v2 |
| 2018-03-07T01:06:44+00:00 | False | v1 |
+----------------------------+--------------------+------------+2018年3月に新規作成され、2024年2月にアップデートが行われているのはCloudWatchAgentAdminPolicyと同じです。
間の2019年1月にも一度バージョンが更新されています。
（↓左がバージョン1です。）
CloudWatchAgentAdminPolicyとCloudWatchAgentServerPolicyの差分の一つであるec2:DescribeVolumesはこのタイミングで追加されていたようです。周辺のアップデートなど少しさらって見ましたが、それらしきものは確認できませんでした。（機能的に Server より Admin の方が劣後することは考えづらいので、何のためにあるんだろう……？と気になってます。）
バージョン2からバージョン3のアップデートの内容は、Admin の方と同様です。
（↓左がバージョン2です。）
余談：新しいとか最近って何を表すのだろう……？
先ほども取り上げたドキュメントでは、以下の記述があります。（太字はわたしによるもの。）
お客様にこれらのポリシーを自分で作成するよう求める代わりに、Amazon が作成した新しい
CloudWatchAgentServerPolicyおよびCloudWatchAgentAdminPolicyポリシーを使用して、最近以下の手順を変更しました。これらのポリシーを使用してエージェント設定ファイルを Parameter Store に書き込み、次に Parameter Store からダウンロードするには、エージェント設定ファイルの名前をAmazonCloudWatch-で始める必要があります。ファイル名がAmazonCloudWatch-で始まらない CloudWatch エージェント設定ファイルがある場合、これらのポリシーを使用してファイルを Parameter Store に書き込んだり、Parameter Store からファイルをダウンロードしたりすることはできません。
ここまで確認したようにCloudWatchAgentAdminPolicyおよび CloudWatchAgentServerPolicyは2018年3月の初回作成時からAmazonCloudWatch-から始まるパラメータへの読み取り（Adminの場合は加えて書き込み）権限を有しています。以降のポリシーバージョンの追加でも、ここの記述に合致するような変更はありません。
2020年8月まで遡っても同様の記述があり、「新しい」とか「最近」って何を指してるんだろう……とちょっと思いました。楽しいですね。
（↓Webアーカイブのリンクです。）
まとめ（再掲）
CloudWatchAgentAdminPolicyとCloudWatchAgentServerPolicyの一番の違いはパラメータストアへの書き込み権限があるかどうか。Admin の方にのみある- パラメータストアへの書き込みを行うのは設定ファイルを他のサーバーに展開したい時。書き込み権限は、必要な時に限定されたサーバーでのみ持たせることが望ましい
- 書き込み権限は大抵の場合なくても困らないので
CloudWatchAgentServerPolicyを使おう
終わりに
AWS 管理ポリシーCloudWatchAgentAdminPolicyとCloudWatchAgentServerPolicyは何が違うのか？どうやって使い分けるべきか？をまとめてみました。
大抵の場合はCloudWatchAgentServerPolicyを利用すればよさそうです。CloudWatch エージェントの設定ファイルを管理するような管理者が、特定のケースで使うのがCloudWatchAgentAdminPolicyと捉えておきましょう。
ふとした時に気になった方の参考になれば幸いです。
以上、 チバユキ (@batchicchi) がお送りしました。
3
