はじめに
Azureで仮想マシンへの接続に対してネイティブサービスではSSH 以外で接続することができません。Azure Bastionでも結局のところはSSHで接続は捨てることができません。あくまでも踏み台という立ち位置です。
そこで、AWS Systems Manager Session Manager を利用します。Session Manager ではオンプレミスインスタンス管理が行えます。この機能を利用します。
ただし、EC2の管理とはことなりSystems Manager アドバンスドインスタンスへアカウントレベルを変更にする必要があり、これは従量課金制になっています。
従量課金制ではあるものの1時間単位で変更して課金を節約することが可能です。これは常時立ち上げが必要となるAzure Bastion では行えないところでもあります。
Azure環境をオンプレミスに見立てただけです。ドキュメントに沿って設定を行っていきます。
構成としてはAzureへの接続管理はSession Managerが行います。仮想マシンにはSSM Agentをインストールする必要があります。当然これらの経路もTLS1.2による暗号化がなされています。
前提
検証にあたり以下の環境が前提として必要になります。
- AWSのアカウントがあること
- Azureのアカウントがあること
- クライアント側でAWS CLIがセットアップされて、CLIによるアクセスが可能であること
AWS Systems Managerの設定
Systems Managerでハイブリッドアクティベーションを行う必要があります。これはリージョンに対して行われます。ap-northeast-1で設定しています。
とりあえず1台だけ接続するので、そのままの設定でアクティベーションを行います。実行ロールも作成されるように設定されています。
作成が完了するとActivation CodeとActivation IDが発行されるのでコピーしておきます。これはSSM Agentを設定するために利用されます。
新しいアクティベーションが正常に作成されました。 アクティベーションコードを以下に記載します。このコード、IDに再度確認することはできないため、コピーして安全な場所に保存してください。
Activation Code xxxxxxxxxxxxxxxxxxx
Activation ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
次に仮想マシンでSSM Agentをインストールします。
仮想マシンの設定
仮想マシンを起動し、SSM Agentをインストールします。検証用はUbuntuを利用しています。
検証のため外部からのアクセスを行う必要がありパブリックIPアドレスは付与していますが、VNET内からアクセスできる場合には付与する必要はありません。
SSM Agentがドキュメントに従いインストールします。
インストールにはdebパッケージを利用しています。activation-cod、activation-idは上記で確認したコードとIDを入力します。regionはアクティベーションを行ったap-northeast-1です。
mkdir /tmp/ssm curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.deb -o /tmp/ssm/amazon-ssm-agent.deb sudo dpkg -i /tmp/ssm/amazon-ssm-agent.deb sudo service amazon-ssm-agent stop sudo -E amazon-ssm-agent -register -code "activation-code" -id "activation-id" -region "region" sudo service amazon-ssm-agent start
実行結果
root@vm1:~# mkdir /tmp/ssm
root@vm1:~# curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_amd64/amazon-ssm-agent.deb -o /tmp/ssm/amazon-ssm-agent.deb
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 29.4M 100 29.4M 0 0 61.3M 0 --:--:-- --:--:-- --:--:-- 61.2M
root@vm1:~# sudo dpkg -i /tmp/ssm/amazon-ssm-agent.deb
Selecting previously unselected package amazon-ssm-agent.
(Reading database ... 60359 files and directories currently installed.)
Preparing to unpack /tmp/ssm/amazon-ssm-agent.deb ...
Preparing for install
-> Systemd detected
active
Failed to stop amazon-ssm-agent.service: Unit amazon-ssm-agent.service not loaded.
Unpacking amazon-ssm-agent (3.2.582.0-1) ...
Setting up amazon-ssm-agent (3.2.582.0-1) ...
Starting agent
Created symlink /etc/systemd/system/multi-user.target.wants/amazon-ssm-agent.service → /lib/systemd/system/amazon-ssm-agent.service.
root@vm1:~# sudo service amazon-ssm-agent stop
root@vm1:~# sudo -E amazon-ssm-agent -register -code "xxxxxxxxxxxxxxxxxxx" -id "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" -region "ap-northeast-1"
Error occurred fetching the seelog config file path: open /etc/amazon/ssm/seelog.xml: no such file or directory
Initializing new seelog logger
New Seelog Logger Creation Complete
2023-02-18 13:44:30 WARN Could not read InstanceFingerprint file: InstanceFingerprint does not exist
2023-02-18 13:44:30 INFO No initial fingerprint detected, generating fingerprint file...
2023-02-18 13:44:31 INFO Successfully registered the instance with AWS SSM using Managed instance-id: mi-0459cca9688f0a039
root@vm1:~# sudo service amazon-ssm-agent start
完了するとSession Managerで登録されたことがわかります。
仮想マシンに接続する
確認のためAWSコンソールからセッションを開始してみたいと思います。
フリートマネージャー、もしくはセッションマネージャーの画面からセッションを開始してみます。
セッションを開始するためには、アドバンスドインスタンスティアの有効化を行う必要かあり設定の変更のダイアログが表示されます。有効化します。有効化により課金が開始されることに注意してください。
有効化を確認したらセッションを再度開始します。
セッションが開始されると「$」だけが表示されるの bash を実行します。見慣れたAzureの仮想マシンにSSHで接続したときの画面になります。ただし接続ユーザーがssm-userになっていることに注意しましょう。
以上、ブラウザでのセッションの確立が確認出来ました。
次にAWS CLIで接続してみましょう。検証ではWSLから接続を行っています。インスタンスIDはセッションマネージャーの画面で確認できるものです。
aws ssm start-session --target "インスタンス ID"
実行結果
root@DESKTOP-FI2UMJO:~# aws ssm start-session --target mi-0459cca9688f0a039 Starting session with SessionId: azureuser-0bc6c5a59d3eb4e67 $ bash ssm-user@vm1:/usr/bin$ sudo -i root@vm1:~# ll total 36 drwx------ 6 root root 4096 Feb 18 14:10 ./ drwxr-xr-x 19 root root 4096 Feb 18 13:09 ../ drwx------ 2 root root 4096 Feb 18 13:45 .aws/ -rw------- 1 root root 412 Feb 18 14:01 .bash_history -rw-r--r-- 1 root root 3106 Oct 15 2021 .bashrc drwxr-xr-x 2 root mdatp 4096 Feb 18 14:10 .osquery/ -rw-r--r-- 1 root root 161 Jul 9 2019 .profile drwx------ 2 root root 4096 Feb 18 13:09 .ssh/ -rw-r--r-- 1 root root 0 Feb 18 13:43 .sudo_as_admin_successful drwx------ 3 root root 4096 Feb 18 13:09 snap/ root@vm1:~#
問題なく仮想マシンに接続できていることがわかります。
課金の停止
課金を停止するためにはアドバンスドインスタンスティアからスタンダードインスタンスティア（標準インスタンス）に変更する必要があります。
AWSコンソールではフリートマネージャーで行うことができます。インスタンス枠の設定で行います。
ダイアログが表示されるので同意して変更します。
同様にアドバンスドインスタンスティアに変更も行えます。
AWSコンソールで変更は都度ログインが必要なので面倒です。そこでCLIで行ってみます。
update-service-settingで変更することができます。
スタンダードインスタンスティアへの変更、ARNのリージョンやアカウントIDは環境に合わせて変更してください。
aws ssm update-service-setting --setting-id arn:aws:ssm:ap-northeast-1:xxxxxxxxxxxx:servicesetting/ssm/managed-instance/activation-tier --setting-value standard
特に変更されたことは表示されません。get-service-setting で確認します。ドキュメントなどには30後ぐらいに確認してくださいとありますが5分もかからず反映されていたように思います。
aws ssm get-service-setting --setting-id arn:aws:ssm:ap-northeast-1:xxxxxxxxxxxx:servicesetting/ssm/managed-instance/activation-tier
実行結果
SettingValueがstandardになっていることが確認できれば課金は停止されます。
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/activation-tier",
"SettingValue": "standard",
"LastModifiedDate": "2023-02-19T01:30:22.099000+09:00",
"LastModifiedUser": "arn:aws:iam::xxxxxxxxxxxx:user/azureuser",
"ARN": "arn:aws:ssm:ap-northeast-1:xxxxxxxxxxxx:servicesetting/ssm/managed-instance/activation-tier",
"Status": "Customized"
}
}
アドバンスドインスタンスティアに変更する
aws ssm update-service-setting --setting-id arn:aws:ssm:ap-northeast-1:xxxxxxxxxxxx:servicesetting/ssm/managed-instance/activation-tier --setting-value advanced
仮想マシンへの接続が必要な場合にadvancedに変更し、終わったらstandardに戻す運用を行えば費用の節約になります。
閉域網
Session Managerは閉域網に構築された環境への接続でも利用できます。
例えばパブリックIPアドレスやポートが開いていない状態でもSSM Agentが設定されているのであれば接続可能です。
これはAzure仮想マシンではパブリックIPアドレスを設定しなくても外部接続が利用できる既定のアウトバウンドアクセスの仕様によるものです。NATなども必要ありません。
まとめ
Azureでは簡単に実現できないSSH接続の断捨離ですが、AWS Systems Manager Session Managerを利用することで実現できます。AWS Systems Manager Session ManagerはAWSだけでなく、AzureやGoogle Cloud、オンプレミスなどへのSSH接続の代わりとなり一括で管理できるようになります。
Session Managerが利用できるようになった時からこのような使い方ができることは確認していましたが、面倒だったので意外とだれも記事にしないので。オンプレミス接続系の仕組みは色々と応用が利くので面白いと思います。