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/

さっそく使ってみましたが、サクサク動くし、コピーペーストによるコマンドの投入も可能です。
すごい!

ここでは、僕が気になったこと、ユースケースなどについて、記載します。

isd気になったこと

  • サーバーコンソールではない!
  • アクセス制御
  • ファイルのアップロードはできない
  • メモリ使用量

サーバーコンソールではない!

一見、他社の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エージョントサービスはデフォルトで起動しています。

isdユースケースなど

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の設定も必須にしたいと思います。
 

Follow me!