はじめに
こんにちは！
みなさんセッションマネージャーは使っていますでしょうか？
先日、社内OJTの1つの企画として新卒ちゃん達にAWSのハンズオンをしてもらいました。その時にセッションマネージャーを使ったEC2への接続で何名か躓いたので、今回はセッションマネージャーでEC2に接続できない時の対処法を整理しました。セッションマネージャーで接続できないと困っている人の助けになればと思います。
セッションマネージャーとは
簡単に言うと、SSHキーも踏み台サーバーも使わずに、しかもインバウンドルールも不要でEC2インスタンスに接続できてしまう神機能のことです。詳しくは公式ドキュメントをご覧ください。
と言いつつ仕組みのところだけ引用しておきます。
- ユーザーは IAM を通じて 自分のID と認証情報を確認します。
- ユーザーはSession Managerから SSH セッションを開始し、EC2 インスタンスに API 呼び出しを送信します。
- EC2 インスタンスにインストールされている AWS Systems Manager SSM エージェントは、Session Managerに接続してコマンドを実行します。
- 監査およびモニタリングの目的で、Session Manager はログデータを CloudWatch ログに送信します。あるいは、Amazon Simple Storage Service (Amazon S3) バケットに、ログデータを送信することもできます。
コンソールだと接続したいインスタンスにチェックを付けて、右上にある"接続"ボタンから接続画面に飛び、セッションマネージャータブを選んで、"接続"ボタンを押すと接続できます。
セッションマネージャーに接続できない時の確認ポイント
ということで本題です。
セッションマネージャーで接続できない時に確認するポイントを記載していきます。
仕組みに沿って確認していくと良いです。
ちなみに接続できない時は以下の画像のようになります。
1. AWS Systems Manager SSM エージェントがインストールされているか
1つ目はSSMエージェントがインストールされているかです。
仕組みでもありましたが、SSMエージェントがセッションマネージャーに接続してコマンドを実行するので、SSMエージェントがインストールされていないと接続できません。
SSMエージェントがインストールされているAMIを使用しましょう。Amazon LinuxなどSSM エージェントがプリインストールされている AMIは公式ドキュメントにまとまっています。
また、SSMエージェントが最新バージョンになっていない場合も動かないことがあるため、公式もSSM Agent の更新の自動化をオススメしています。
2. EC2インスタンスに必要なIAMロールがアタッチされているか
2つ目はEC2にIAMロールがアタッチされており、そのIAMロールにマネージドポリシーのAmazonSSMManagedInstanceCoreがアタッチされていることを確認します。
簡単に言うと、SSMエージェントからSSMへの疎通に関する権限とインスタンス内のSSMに関する情報の読み取りと更新に関する権限が記載されています。
マネージドポリシーを使用する時は内容を確認することをオススメします。
マネージドポリシーAmazonSSMManagedInstanceCoreの内容
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation",
"ssm:GetDeployablePatchSnapshotForInstance",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:GetManifest",
"ssm:GetParameter",
"ssm:GetParameters",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
"ssm:PutInventory",
"ssm:PutComplianceItems",
"ssm:PutConfigurePackageResult",
"ssm:UpdateAssociationStatus",
"ssm:UpdateInstanceAssociationStatus",
"ssm:UpdateInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2messages:AcknowledgeMessage",
"ec2messages:DeleteMessage",
"ec2messages:FailMessage",
"ec2messages:GetEndpoint",
"ec2messages:GetMessages",
"ec2messages:SendReply"
],
"Resource": "*"
}
]
}
3. EC2からSSMへアウトバウンド通信ができるか
3つ目はSSMとSSMエージェントの通信経路があるのか確認します。
この通信経路のパターンは、SSMエンドポイントを経由するパターン、NATゲートウェイを経由するパターン、インターネットゲートウェイを経由するパターンの3種類あります。
3種類とも共通して、EC2のセキュリティグループでアウトバウンドルールが許可されている必要があります。（セキュリティグループ作成時、デフォルトでアウトバウンドルールはフルアクセスになっており、あまり設定を変更しない点なので、一応確認するレベルです。）
SSMエンドポイント経由のパターン
この方法が1番セキュアな方法で、エンドポイント経由の通信となるため、インターネットを経由することなく、SSMとSSMエージェントが通信できます。
この時に作成が必要なエンドポイントは以下の2つです。
- ssm.region.amazonaws.com
- ssmmessages.region.amazonaws.com
この時、それぞれのSSMエンドポイントにアタッチするセキュリティグループのインバウンドルールに、EC2にアタッチするセキュリティグループからの許可があることを確認します。
NATゲートウェイ経由のパターン
こちらはNATゲートウェイを経由してインターネット経由でSSMとSSMエージェントが通信します。
この時、EC2を配置しているプライベートサブネットにNATゲートウェイへのルーティング設定がされていることを確認します。
（VPCを作成時にサブネットなども自動で作成してくれる機能でNATゲートウェイを作成した場合は、ルーティング設定も行ってくれています。VPC自動作成機能は便利ですよね！）
インターネットゲートウェイ経由のパターン
インスタンスをパブリックサブネットに置くことはあまりないかもしれないですが、パブリックサブネットにインスタンスがあるパターンです。
この時、EC2にパブリックなIPアドレスが付与されていることを確認します。
EC2作成時の自動割り当てでも、Elastic IPを使用してIPアドレスを固定しても大丈夫です。
見つけにくいですが、公式ドキュメントではここにネットワークに関する記載があります
おわりに
セッションマネージャーで接続できない時の確認項目についてまとめました。この記事により1人でも多くの人がセッションマネージャーで接続できるようになると嬉しいです。
接続できるようになった人は、ぜひ←のいいね♡を押していってください！よろしくお願いします！
ちなみに、Cloud9も接続時にセッションマネージャーを使っているようなので、Cloud9が接続できない時にも同じ点を確認してみてください。