Puppet Security и сетевые топологии

Задний план:

Я наконец откладываю некоторое время, чтобы присоединиться к 21-му веку и взглянуть на Puppet.

Сегодня мы контролируем все конфигурации серверов в репозитории, который хранится внутри офиса. Когда необходимо выполнить обновление, изменения возвращаются в репозитории и вручную выталкиваются на рассматриваемый компьютер. Обычно это означает SFTP на удаленной машине, а затем перемещение файлов на место с соответствующими разрешениями из оболочки.

Поэтому я надеюсь, что Puppet станет простым, но удивительным дополнением к тому, что у нас уже есть.

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

• Процесс всегда один путь. Изменения переходят от безопасной среды к небезопасной и никогда наоборот.

• Мастер магазин находится в самом безопасном месте. Риск компрометации путем кражи конфигураций или отправки вредоносных модификаций значительно снижается.

Вопрос:

Насколько я понимаю, модель сервера / клиента Puppet заключается в том, что клиенты опрашивают и загружают обновления прямо с сервера. Трафик защищен SSL, поэтому его нельзя перехватить или подделать. Но это отличается от того, что мы делаем в настоящее время, потому что серверы Puppet должны быть размещены в публичном месте. Либо централизованно, либо по одному для каждого сайта центра обработки данных, который мы поддерживаем.

Вот мне и интересно

• Я излишне параноидален по поводу перехода от толчка к тяге?

• Я излишне параноидален из-за централизованного хранения всей этой информации в общедоступной сети?

• Как другие обслуживают несколько сетей - отдельный сервер для каждого сайта?

Обновление 30/07/09:

Я предполагаю, что одна из моих других больших проблем - размещение, поэтому я должен доверять одной машине. Хозяин марионеток (ов) будет огнен, защищен и тому подобное. Но даже в этом случае любой общедоступный компьютер со службами прослушивания имеет поверхность атаки определенного размера.

Предположительно, если мастер имеет разрешение на обновление любого файла на любом из клиентов марионеток, то его компрометация в конечном итоге приведет к компрометации всех его клиентов. «Короли в королевство», так сказать.

• Это гипотеза верна?

• Есть ли способ, которым это может быть смягчено?

Поскольку я иногда храню пароли в переменных в своих модулях, чтобы иметь возможность развертывать приложения без необходимости завершать настройку вручную, это означает, что я не могу прилично разместить свое репозиторий марионеток на общедоступном сервере. Это будет означать, что нападение на puppetmaster позволит получить пароли некоторых приложений или БД всех наших различных приложений на всех наших серверах.

Так что мой puppetmaster находится в частной сети нашего офиса, и я не запускаю демон puppetd на серверах. Когда мне нужно развернуть, я использую ssh из частной сети на серверы, создавая туннель и вызывая удаленно puppetd.
Хитрость заключается не в том, чтобы настроить удаленный туннель и клиент puppet для подключения к puppetmaster, а к прокси-серверу, который принимает http-соединение и может достигать сервера puppetmaster в частной сети. В противном случае Puppet откажется вытащить из-за конфликта имени хоста с сертификатами.

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

Это работает для меня, надеется, что это поможет вам

У нас есть два сайта, наш офис и наш офис. У каждого сайта есть свой кукловод. Мы создали хранилище SVN со следующей структурой:

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

Каталог модулей на каждом сайте - это каталог svn: externals обратно в каталог модулей верхнего уровня. Это означает, что они используют один и тот же каталог модулей. Затем мы проверяем, что подавляющее большинство написанных нами классов находятся в каталоге модулей и используются обоими сайтами. Это имеет приятное преимущество, заставляя нас мыслить обобщенно, а не привязывать класс к определенному сайту.

Что касается безопасности, мы размещаем нашего puppetmaster (и остальную часть нашей сети) за нашим брандмауэром, поэтому нас не беспокоит централизованное хранение конфигурации. Puppetmaster будет отправлять конфигурацию только тем хостам, которым он доверяет. Очевидно, вам нужно сохранить этот сервер в безопасности.

Я не могу судить о том, насколько необходима ваша паранойя, это сильно зависит от вашего окружения. Тем не менее, я могу с уверенностью сказать, что две основные точки вашей существующей конфигурации все еще могут применяться. Вы можете обеспечить переход от безопасной среды (хранилище в вашем офисе) к менее безопасной среде, где бы ни находился ваш puppetmaster. Вы изменяете процесс с SFTP на кучу серверов и вручную помещаете файлы для размещения на SFTP'инг своему хозяину puppet и позволяете Puppet распространять файлы и размещать их в нужном месте. Ваш главный магазин по-прежнему является хранилищем, и ваши риски снижены.

Я не верю, что push или pull по своей сути безопаснее, чем другие модели. Puppet делает большую работу по защите конфигураций при передаче, а также аутентификации как клиента, так и сервера, чтобы обеспечить двустороннее доверие.

Что касается нескольких сетей - мы работаем с центральным мастером кукловодов со спутниковыми мастерами кукол в каждой локации, выступающими в роли клиентов для центрального мастера.

Один из подходов к проектированию состоит в том, чтобы иметь puppetmaster локально для каждого сайта систем и использовать инструмент развертывания, чтобы вносить изменения в puppetmasters. (Использование git с git hooks тоже может сработать).

Это избавит вас от беспокойства о службах прослушивания в общедоступной сети, поскольку сетевой трафик марионеток будет только внутренним.

Также можно отправить манифесты на каждый сервер и заставить клиента puppet проанализировать манифесты и применить соответствующие конфиги.

хотя вы говорите «внешний», я действительно сомневаюсь, что произвольные люди должны подключиться к вашему марионетке. Вы всегда можете добавить VPN в смесь. один мой друг однажды спросил меня: «Тебе нужно беспокоиться о безопасности протокола, если соединение безопасно?» Хотя я не согласен с таким отношением, дополнительный слой никогда не ранит и, конечно, творит чудеса в моей личной паранойе. Кроме того, это весело для туннелей.

Марк Берджесс, автор cfengine и профессор университета (эта марионетка, похоже, обязана своим наследием) много писал о толчках и толчках. Он утверждает, что тяга более безопасна. Если вы посмотрите на веб-сайт cfengine, за 17 лет у них произошел всего один инцидент с сетевой безопасностью. Берджесс утверждает, что это из-за дизайна тяги. Я думаю, что единственная точка компромисса неизбежна. Я был бы более обеспокоен путями нападения к этой точке.

Вы можете запустить марионетку без центрального хозяина, если хотите. Один из методов, которые я видел, - это использование репозитория git и наличие сценариев, которые будут объединять и развертывать обновление только в том случае, если тег подписан одним из предварительно заданных списков ключей gpg. Люди даже разобрались, как получить сохраненные конфиги (например, для настройки мониторинга nagios на центральном сервере из ресурса, обработанного на другом сервере).

Таким образом, если центральный git-сервер был скомпрометирован, другие серверы больше не будут применять обновления с него. Ключи gpg будут на ноутбуках sys admin или что-то в этом роде вместе с некоторым способом отзыва ключей.

Узнайте больше на http://current.workingdirectory.net/posts/2011/puppet-without-masters/