Я создаю систему, похожую на поставщика облачных вычислений, с использованием привязок libvirt python.
Я хотел бы дать пользователям возможность указывать собственный образ виртуальной машины аналогично AWS.
Я хотел бы на лету сгенерировать пары ключей SSH и настроить виртуальную машину для аутентификации с открытым ключом.
Как лучше всего это сделать? Какие требования я должен наложить на указанный пользователем образ виртуальной машины, чтобы это работало?
Я думал о беспарольной учетной записи root, чтобы позволить моему программному обеспечению входить в систему и настраивать то, что необходимо, но это оставляет (короткий) промежуток времени, в течение которого каждый может войти в систему как root. Есть ли лучшие решения? Могу ли я отредактировать образ виртуальной машины перед ее запуском?
На практике мне нужно войти в систему, чтобы иметь возможность войти в систему и выполнить некоторые команды, прежде чем передавать их пользователю.
Редактировать:
Некоторые дополнительные детали:
Возможно, вам стоит попытаться не изобретать велосипед заново. Есть много фреймворков, которые сделают именно то, что вы хотите ... и даже бесплатных / с открытым исходным кодом. Попробуй посмотреть на облако или эвкалипт для двух таких сред.
Я решил это следующим образом:
Поскольку мне нужен был IP-адрес, назначенный виртуальной машине, и поскольку libvirt не предлагает средств для его получения (в отличие от VMWare, который предлагает набор инструментов VMWare для таких операций), я закончил настройку серийного номера (на гостевом компьютере). ) в канал tcp (на хосте) между виртуальной машиной и хостом, используя libvirt поддержка виртуальных устройств.
Затем простой сценарий оболочки на гостевой машине ожидает, пока IP-адрес не будет назначен данному интерфейсу, и записывает его на последовательное устройство. Когда TCP-сервер, находящийся на хосте, получает IP-адрес, он отправляет обратно его открытый ключ, который скрипт на гостевой машине считывает (опять же, из последовательного порта) и записывает обратно в правильный authorized_keys файл.
Это решение можно использовать без части обмена IP, при этом только гость будет читать ключ из последовательного порта при загрузке. Преимущества такого решения заключаются в том, что гостевую ОС не нужно настраивать с помощью заданного ключа (такие разные пары ключей можно использовать для разных «разделов» системы) и что она может определять, где его разместить; Обратной стороной является то, что гость должен быть настроен для запуска сценария.
Другое решение - смонтировать образ диска перед загрузкой виртуальной машины, используя что-то вроде libguestfs, скопируйте открытый ключ, размонтируйте его и загрузите гостя. Это решение предпочтительнее, чем TCP <-> SerialPort, но поскольку мне все равно нужен IP-адрес, я поступил наоборот.
Третье решение, предложенное ErikA в его первом комментарии, - позволить пользователю, создающему образ, выполнить всю настройку, предоставив ему ваш открытый ключ. Это, вероятно, лучшее (самое чистое и элегантное) решение для наиболее общего случая.