AWS SSM Default Host Management Configurationの登場でEC2インスタンスにアタッチするポリシーの考え方・運用はどう変わる?

quiver

2023.03.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2023年2月中旬にAWS Systems Manager Default Host Management Configuration(SSM DHMC)という機能がリリースされました。

本機能を利用すると、EC2のインスタンスプロファイルにSSM系権限を付与することなく、セッションマネージャーなどのSSM管理機能を利用できるようになります。

最新のSSM Agent(バージョン>=3.2.582.0)でしか動作しないため、現時点での一括導入は難しいですが、AMIの更新やSSMエージェントのアップデートなど時間の経過とともに、EC2インスタンスはDHMCでSSM管理するのが主流になるはずです。

SSM DHMCが当たり前な世界になると、EC2インスタンスにアタッチしている権限の運用はどう変わるでしょうか?

SSM DHMC登場前

SSM DHMC登場前であれば、次のようなポリシーを用意し、EC2インスタンスプロファイルのIAMロールにアタッチすることが一般的でした。

SSM管理用のポリシー(マネージドポリシーAmazonSSMManagedInstanceCoreなど)
アプリケーションが利用するS3権限などのポリシー

インフラ管理者がEC2インスタンスをSSM管理するための運用系ポリシーとアプリケーションが利用する開発系ポリシーが同じロールに同居しています。

運用と開発でチームが別れていて、開発チームがIAM権限を変更する敷居が高かったりすると、IAMポリシーの変更を伴うデプロイは一苦労です。

同じリソースを異なる役割の人が触ると、様々な問題が発生しがちです。

SSM DHMC登場後

SSM DHMC登場後はこの2つのポリシーがIAMロールレベルで分離されます。

EC2インスタンスプロファイルには、開発者がアプリケーション固有の権限を付与します(=開発チームに委任)。アプリケーションのコードから自動生成したポリシーに、おまじない的にSSM系ポリシーを付与する必要はありません。

管理者はSSM管理用のロールを用意し、DHMCに設定します。SSMの性質上、このロールに設定する権限がEC2インスタンスやアカウントごとに異なることは稀でしょう。 Organization全体や複数アカウント・リージョンに対してCloudFormation StackSetsでSSM DHMCを一括設定しましょう。

管理者はEC2のSSM運用に必要なIAMロールをOrganizationやアカウントレベルで管理し、開発者はアプリケーション固有のIAMロールを管理するため、互いに干渉せずにIAM運用できるようになります。

インスタンスプロファイルとDHMCのロールでポリシーがかぶっていても心配不要です。この2つのロールは併用可能で、DHMCロールはフォールバック的に動作します。結果的に、インスタンスプロファイルにあるSSM系ポリシーをSSM DHMCに移行するのも容易です。

Default Host Management Configurationのドキュメントには "This procedure is intended to be performed only by administrators." という記載があったり、DHMCにはSSMのアクションしか動作しないことなどから、このようなIAMの棲み分け運用を想定しているのではないかと予想します。

最後に

AWS Systems Manager Default Host Management Configurationを利用すると、EC2インスタンスに特別な権限を設定することなく、自動的にSSM管理できるようになります。

AWS管理者はSSM DHMCを活用してOrganizationやAWSアカウントといったグローバルな粒度でEC2インスタンスを自動的にSSM管理するようになり、SSM系権限が不要になったインスタンスプロファイルはアプリケーション固有のローカルな粒度で権限管理するよう、棲み分けが進んでいくのではないかと思います。

それでは。