はじめに
皆さんはSystems Manager（以降SSM）を利用しているでしょうか。私はAWSを使ってWindows環境（ADとか）の検証をすることが多いのですが、SSMのFleet Managerをめちゃくちゃ愛用しています。
SSMは非常に便利なサービスですが、ハイブリッド環境でEC2をオンプレADにドメイン参加させる場合、注意が必要となります。本記事では、その注意点と対応方法についてまとめます。
Systems Managerの概要についてはこちら
Systems Manager概要
SSMは、AWSやオンプレ環境のサーバを一元的に管理・運用できるサービスです。SSMでサーバを管理するためには、対象のサーバをマネージドノードにする必要があります。マネージドノードにすることで、リモートコマンドを実行させたり、インバウンドポートを開けずにOSに接続したりと様々な機能を利用することができます。
マネージドノードのセットアップ
対象のノードをマネージドノードにするためには、下記の条件を満たす必要があります。
- SSM Agentがインストールされている
- SSM APIに対するアクセス経路が確保されている
- アクセスに必要な権限が付与されている
1. SSM Agentがインストールされている
マネージドノードにするためには、対象のサーバにSSM Agentがインストールされている必要があります。SSM AgentからSSM APIに対して通信（HTTPS）を行っているため、インバウンドの通信は発生しません。
一部のAMIにはSSM Agentがプリインストールされているため手動でインストールする必要はありません。それ以外のAMIやオンプレサーバでは手動インストールが必要です。
RHELなどSSM AgentがプリインストールされていないAMIの場合は、ユーザーデータを使ってEC2作成時にインストールさせることができます。インストールコマンドは、公式ドキュメントから確認することができます。なお、インターネットに対する通信が必要になるため、事前にNAT Gatewayの準備等を忘れずに実施してください。
2. SSM APIに対するアクセス経路が確保されている
SSM AgentがSSM APIに接続するため、アウトバウンドのアクセス経路が必要です。SSM AgentはHTTPSで通信するため、セキュリティグループではアウトバウンドの443通信を許可します。下記の2パターンでアクセス経路を確保します。
パターン① インターネット経由
グローバルIPで通信するか、NAT Gateway経由で接続します。
※EC2インスタンス、サーバー横の小さなアイコンがSSM Agent
パターン② VPCエンドポイント経由
VPCエンドポイント経由で接続することで、プライベートネットワークからの通信が可能です。
3. アクセスに必要な権限が付与されている
SSM APIに接続するためには、必要な権限を付与する必要があります。
方法① IAMロールをアタッチ
マネージドノードにするEC2にIAMロールをアタッチします。SSMの機能を使うためには、AmazonSSMManagedInstanceCore（必須）が必要です。その他、ユースケースに応じて追加のポリシーが必要となります。
オンプレミスサーバをSSMで管理する場合、EC2とは異なる作業が必要となります。作業の流れとしては、アクティベーションコードを作成し、SSM Agentのインストール時にコードを指定することで登録します。IAMロールは、アクティベーションコードを作成する際に指定します。必要な作業は異なりますが、SSMの利用に必要な条件自体は変わりません。
方法② DHMCを有効にする
DHMC（デフォルトのホスト管理設定）は明示的にEC2にロールをアタッチせずに、SSMによる管理ができるようにするための機能です。リージョン単位で、まとめてEC2に権限を付与することができます。
DHMCを利用するためには、次の前提条件を満たす必要があります。詳細は公式ドキュメントをご確認ください。
- IMDSv2を使用している
- SSM Agentのバージョンが 3.2.582.0 以上
EC2をオンプレADにドメイン参加させた場合の注意点
AWS環境を構築する際に、Direct ConnectやVPNでオンプレと繋げて利用することは良くある構成かと思います。そして、EC2をオンプレADにドメイン参加させることも多々あることでしょう。その際、VPCエンドポイント経由でSSMを利用するEC2でドメイン参加すると、SSMが利用できなくなります（インターネット接続がない場合）。
なぜADにドメイン参加させるとSSMが利用できなくなるのでしょう？理由は、SSMの名前解決でVPCエンドポイントのアドレスが返されないためです。SSM Agentでは下記のエンドポイントに対して通信を行います。（東京リージョンの場合）
- ssm.ap-northeast-1.amazonaws.com
- ssmmessages.ap-northeast-1.amazonaws.com
- ec2messages.ap-northeast-1.amazonaws.com
SSM Agentのバージョンが 3.3.40.0 以上であれば、ec2messages:*への通信はssmmessages:*が代替するため不要となります。
エンドポイントのアドレスを名前解決すると、VPCエンドポイントが存在しない環境では、グローバルIPが名前解決されます。以下はEC2からnslookupを実行した際の結果です。
ここで、対象のEC2が存在するVPCにエンドポイントを作成してみます。すると、EC2からnslookupを実行した結果、VPCエンドポイント（ENI）のプライベートIPアドレスが名前解決されるようになります。
実際にコンソール画面から作成したエンドポイントのENIを確認すると、返されたアドレスが一致していることがわかります。
このように、ユーザーが意識をしなくてもVPCエンドポイントを作成すると自動で名前解決で返されるアドレスが切り替わる（=インターネットに通信可能な環境でも自動でVPCエンドポイント経由での接続に切り替わる）ことがわかりますが、これを実現できるのはEC2がAmazonProvidedDNSで名前解決を行っているためです。AmazonProvidedDNSとは、EC2の名前解決先としてデフォルトで設定されているDNSサーバーのことで、VPCのCIDR+2のアドレス、169.254.169.253（全VPC共通）が該当します。
例）CIDRが10.0.0.0/16のVPCでは、10.0.0.2がAmazonProvidedDNSのアドレスとなる
しかし、EC2をオンプレADにドメイン参加すると、名前解決先がAmazonProvidedDNSからオンプレADに変わるため、名前解決時にVPCエンドポイントのアドレスが返されずSSMが利用できなくなってしまいます。ただし、AmazonProvidedDNSはVPC外からのDNSクエリをサポートしていないことに注意する必要があります。
対応方法
対応方法としては、大きく下記の3つがあります。AWSの公式ドキュメントでは、VPC外のネットワークからAWSリソースを名前解決したい場合は、Route 53 Resolverのインバウンドエンドポイントを作成するよう記載されており、基本的にはこの方法が推奨となります。
| 対応方法 | ユースケース | 注意点 |
|---|---|---|
| Route53インバウンドエンドポイントを利用する（推奨） | ・本番環境 ・オンプレからもAmazonProvidedDNSでの名前解決が必要なとき |
・インバウンドエンドポイントのコストがかかる |
| hostsファイルでエンドポイントのアドレスを設定する | ・検証や一時的な用途 ・EC2だけがSSMを利用すれば良いケースでコストを抑えたいとき |
・VPCエンドポイントの再作成でアドレスが変わるとhostsファイルの更新が必要 ・AWSドキュメントでは言及がなく、非推奨と思われる |
| NAT Gatewayを利用する | ・別の用途でNAT Gatewayを利用し、VPCエンドポイント経由で接続しなければならないという要件がないとき | ・インターネット経由での接続となる（VPCエンドポイント経由ではない） ・NAT Gatewayのコストがかかる |
Route53インバウンドエンドポイントの設定方法
Route53インバウンドエンドポイントは、[Route53]>[リゾルバー]>[インバウンドエンドポイント]から作成可能です。
Endpoint CategoryはDefaultとし、セキュリティグループ等の設定を行います。当然セキュリティグループでは、クエリ元からのUDP/53,TCP/53の許可が必要です。
インバウンドエンドポイントを設定後、対象のサーバーで条件付きフォワーダーを設定します。下記はVPNで接続した、Azure上のAD（DNS）での設定画面です。
上記問題なく設定ができれば、VPCエンドポイントのアドレスが返されます。
▼条件付きフォワーダー設定前
▼条件付きフォワーダー設定後
ちなみにですが、AmazonProvidedDNSを直接指定して名前解決を試みると、VPC外からのクエリのためタイムアウトになることが確認できます。
さいごに
最後までお読みいただきありがとうございました。ネットワークに強くなりたいです。