Задний план:
Я наконец-то выделяю время, чтобы присоединиться к 21 веку и посмотреть на Puppet.
В настоящее время мы контролируем версии всех конфигураций серверов в репозитории, который хранится внутри офиса. Когда необходимо выполнить обновление, изменения возвращаются в репозиторий и вручную отправляются на соответствующую машину. Обычно это означает отправку SFTP на удаленный компьютер, а затем перемещение файлов на место с соответствующими разрешениями из оболочки.
Так что я надеюсь, что Puppet станет простым, но удивительным расширением того, что у нас уже есть.
Теперь я считаю, что нынешний процесс должен быть достаточно безопасным. При условии, что наша внутренняя сеть всегда будет относительно более безопасной, чем общедоступные сети в наших центрах обработки данных.
Процесс всегда односторонний. Изменения переходят от безопасной среды к небезопасной, и никогда не наоборот.
Главный магазин находится в самом безопасном месте. Риск компрометации путем кражи конфигураций или рассылки вредоносных модификаций значительно снижается.
Вопрос:
Насколько я понимаю, модель «сервер / клиент» Puppet заключается в том, что клиенты опрашивают и загружают обновления прямо с сервера. Трафик имеет оболочку SSL, поэтому его нельзя перехватить или подделать. Но это отличается от того, что мы делаем сейчас, потому что серверы Puppet должны быть размещены в общедоступном месте. Либо централизованно, либо по одному для каждого сайта центра обработки данных, который мы обслуживаем.
Так что мне интересно:
Я излишне параноидально отношусь к переходу от нажима к вытягиванию?
Я излишне параною по поводу централизованного хранения всей этой информации в публичной сети?
Как другие поддерживают несколько сетей - отдельный сервер для каждого сайта?
Обновление 30.07.09:
Я думаю, что один из моих других большой поэтому нужно доверять одной машине. Марионеточные мастера будут защищены от огня и тому подобное. Но даже в этом случае любая общедоступная машина со службами прослушивания имеет поверхность для атаки определенного размера.
Предположительно, если у мастера есть разрешение на обновление любого файла на любом из марионеточных клиентов, то его компрометация в конечном итоге приведет к компрометации всех его клиентов. Так сказать «короли королевства».
Верна ли эта гипотеза?
Есть ли способ смягчить его последствия?
Поскольку я иногда храню пароли в переменных в своих модулях, чтобы иметь возможность развертывать приложения без необходимости завершать настройку вручную, это означает, что я не могу прилично разместить свое марионеточное репо на общедоступном сервере. Это будет означать, что атака кукловода позволит получить пароли некоторых приложений или баз данных для всех наших различных приложений на всех наших серверах.
Итак, мой puppetmaster находится в частной сети нашего офиса, и я не запускаю демон puppetd на серверах. Когда мне нужно развернуть, я использую ssh из частной сети на серверы, создавая туннель и удаленно вызывая puppetd.
Уловка заключается не в том, чтобы настроить удаленный туннель и марионеточный клиент для подключения к puppetmaster, а к прокси, который принимает http подключение и может подключиться к серверу puppetmaster в частной сети. В противном случае марионетка откажется тянуть из-за конфликта имени хоста с сертификатами.
# 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
Это работает для меня, надеюсь, это поможет вам
У нас есть два сайта, наш офис и наш colo. На каждом участке есть свой кукловод. Мы настраиваем репозиторий 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 будет отправлять конфигурацию только тем хостам, которым он доверяет. Очевидно, вам необходимо обеспечить безопасность этого сервера.
Я не могу судить о том, насколько необходима ваша паранойя, она сильно зависит от вашего окружения. Однако я могу с уверенностью сказать, что два основных момента вашей существующей конфигурации все еще применимы. Вы можете обеспечить переход ваших изменений из безопасной среды (репозиторий в вашем офисе) в менее безопасную среду, где бы ни находился ваш кукловод. Вы меняете процесс с SFTP на несколько серверов и вручную помещаете файлы на место на SFTP для своего марионеточного мастера, позволяя Puppet распространять файлы и помещать их в нужное место. Ваше главное хранилище по-прежнему является репозиторием, и ваши риски уменьшаются.
Я не верю, что толкать или тянуть по своей сути безопаснее, чем другая модель. Puppet отлично справляется с защитой передаваемых конфигураций, а также с аутентификацией клиента и сервера, чтобы гарантировать двустороннее доверие.
Что касается множественных сетей - мы обрабатываем их с центральным «хозяином» кукловодом со спутниковыми кукловодами в каждом месте, действующими в качестве клиентов для центрального хозяина.
Один из подходов к проектированию состоит в том, чтобы иметь локального мастера марионеток для каждого сайта систем и использовать инструмент развертывания для передачи изменений мастерам марионеток. (Использование git с хуками git тоже может работать).
Это избавит вас от беспокойства по поводу прослушивания служб в общедоступной сети, поскольку марионеточный сетевой трафик будет только внутренним.
Также можно отправить манифесты на каждый сервер, а марионеточный клиент проанализирует манифесты и применит соответствующие конфигурации.
хотя вы говорите «внешний», я действительно сомневаюсь, что произвольным людям нужно связываться с вашим кукловодом. вы всегда можете добавить к этому VPN. Один мой друг однажды спросил меня: «Вам нужно беспокоиться о безопасности протокола, если соединение защищено?» хотя я не согласен с таким отношением, дополнительный слой никогда не повредит и, безусловно, творит чудеса с моей личной паранойей. кроме того, туннелировать туннели - это весело.
Марк Берджесс, автор cfengine и профессор университета (эта марионетка, кажется, обязана своим наследием), много писал о толкании и толчке. Он утверждает, что тяга по своей сути более безопасна. Если вы посмотрите на веб-сайт cfengine, у них был всего 1 инцидент сетевой безопасности за 17 лет. Берджесс утверждает, что это из-за конструкции тяги. Я считаю, что компромисс в одном месте неизбежен. В этот момент меня бы больше беспокоили пути атаки.
Если хотите, вы можете запустить марионетку без центрального мастера. Один из методов, который я видел, - это использование репозитория git и наличие скриптов, которые будут объединять и развертывать обновление только в том случае, если тег подписан одним из предварительно заданного списка ключей gpg. Люди даже придумали, как получить сохраненные конфигурации (используемые, например, для настройки мониторинга nagios на центральном сервере из ресурса, обрабатываемого на другом сервере).
Поэтому, если центральный сервер git был скомпрометирован, другие серверы больше не применяли бы обновления с него. Ключи gpg будут на ноутбуках системного администратора или что-то в этом роде, вместе с каким-то способом отзыва ключей.
Узнать больше на http://current.workingdirectory.net/posts/2011/puppet-without-masters/