Назад | Перейти на главную страницу

Секреты начальной загрузки и аутентификация на VPS

Как мне получить первый секрет на облачном VPS?

Если я смогу подтвердить, что я говорю с VPS, я думаю, что это так, то достаточно легко безопасно отправить секрет по этому каналу. И когда у меня есть первый секрет, я могу подтвердить, что действительно разговариваю со своим новым блестящим сервером, и передать ему все остальные секреты, необходимые для работы. Итак, этот вопрос эквивалентен вопросу о том, как я должен аутентифицировать новый VPS.

(Обратите внимание, что я не спрашиваю, как я могу аутентифицироваться на VPS: это решается путем отправки открытого ключа на сервер, либо записанного в изображение, либо через какую-либо службу метаданных; открытые ключи не чувствительны, поэтому это нет проблем.)

Запись секретов в образ, который нужно загрузить, кажется неоптимальным, потому что теперь образ чувствителен, и начальные секреты будут использоваться каждым сервером при загрузке, пока я не создам новый образ.

Облачные провайдеры предоставляют услуги метаданных для каждого экземпляра на хорошо известном IP-адресе, что хорошо, за исключением одного: это делает виртуальную машину границей доверия, и трудно остановить любой случайный процесс от получения метаданных. Колин Персиваль отметил проблему и выпустил смягчение, но весь подход здесь заставляет меня нервничать. Я хотел бы использовать обычные инструменты Unix и разрешения для защиты секретов VPS и заставить всех злоумышленников, которые скомпрометировали процесс, использовать второй эксплойт для получения root.

Создание нового закрытого ключа на сервере, а затем подключение по SSH дает некоторые надежды, но как я могу подтвердить, что я обращаюсь к недавно подготовленному серверу, а не к промежуточному устройству, если я подключаюсь через общедоступный Интернет? AWS предлагает проверить вывод консоли, чтобы получить открытый ключ, что сработает, но меня отталкивает. Google Cloud предлагает туннель с аутентификацией для экземпляра, но IAP довольно тяжелый, и я не вижу в документации упомянутого варианта использования, где я ожидал бы этого; Мне кажется, что я использую не тот инструмент для работы.

Моей последней идеей было поместить ключ подписи в прикрепленное блочное хранилище, а затем сгенерировать сертификат для сервера. Это позволяет мне скрывать ключи от скомпрометированных процессов (при отсутствии локального повышения привилегий, но в этом случае я все равно ничего не могу сделать), и должно быть достаточно легко рассматривать это хранилище блоков как секретное, но, опять же, я чувствую себя неуклюжим . Что делать, если ключ подписи будет скомпрометирован? Что, если я захочу его повернуть? Конечно, это не может быть современным уровнем искусства; Я думал, что суть облачных вычислений в том, что я буду платить Amazon / Google / Microsoft, чтобы скрыть подобные ужасные операционные детали. (Я также уклоняюсь от вопроса о том, как этот ключ вообще попадает в блочное хранилище!)

Итак, что мне не хватает? Нетрудно получить секрет на новый VPS без необходимости хранить в секрете образы серверов, без того, чтобы этот секрет был доступен для чтения все VPS, а не рискуя отправить секрет человеку посередине, не так ли?