Мы пытаемся сделать защищенный AMI для распространения одному из наших клиентов (под управлением Linux / CoreOS). После того, как наш клиент развернет наш AMI, важно, чтобы он не мог получить доступ к оболочке (например, не мог войти по SSH).
На первый взгляд, это кажется очень простой проблемой: просто убедитесь, что только наши ключи находятся в файлах authorized_keys. Однако, когда наш клиент развертывает наш AMI, он вынужден предоставить свою собственную пару ключей, а затем связанный открытый ключ вставляется в файл authorized_keys на коробке, что позволяет им использовать SSH в коробке.
Я знаю, что Amazon делает открытый ключ доступным (и метаданные пользователя) для ОС хоста через HTTP на 169.254.169.254 (информация здесь: 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. Я также предлагаю другой номер порта как простой способ убедиться, что все работает правильно.