はじめに

本投稿ではSystemsManagerの機能の一つであるDefault Host Management Configration(DHMC)を使って、EC2インスタンスにIAMロールをアタッチせずにマネージドインスタンス化する方法について解説したいと思います。

IAMロールなしでとタイトルに冠しましたが、厳密にはインスタンスプロファイルにSSM操作用のIAMロールをアタッチすることなしでとなります。
DHMC用にIAMロールは用意する必要がありますのでご了承ください。

Default Host Management Configration(DHMC)とは

詳細は上記ドキュメントの通りですが、端的に言うとEC2にIAMロールがアタッチされていない場合に、デフォルトで使用されるIAMロールを指定しておける機能になります。
※より厳密な機能の仕組みについては後述します。

こちらの機能を使用するためには下記の制約があります。

DHMCを使用する際の制約

* SSM Agent バージョン 3.2.582.0 以降がインストールされていること
* インスタンスメタデータサービスバージョン 2 (IMDSv2) を使用していること

最初の制約であるSSM Agentですが、使用するAMIによっては要件を満たすバージョンがインストールされていない場合があります。
将来的には最新のAMIを使えば問題なくなるとは思われますが、もしエージェントのバージョンが古い場合はインスタンス起動時にuserdataで更新してあげましょう。

userdata

#!/bin/bash
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
REGION_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//')
yum install -y https://s3.${REGION_NAME}.amazonaws.com/amazon-ssm-${REGION_NAME}/latest/linux_arm64/amazon-ssm-agent.rpm

systemctl restart amazon-ssm-agent

上記はGravitonベースのインスタンス向けにlinux_arm64用パッケージを指定しています。
お使いのインスタンスに合わせて適宜linux_amd64などに書き換えてください。

なお、DHMCを使用する場合でもSSM APIへの通信経路は必要となりますので、
インターネットゲートウェイ、NATゲートウェイ、VPCエンドポイント等は別途用意してください。

DHMCの有効化

今回はマネジメントコンソールからDHCMを有効化していきます。
Systems Managerコンソールからフリートマネージャーを選択し、デフォルトのホスト管理設定の構成を選択してください。

トグルボタンで機能を有効化します。
IAMロールを指定する必要がありますが、レコメンデーションに従って必要なロールを作成し設定しましょう。

これで完了です。
わずか数クリックで設定ができましたね。

今後アカウント内のEC2インスタンスが要件を満たすと自動的にマネージドインスタンスとして登録されます。

CLIから有効化したい、CloudFormation StackSetsで複数アカウントにまとめて設定したいという方は下記の記事を参考にしてください。

結局なにが嬉しいの？

さて、本記事を読んでいただいている方の中には、
EC2を自動でマネージドインスタンスに、ってSSMのQuickSetupで元々できましたよね？🤔
と思われた方もいるかもしれません。

では、QuickSetupではなくDHMCを使うことでなにが嬉しいのかというと、管理用（SSM用）のロールと開発用のロールを分離できる という点です。

ご存知の通り、EC2のインスタンスプロファイルに含めることができるIAMロールは1つのみで、この制限を増やすことはできません。

この制限下で開発をしていると何が起こるかというと、1つのIAMロールに管理用のポリシーと開発用ポリシーが同居することになります。
もし管理（運用）と開発を別々のチームが担当していた場合、このロールの変更に関する統制をとることが非常に困難になります。

そこで、

管理（運用）チーム : DHMC用ロール
開発チーム : インスタンスプロファイル用ロール

と管理する範囲を分離することでお互いに干渉することなく開発を進めることができます。

1つのインスタンスに2つのロールが紐付いてるということ？どちらの権限が優先されるの？

細かい話ですが、

インスタンスプロファイルに設定されたIAMロール
DHMCに設定されたIAMロール

が同時に存在する場合、どちらの権限が使用されるか気になった方もいるかと思います。

答えは、

SSM Agent は、デフォルトのホスト管理設定の許可を使用する前に、インスタンスプロファイルの許可の使用を試みます。インスタンスプロファイルで ssm:UpdateInstanceInformation オペレーションを許可すると、インスタンスはデフォルトのホスト管理設定のアクセス許可を使用しません。

とドキュメントにある通りとなります。

少しわかりにくいですので表にすると、

	EC2インスタンス	SSMに使用されるIAMロール
1	インスタンスプロファイルがアタッチされて`いない`	DHMCに設定されたIAMロール
2	インスタンスプロファイルがアタッチされて`いる` かつ ssm:UpdateInstanceInformation アクションが許可されて`いない`	DHMCに設定されたIAMロール
3	インスタンスプロファイルがアタッチされて`いる` かつ ssm:UpdateInstanceInformation アクションが許可されて`いる`	インスタンスプロファイルに設定されたIAMロール

といったような対応となります。
なお、2のようなケースでもSSM以外のサービス（例えばS3やLambdaへのアクセスなど）はインスタンスプロファイル側のロールの権限が参照されますのでご安心ください。

おわりに

いかがでしたか？

EC2をマネージドインスタンスにすることで、SessionManagerによる接続が可能になります。
以前に投稿したEC2 Instance Connect Endpointと合わせて、秘密鍵を使用せずにEC2インスタンスへ接続する選択肢としてぜひご検討いただければと思います。

無くそう、秘密鍵の管理。