AWS (HAProxy/Solr、PGPool/PostgreSQL) で稼働しているクラスターがいくつかあり、S3 に保持されている構成ファイルに IP を更新し、マスター インスタンスに SSH 接続して、修正された構成をダウンロードしてサービスを再起動することで、新しいスレーブ インスタンスがクラスターに自動的に含まれるようにスクリプトを設定しました。すべてうまく機能していますが、テストでは SSH にマスター pem を使用しているため、インスタンスに保存する必要があります。これは良くありません。
AWS キーペアを使用でき、download-config-and-restart スクリプトを実行するための sudo アクセスのみを持つ非ルート ユーザーが必要です。rbash が最適な方法のようですが、正しく設定しないと安全でない可能性があると理解しています。
では、このアプローチにはどのようなセキュリティホールがあるのでしょうか。
- user.pem 用に作成された新しい AWS キーペア (実際には「user」とは呼ばれません)
- インスタンスの新しいユーザー: user
- ユーザーの公開鍵は ~user/.ssh/authorized_keys にあります (user.pem を使用して新しいインスタンスを作成し、/root/.ssh/authorized_keys からコピーして取得します)
- ユーザーの秘密鍵は ~user/.ssh/user.pem にあります。
- 'user' のログインシェルは /home/user/bin/rbash です
- ~user/bin/ には /bin/rbash と /usr/bin/sudo へのシンボリックリンクが含まれています。
- /etc/sudoers には「user ALL=(root) NOPASSWD: [スクリプトへのパス]」というエントリがあります。
- ~user/.bashrc は PATH を /home/user/bin/ のみに設定します
- ~user/.inputrc には、パスを見つけるために 'sudo /' からダブルタブで入力するのを防ぐ 'set disabled-completion on' があります。
- ~user/ -R は、user への読み取り専用アクセス権を持つ root によって所有されています。ただし、~user/.ssh は、user への書き込みアクセス権 (known_hosts への書き込み用) を持ち、~user/bin/* は +x です。
- インスタンス間通信では、「ssh -o StrictHostKeyChecking=no -i ~user/.ssh/user.pem user@[host] sudo [scriptname]」を使用します。
ご意見は何でも歓迎します。
マーク...
答え1
わかりました。誰かがユーザー ログインに侵入すると、ユーザーの PEM キーが取得されるという事実を除いて、これがひどく露出しているという回答はありません。これにより、他の場所にアクセスできなくなるはずです*。
上記のアプローチで動作しています。
*通常の注意事項が適用されます