私たちは、お客様の1人(Linux/CoreOSを実行している)に配布するための安全なAMIを作成しようとしています。お客様がAMIをデプロイしたら、シェルアクセスを取得できないことが重要です(たとえば、SSHで接続できません)。
一見すると、これは解決するのが非常に簡単な問題のように見えます。許可されたキーファイルにキーだけが含まれていることを確認してください。ただし、お客様がAMIを展開すると、独自のキーペアを提供する必要があり、関連付けられた公開キーがボックスのauthorized_keysファイルに挿入され、ボックスにSSHで接続できるようになります。
Amazonが169.254.169.254のHTTP経由でホストOSに公開鍵(およびユーザーメタデータ)にアクセスできるようにしていることを知っています(情報はこちら: http://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/ ec2-key-pairs.html )。インターネットとCoreOSファイルシステムに関する調査では、/ usr/bin/coreos-metadataが実際にこのIPにアクセスしていることが示唆されていますが、おそらくキーペアのために、その実行可能ファイルを実際に開始しているのか、それを無効にする方法がわかりません。実行可能特権を削除するか、完全に削除することも考えましたが、ファイルシステムのその部分はCoreOSでは読み取り専用です(rootに対しても)。
明らかに、上記の動作は、私たちが実施しているセキュリティ対策よりも優先されます。これを防ぐためにできることはありますか?
cloud-init
はこれを行っています。 sshd
の実行を無効にし(AMIビルドの一部)、ログインユーザーの下にキーを配置するスクリプトコードを実行し(別のキーをお勧めします)、ssh
を起動します。また、正常に動作していることを確認する簡単な方法として、別のポート番号をお勧めします。