AWS Systems Managerの新機能Session Managerで気になったこと
2018年9月、AWSより、Systems Managerの新機能である「Session Manager」がリリースされました。
簡単にいうと、
「SSH接続せずに、AWSマネジメントコンソール（もしくはAWSCLI）でEC2インスタンスのシェルを使用できる」
というものです。
使い方などは、以下のAWS公式ブログやクラスメソッドさんブログが詳しいです。
・AWS Systems Manager セッションマネージャーで EC2 インスタンスへのシェルアクセスを実現 – Amazon Web Services ブログ
https://aws.amazon.com/jp/blogs/news/new-session-manager/
・SSH不要時代がくるか!?AWS Systems Manager セッションマネージャーがリリースされました! – Developers.IO
https://dev.classmethod.jp/cloud/aws/ssm-session-manager-release/
さっそく使ってみましたが、サクサク動くし、コピーペーストによるコマンドの投入も可能です。
すごい！
ここでは、僕が気になったこと、ユースケースなどについて、記載します。
気になったこと
- サーバーコンソールではない！
- アクセス制御
- ファイルのアップロードはできない
- メモリ使用量
サーバーコンソールではない！
一見、他社のVPSサービスやクラウドサービスにあるような、サーバーコンソール機能に見えますが、そうではありません。
クライアントからは、サーバーに直接アクセスするのではなく、AWS上のどこかにあるSSM Managerサービスにアクセスします。
クライアント --> クラウド上のSSM Mangerサービス <-- SSMエージェント on EC2サーバー
サーバー上では、ネットワークサービスや、amazon-ssm-agentが正しく起動して、サーバーから「SSM Managerサービスへのアクセスを受け付けるAmazon SSMパブリックエンドポイント」へのアウトバウンドHTTPSアクセスが正しく行える必要があります。
ですので、例えば、
「何らかの原因（起動中のマウント失敗、ファイルシステムの障害など）でサーバーが正しく起動しないときに、サーバーコンソールに接続して、シングルユーザーモードで起動して調査、対応する」
というようなことはできません。
（サーバーが正しく起動しないときは、ネットワークサービスやssm-agentが起動していないと思われるため）。
この点で、Session Managerは、サーバーコンソール機能と同等ではありません。
アクセス制御
前述のとおり、サーバーからAmazon SSMパブリックエンドポイントへのアウトバウンドHTTPSアクセスが正しくできる必要があります。
試しに、セキュリティグループのアウトバウンド設定で、HTTPSへのアクセス許可ルールを削除してみると、セッションを開始しても、コマンドプロンプトが表示されませんでした。
ファイルのアップロードはできない
現時点では、SFTPのような機能はないようですので、クライアントからサーバーへのファイルをアップロードはできません。
今後、できるようになるかもしれませんね。
（2019.7.25追記）
2019年7月、セッションマネージャーでSSH、SCPできるようになりました。
これで、SSHポートを塞いだままファイル転送が可能となったので、運用がしやすくなりますね。
セッションマネージャーのSSHは、IAMユーザーのアクセスキーを使用しますので、アクセスキーの管理には十分注意しましょう。
（参考）
・AWS Systems Manager セッションマネージャーでSSH・SCPできるようになりました | DevelopersIO
https://dev.classmethod.jp/cloud/aws/session-manager-launches-tunneling-support-for-ssh-and-scp/
メモリ使用量
Session Managerを使用するには、サーバー上でSSMエージョントサービスが常時起動している必要があります。
SSMエージョントは、メモリを約20MBぐらい使用しています。
# ps aux | grep ssm-agent root 3551 0.0 2.1 623696 21400 ? Ssl 13:20 0:00 /usr/bin/amazon-ssm-agent
Session Managerでセッションを開始したときは、さらにworkerが17MBぐらい使用します。
# ps aux | grep ssm-session-worker root 3609 0.1 1.7 397916 17276 ? Sl 13:22 0:00 /usr/bin/ssm-session-worker root-0070680daae640daa
サーバーの搭載メモリに比べると少量で影響はほとんどないはずですが、メモリリソース管理にシビアな方だと、気になってしまうかもしれませんね。
なお、Amazon Linux 2では、SSMエージョントサービスはデフォルトで起動しています。
ユースケースなど
Session Managerは、
「サーバーシェルへのアクセス制御・認証として、SSHの機能（ポートへのAWSのIAMアクセス元IPアドレス、ユーザー、鍵認証など）のほかに、AWS IAMの仕組みを使えますよ」
ということですね。
シェル上の操作ログも、簡単な設定で、S3やCloudWatch Logsに保存できます。
SSHはセキュリティ上攻撃者に狙われやすい機能ですから、そのアクセス制御の設計・設定・管理は案外面倒です。
固定IPアドレスがなかったり、SSH鍵ペアを作成するのにひと苦労、というのもよくある話です。
これらが、IAMユーザーで管理できてしまうのは、シンブルで便利だと思います。
ただ、現時点ではファイルのアップロードが（おそらく）できないようなので、サーバー構築やアプリケーションデプロイがある程度自動化されていて、サーバーからのダウンロードで完結するしくみをもつプロジェクトでないと、「SSHからSession Managerへの完全移行」は難しいのではないでしょうか。
それでも、SSHとSession Managerの併用も、メリットはあると思います。
例えば僕も、AWSのサーバー構築作業において、iptablesやsshd_configの設定を行う際、
「万一この設定をミスって、SSH接続できなくなると、サーバーに一切アクセスできなくなってしまう」
と、ドキドキすることがたまにあります。
そうならないために、一定時間経過後に、iptablesの設定をクリアしたり、sshd_configを元に戻したりするよう工夫して作業したりするのですが、
「万一失敗してもSession Managerでシェルが使える」
と思うと、そういった工夫が不要ですし、安心感が違います。
また、SSHのアクセス元IPアドレスを限定している場合、緊急時に、自宅など、それ以外のネットワーク環境からもシェルを使用することができるのは便利ですね。
ということで、今後AWSのサーバー構築では、Session Managerの設定も必須にしたいと思います。
