AWS Systems Managerにて、セッションマネージャ経由でのSSH接続がリリースされ、従来の煩わしいSSH管理から開放される未来が見えてきました・・・！
今回はPrivateサブネット内のEC2インスタンスに対して本機能を設定する手順を、備忘の意味も込めてまとめます。
ちなみに、タイトルにもあるSSMは、Simple Session Managerの略らしいです。
なお、AWS CLIからSSM経由でPrivateサブネット内のEC2インスタンスにアクセスできる設定をすることで、よりセキュアに、ローカル環境からのCLI操作でEC2インスタンスにアクセスできるようになります。詳しくは以下記事参照ください。
事前準備
本記事は、事前に以下設定がされていることを前提とします。
(a) IAMユーザーの設定（各種IAMポリシー付与）
(b) VPC設定（DNS設定の有効化）
(c) Privateサブネット作成
(a) IAMユーザーの設定
本記事で取り上げるAWSサービス利用に必要なIAMポリシーが設定されていること。本来はもっと絞るべきですが、本記事では以下権限を付与しています。
- AmazonEC2FullAccess
- AmazonS3FullAccess
- AmazonSSMFullAccess
(b) VPC設定
後述の「VPCエンドポイントの作成」の際に必要となるため、Privateサブネットが所属するVPCにおいて、以下の２つが「有効」となっていることを確認する。「無効」の箇所があれば、VPCの「アクション」から有効化する。
- DNS解決 ← デフォルトで「有効」なはず
- DNSホスト名 ← デフォルトだと「無効」なため、VPC作成後手動で有効化する必要があるはず
(c) Privateサブネット作成
(b)の設定がされたVPC内に、Privateサブネットを作成する
- 作成後はルートテーブルから、IGW(インターネットゲートウェイ)へルーティングされていないことを確認すること
手順
(1) EC2にアタッチするIAMロール作成
「IAM」にて、EC2でSSMを利用するために必要な権限を持たせるため、以下手順でIAMロールを作成する。
- IAMロール作成画面にて「ロールの作成」をクリック
- 「ユースケースの選択」にて「EC2」を選択して、「次のステップ：アクセス権限」をクリック
- 「AmazonEC2RoleforSSM」を選択して、「次のステップ：タグ」をクリック
- 任意のタグ情報を設定して、「次のステップ：確認」をクリック
- 任意の「ロール名」を設定して、「ロールの作成」をクリック
(2) Privateサブネット内にSSMアクセス用のEC2インスタンスを作成
事前準備(c)で作成したPrivateサブネット内にEC2インスタンスを作成し、(1)で作成したIAMロールをアタッチする。
本記事では、「amazon-ssm-agent」が事前にインストールされている、以下AMIを用いてEC2インスタンスを作成した。
- amzn2-ami-hvm-2.0.20181114-x86_64-gp2 (ami-0a2de1c3b415889d2)
脱線だが、(2)の段階で「AWS Systems Manager」の「マネージドインスタンス」にアクセスをしても、(3)以降の処理をしていないため、初期設定画面が表示される。（マネージドインスタンスとして認識されるインスタンスがあると、一覧画面が表示される）
(3) VPCエンドポイントを作成する
「VPC」にて、PrivateサブネットでSSMを利用するために必要なサービス(ssm, ssmmessages, ec2messages, s3)に対して、それぞれ以下手順でエンドポイントを作成する。
なお、それぞれのエンドポイントは以下の役割を担う。
| エンドポイント | 種類 | 役割 |
|---|---|---|
| com.amazonaws."region".ssm | I/F | Systems Managerサービスのエンドポイント |
| com.amazonaws."region".ec2messages | I/F | Systems ManagerがSSMエージェントからSystems Managerサービスに呼び出しを行うために必要 |
| com.amazonaws."region".ssmmessages | I/F | Session Managerを使用し、安全なデータチャネルを経由してインスタンスに接続する場合に必要 |
| com.amazonaws."region".s3 | GW | Systems Managerが、SSMエージェントの更新や、S3バケットに保存する出力ログのアップロード、バケットに保存したスクリプトやその他のファイルの取得などのタスクを実行するために必要 |
(3-1) I/Fエンドポイントを作成(ssm, ssmmessages, ec2messages)
- 「VPC」の左メニューから「エンドポイント」をクリックしてエンドポイント画面に遷移
- 「エンドポイントの作成」をクリック
- 自身のリージョンによって、以下の対象サービス名を検索し、選択する
- com.amazonaws."region".ssm
- 東京リージョンだったら「com.amazonaws.ap-northeast-1.ssm」
- 事前準備(b)(c)のVPC、サブネットを選択する
- 「プライベートDNS名を有効にする」にチェックを入れる
- 事前準備(b)のDNS設定ができていないと、ここでチェックが入れられない
- 以下の要件を満たすセキュリティグループを選択する(必要に応じて作成)
- VPC/サブネット内のEC2インスタンスからの、HTTPS(443)での"インバウンド"トラフィックを許可
- 例） 「タイプ」を「HTTPS」、「ソース」を「VPCのCIDR表記」
- 「エンドポイントの作成」をクリック
- 上記2-7を繰り返し、以下サービスのエンドポイントを同様に作成する
- com.amazonaws."region".ssmmessages
- com.amazonaws."region".ec2messages
(3-2) GWエンドポイントを作成(s3)
- 「VPC」の左メニューから「エンドポイント」をクリックしてエンドポイント画面に遷移
- 「エンドポイントの作成」をクリック
- 自身のリージョンに対応するs3サービスを検索し、選択する
- com.amazonaws."region".s3
- 東京リージョンだったら「com.amazonaws.ap-northeast-1.s3」
- 事前準備(b)のVPCを選択する
- 事前準備(c)で作成したサブネットに関連付けられたルートテーブルを選択する
- ポリシーは「フルアクセス」を選択する
- 「エンドポイントの作成」をクリック
(4) 「AWS Systems Manager」からセッション開始
- 手順(3)を実施後、「AWS Systems Manager」の左メニューの「マネージドインスタンス」にて、手順(2)で作成したEC2インスタンスが認識されていることを確認する。
- SSMエージェントのバージョンは、認識される過程で「AWS-UpdateSSMAgent」が実施されるため最新版に更新される模様
-
「AWS Systems Manager」の左メニューの「セッションマネージャー」にて、「セッションの開始」をクリック
-
ターゲットインスタンスとして、手順(2)で作成したEC2インスタンスを選択し、「セッションを開始する」をクリック
-
セッションが開始され、コマンドが実行できることを確認する
- 【注意】ログインしたユーザーが「ssm-user」となっていますが、これはSSM経由でログインする際に利用されるユーザーとなります。本記事のIAMユーザーが「ssm-user」だからではありません(IAMユーザー名が適切ではなかったです。。)。
おまけ ： セッションログの保存設定
「AWS Systems Manager」の左メニューの「セッションマネージャー」の「設定」にて、ログの保存先を指定することができます。保存先としては「S3」と「CloudWatch Logs」を選ぶ、もしくは両方を指定することができます。
手順は、事前にS3のバケット、もしくはCloudWatch Logsのロググループを作成しておき、設定画面から対象サービスを選んで保存先を指定するだけです。
これにより、誰がSSM経由でEC2インスタンスにログインして何をやったのかのログを取得することができます。
