はじめに

こんにちはー
TIG DX Unit のゆるふわエンジニアの前原です。

突然ですが、Session Manager 使ってますか？調べるとブログがたくさん掲載されているので使っているところは多いのかな？って思っています。

また、ブログのタイトルを見ると以下のメッセージが多い印象を受けました。

さよなら踏み台サーバ
もういらない踏み台サーバ
..etc

なんか、可哀想になってきますね。。
とはいえ、こういったメッセージが多い理由としては、以下のメリットからだと考えられます。

踏み台サーバ不要でAWS リソースに容易にアクセスすることが可能
SSH のキー管理も不要で、IAM User と必要な権限が付与されていればアクセスできる
Security Group を意識しなくていい
操作ログも自動でCloudWatch Logs で取得される
CloudTrail では、セッションを張った時のイベントが取得される

仮に踏み台サーバを運用しようとすると上記のことを踏まえて構成、メンテナンスを行う必要があります。
これは、Session Manager を利用するのが必然に感じますね。

しかし、運用している踏み台サーバをSession Manager に移行するのは難しいところもあると思います。例えば、踏み台サーバに色々な役割を持たせているケースもあると思います（例えば、プロビジョニング用途など）。踏み台サーバの本来の役割的には、、と思った人もいると思いますが、現実は割とごった煮サーバになっているケースもあります。

そこで、踏み台サーバを生かしつつ、Session Manager を利用できる方法について説明したいと思います。

踏み台サーバとSession Manager の共存構成

ここで紹介する構成は、以下です。
下記の図に記載されているbastion serverは、踏み台サーバを指しています。

Session Manager を通してSSH で踏み台サーバへアクセス

ポートフォワードでRDS にアクセス

準備

サーバ側の準備とクライアント側の準備が必要になります。

サーバ側の準備

Session Manager のアクセス許可を行うため、対象のEC2（ここでいう踏み台サーバ）にAmazonSSMManagedInstanceCoreポリシを追加します。
もし必要なアクションのみを追加したい場合は、以下を追加します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetEncryptionConfiguration"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "key-name"
        }
    ]
}

踏み台サーバのSSM エージェントが2.3.672.0以上である必要があります。
もし古い場合は、ここのサイトを参考にしてください。
バージョンが古いとSession Manager を通してSSH で接続することができません。

クライアント側の準備

Session Manager plugin をインストールします。
前提として、AWS CLI が使用できることと、適切なIAM Policy がアタッチされていることを前提とします。

Mac インストール方法

プラグインをダウンロードします。

$ curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 4680k  100 4680k    0     0   174k      0  0:00:26  0:00:26 --:--:--  120k

ダウンロードしたファイルを解凍します。

$ unzip sessionmanager-bundle.zip
Archive:  sessionmanager-bundle.zip
   creating: sessionmanager-bundle/
   creating: sessionmanager-bundle/bin/
  inflating: sessionmanager-bundle/seelog.xml.template
  inflating: sessionmanager-bundle/LICENSE
  inflating: sessionmanager-bundle/VERSION
  inflating: sessionmanager-bundle/install
  inflating: sessionmanager-bundle/bin/session-manager-plugin

プラグインのインストールをします。

$ sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
Password:
Creating install directories: /usr/local/sessionmanagerplugin/bin
Creating Symlink from /usr/local/sessionmanagerplugin/bin/session-manager-plugin to /usr/local/bin/session-manager-plugin
Installation successful!

バージョンの確認をします。

$ session-manager-plugin --version
1.1.54.0

インストールが成功していると以下のメッセージが出力されます。

$ session-manager-plugin

The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.

SSH 設定ファイル（~/.ssh/config）に以下を追記します。

# SSH over Session Manager
host i-* mi-*
    ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

Windows インストール方法

ここでは、Windows にSession Manager Plugin をインストールする方法を記載します。

インストーラーをダウンロードする
インストーラーの指示に従う
インストールの確認のため以下のコマンドでバージョンが表示されたら完了

$ session-manager-plugin --version

SSH 設定ファイルに以下を追記する
- ファイル: C:\Users\username.ssh\config

# SSH over Session Manager
host i-* mi-*
    ProxyCommand C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p"

補足: プロキシ設定

$ export http_proxy=http://<USER_NAMEh>:<PASSWORD>@<PROXY_SERVER>:<PORT>
$ export https_proxy=https://<USER_NAMEh>:<PASSWORD>@<PROXY_SERVER>:<PORT>

Windows

$ set http_proxy=http://<USER_NAMEh>:<PASSWORD>@<PROXY_SERVER>:<PORT>
$ set https_proxy=https://<USER_NAMEh>:<PASSWORD>@<PROXY_SERVER>:<PORT>

実際にアクセスしてみる

今回の二つの構成でのアクセスを行なっていきたいと思います。

Session Manager を通してSSH で踏み台サーバへアクセス
ポートフォワードでRDS にアクセス

Session Manager を通してSSH で踏み台サーバへアクセス

まずは、踏み台サーバにSession Manager を通してアクセスしたいと思います。

$ ssh -i <KEY_NAME>.pem <USER_NAME>@<INSTANCE_ID>

通常のssh でアクセスするときと違う点としては、IP アドレスではなく、Instance ID を指定する点です。
ポートは、デフォルトの22 を指定するかたちで問題ありません（Security Group のInbound の22 を開ける必要はありません）
AWS マネジメントコンソール（HTTPS）へのアクセスが可能であればアクセスできます。

ポートフォワードでRDS にアクセス

ポートフォワードも通常のSSH で行う場合と同一のコマンドで行えます。
ここでは、PostgreSQL（5432）にアクセスするケースとします。

$ ssh -NL 15432:{DB_HOST}:5432 -i <KEY_NAME>.pem <USER_NAME>@<INSTANCE_ID>

アクセスできない場合

踏み台サーバにアクセスできず、以下のエラーが発生する場合は、SSM エージェントのサービス再起動をすると解消される可能性があります。
（前提としてポリシ周りの誤りがないこと）

The version of SSM Agent on the instance supports Session Manager, but the instance is not configured for use with AWS Systems Manager. Verify that the IAM instance profile attached to the instance includes the required permissions.

再起動コマンド

$ systemctl restart amazon-ssm-agent

ログについて

Session Manager を利用することで、CloudWatch Logs で操作ログの取得ができると冒頭で説明しました。
ただ、今回のSSH over Session Manager の構成では、CloudWatch Logs でログが出力されません。
したがって、Script コマンドで各ユーザの操作ログの取得が必要となります。
また、ポートフォワードした時は、Script コマンドにさえ残らないので、注意が必要です（これはSession Manager 云々の話ではないですが）
その場合は、CloudTrail のイベント（Session & Terminate）とRDS のAudit ログから証跡を辿る必要があります。

まとめ

いかがでしたでしょうか。
既存の踏み台サーバを残しつつ、Session Manager を利用する場合のケースについて書きました。
踏み台サーバを簡単になくすことが出来ない構成だけど、Session Manager を利用したいという人のお役に立てれば嬉しいです。
もし、完全に踏み台サーバを無くしたい場合は、PrivateLink などを利用した構成や、踏み台サーバに持たせている機能の移行などを検討するのも良いと思います。

Session Manager と踏み台サーバの共存構成