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

бродячая и марионеточная безопасность для ssl-сертификатов

Я новичок в vagrant, сможет ли кто-нибудь, кто знает об этом (и марионетке) больше, объяснить, как vagrant работает с ssl-сертификатами, необходимыми при создании машин vagrant-тестирования, которые обрабатывают то же определение узла, что и настоящие производственные машины?

Я запускаю марионетку в режиме ведущий / клиент, и я хочу развернуть бродячую версию своих узлов производства марионеток, в первую очередь для тестирования нового кода марионетки.

Если моя производственная машина, скажем, sql.domain.com, я запускаю бродячую машину, скажем, sql.vagrant.domain.com. Затем в бродячем файле я использую инициатор puppet_server и задаю запись puppet.puppet_node «sql.domain.com», чтобы он получил такое же определение узла марионетки.

На марионеточном сервере я использую регулярное выражение чего-то вроде /*.sql.domain.com/ для этой записи узла, чтобы и бродячая, и настоящая машины получали эту запись узла на марионеточном сервере.

Наконец, я включаю автоматическую подпись для * .vagrant.domain.com в файле autosign.conf марионетки, чтобы машина vagrant была подписана.

Все идет нормально...

Однако: если одна машина в моей сети получает root-права, скажем, unimportant.domain.com, что помешает злоумышленнику изменить имя хоста на этой машине на sql.vagrant.domain.com, удалив с него старый марионеточный ssl-сертификат, а затем повторно запустить марионетку с заданным именем узла sql.domain.com? Новый сертификат ssl будет автоматически подписан марионеткой, совпадать с регулярным выражением имени узла, и затем этот взломанный узел получит всю интересную информацию, предназначенную для машины sql ?!

Одно из решений, которое я могу придумать, - это избежать автоподписи и поместить известный марионеточный ssl-сертификат для реальной производственной машины в общий каталог vagrant, а затем выполнить задание vagrant ssh, переместив его на место. Обратной стороной этого является то, что я получаю все свои ssl-сертификаты для каждой производственной машины, находящейся в одном репозитории git (мое бродячее репо) и, следовательно, на каждой машине разработчика - что может быть или не быть проблемой, но это не похоже на правильный способ сделать это.

tl; dr: Как другие люди справляются с сертификатами ssl vagrant и puppet для разработки или тестирования клонов производственных машин?

Чтобы ответить здесь другим людям, которые могут столкнуться с подобным вопросом. Я закончил тем, что использовал vagrant в сетевом устройстве только для хоста, используя маскарад постмаршрутизации (nat) на хосте, чтобы позволить сети только для хоста также связываться с внешним миром.

Есть vagrant puppetmaster, который использует автоподпись - учитывая, что он находится в собственной сети только для хоста (vboxnet0) с любым vagrant puppet client, для которого я пишу код, он устраняет большинство проблем безопасности, которые у меня были.

Для производства настоящий (не бродячий) кукловод имеет только производственную ветвь git и не допускает автоподписи.