踏み台サーバーはもういらない。Ansible × SSM Session Manager で構築する「究極のセキュア管理術」
こんにちは。クラウドインフラの世界へようこそ。
インフラエンジニアとして現場に出ると、必ずと言っていいほどぶつかる壁があります。「プライベートサブネットにあるインスタンスをどうやって管理するか？」という問題です。昔ながらのやり方なら、そこに「踏み台サーバー（Bastion Host）」を立てて、SSHポート（22番）を開放して……と考えるでしょう。
しかし、それはもう過去の遺物です。
今日は、SSHのポートを開放することなく、AWSの強力なバックボーンを経由してAnsibleを流し込む「SSM Session Manager 経由の Ansible 実行」という、現代的かつ最高にセキュアな手法を伝授します。これをマスターすれば、セキュリティホールを塞ぎつつ、運用の自動化レベルが劇的に向上します。
—
1. なぜ「SSM Session Manager」なのか？
従来のSSH管理には、致命的な弱点があります。
- ポート22の開放: 攻撃の標的になりやすい。
- 鍵管理の煩雑さ: 秘密鍵の配布やローテーションが運用コストを圧迫する。
一方、AWS Systems Manager (SSM) Session Manager を使えば、インバウンドポートを一切開放する必要がありません。 インスタンスはAWSのSSMエージェントを通じてアウトバウンド通信を行うだけです。つまり、パブリックIPを持たない隔離された環境でも、安全にコマンドを叩けるのです。
—
2. 準備：魔法のコネクタを手に入れる
まずは、AnsibleがSSMを介して通信できるようにするための「コネクタ」を準備します。ローカルマシン（あなたのPC）に以下のツールをインストールしてください。
① AWS CLI & Session Manager Plugin
すでにインストール済みの方も多いはずですが、念のため確認を。
セッションマネージャプラグインがインストールされているか確認
session-manager-plugin –version
インストールがまだなら、[AWS公式ガイド](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)を参考に導入してください。
② Ansible の準備
`pip` でサクッとインストールします。
pip install ansible
—
3. インスタンス側のセットアップ（最重要）
Ansibleを動かす対象のインスタンスには、「SSMエージェント」と「適切なIAMロール」が必須です。
1. IAMロール: インスタンスにアタッチするロールに `AmazonSSMManagedInstanceCore` ポリシーを付与してください。これが「SSMで管理してもいいよ」という証明書になります。
2. SSM Agent: Amazon Linux 2 / 2023 なら最初から入っています。Ubuntu等ならインストールを忘れずに。
—
4. Ansible で SSM を叩く：HelloWorld的な設定
ここが一番の肝です。Ansibleの設定ファイル（`ansible.cfg`）に、SSMをSSHの代わりに使う設定を書き込みます。
`ansible.cfg`
プロジェクトのルートに配置してください。
[defaults]
SSHの代わりにaws ssmコマンドを呼び出す設定
ansible_ssh_common_args = ‘-o ProxyCommand=”aws ssm start-session –target %h –document-name AWS-StartSSHSession –parameters portNumber=%p”‘
`inventory.ini`
対象のインスタンスIDをインベントリに記述します。IPアドレスではなく「Instance ID」を書くのがポイントです。
[webservers]
i-0123456789abcdef0 ansible_user=ec2-user
—
5. 動作確認：ファースト・コンタクト
準備は整いました。以下のコマンドを叩いてみてください。
ansible webservers -i inventory.ini -m ping
「pong」 と返ってきましたか？
もし返ってくれば、あなたのローカルマシンから、プライベートサブネット内のインスタンスに対して、SSHポートを開放することなくAnsibleが通ったことになります。
—
現場で震えるほど役立つアドバイス
この手法を使いこなすと、次のようなメリットが待っています。
1. セキュリティ監査の簡略化: 22番ポートを開放していないため、セキュリティグループのルールが劇的にシンプルになります。
2. ログの一元管理: SSM経由の操作はすべてCloudWatch LogsやS3に記録可能です。「誰がいつ何をしたか」が完全に追跡できます。
3. マルチクラウド/ハイブリッド構成への拡張: 将来的にも、Ansibleの柔軟な接続設定を変えるだけで、管理対象を横断的に扱えるようになります。
最後に
最初は少し複雑に見えるかもしれませんが、一度この仕組みを作ってしまえば、あなたはもう「踏み台サーバーの死活監視」や「SSH鍵の配布」という退屈な作業から解放されます。
インフラは「自動化」と「セキュリティ」のバランスが全てです。このSSM構成はその理想形に近い一つの回答。ぜひ、あなたの現場でも試してみてください。
何か詰まったら、いつでも聞きに来てくださいね。応援しています！