Systems Manager Run command - ssm run command
Using Run Command, a tool in AWS Systems Manager, you can remotely and securely manage the configuration of your managed nodes. A managed node is any Amazon Elastic Compute Cloud (Amazon EC2) instance or non-EC2 machine in your hybrid and multicloud environment that has been configured for Systems Manager.
(引用元 上記リンク)
次の文章はgeminiにより生成
SSM Run Command（AWS Systems Manager Run Command）とは、AWS上にある仮想サーバー（EC2インスタンス）や、オンプレミスのサーバーに対して、SSHやRDPで直接ログインすることなく、安全かつリモートからコマンドを実行できる機能です。
「何台ものサーバーに一括でパッチを当てたい」「セキュリティ上、サーバーへの直接ログインは禁止したい」といった運用上の課題を解決するために非常によく使われます。
RDPは人間がログインするので、少し用途が違うが、
SSHではなぜ良くないのだろうかを改めて整理する。
jenkins + ssh
Jenkins
↓ SSH
EC2
メリット
シンプル
多くのエンジニアが理解している
AWS 以外でも使える
デメリット
SSH 鍵管理が必要
22 番ポートを開ける必要がある
接続元のIP管理が必要
誰がいつ何をしたか？の管理がしにくくなる
小規模環境では十分実用的ですが、大規模運用になると管理負荷が上がります。
SSM run commandだと
SSH 鍵管理が必要
22 番ポートを開ける必要がある
接続元のIP管理が必要
誰がいつ何をしたか？の管理がしにくくなる
このようなデメリットをなくせる。
次のことが必要になる。
- SSM AgentをEC2に入れる。
- IAM ロールの準備。
- Systems Manager への HTTPS 通信経路
そしてさらに以下の２パターンがある。
IAM ユーザーでやる場合
[AWS外部 (オンプレなど)]
Jenkins (アクセスキーを保持)
↓
↓ AWS API (HTTPS / ssm:SendCommand) ※インターネット経由
↓
[AWS環境内]
SSM Run Command
↓
EC2 / オンプレサーバー
デメリット
鍵漏洩のリスク
漏洩するとどうなるか。
ssm:SendCommand だけに権限を絞っていたとしても、
ランサムウェアを実行し、管理下のサーバーすべてに一斉にコマンドを送り、データを暗号化して身代金を要求する、とかができちゃう。
IAM ロールでやる場合(推奨)
[AWS環境内]
Jenkins (IAMロール付与)
↓ AWS API (HTTPS) ※認証情報の管理不要
SSM Run Command
↓
EC2
デメリット
これに特有のデメリットはない。
上述の他の方法と共通するが、jenkinsそのものが乗っ取られた時に、
色々実行されてしまうというリスクは残る。
まとめ
以上を踏まえると、IAMユーザーを使っても鍵ローテなどができていればIAM ロールの場合とセキュリティリスクは大差ないように思えた（？）
以上