Лялечна безпека та мережеві топології

Фон:

Нарешті я відкладаю деякий час, щоб приєднатися до 21 століття і подивитися на Лялечку.

На сьогоднішній день ми підтримуємо версію всіх конфігурацій сервера в сховищі, яке знаходиться в офісі. Коли потребує оновлення, зміни перевіряються в репост і вручну висуваються на відповідну машину. Зазвичай це означає SFTP'ing до віддаленої машини, а потім переміщення файлів на місце з відповідними дозволами з оболонки.

Тож я сподіваюся, що Лялька стане простим, але дивовижним доповненням до того, що ми вже маємо.

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

• Процес завжди є одним із способів. Змінює перехід від безпечного середовища до небезпечного і ніколи не навпаки.

• Господарський магазин знаходиться в найбезпечнішому можливому місці. Ризик виникнення компромісу, викрадаючи конфігурації або надсилаючи шкідливі модифікації, значно зменшується.

Питання:

З того, що я розумію про модель лялькових серверів / клієнтів, це те, що клієнти опитують і тягнуть оновлення безпосередньо з сервера. Трафік завершений SSL, тому його не можна перехоплювати чи підробляти. Але це відрізняється від того, що ми робимо в даний час, оскільки сервер ляльок (-ів) потребує розміщення в публічному місці. Або централізовано, або по одному для кожного центру даних, який ми підтримуємо.

Тож мені цікаво:

• Невже я є параноїдальним щодо переходу від натискання на потяг?

• Мене зайво параноїзує центральне зберігання всієї цієї інформації в загальнодоступній мережі?

• Як інші підтримують кілька мереж - окремий сервер для кожного сайту?

Оновлення 30.07.09:

Я здогадуюсь, що одна з моїх інших великих проблем полягає в тому, щоб довіряти одній машині. Ляльковий майстер (и) мав би бути закреплений, закріплений тощо. Але навіть будь-яка публічна машина із послугами прослуховування має атакуючу поверхню певного розміру.

Імовірно, якщо майстер має дозвіл на оновлення будь-якого файлу на будь-якому з лялькових клієнтів, то цей компроміс в кінцевому підсумку призведе до компромісу всіх його клієнтів. "Царі в царство" так би мовити.

• Це гіпотеза правильна?

• Чи є якийсь спосіб, що його можна пом'якшити?

Оскільки я іноді зберігаю паролі у змінних у своїх модулях, щоб мати змогу розгортати програми, не доводивши до конфігурації вручну, це означає, що я не можу гідно розмістити свою лялькову репо на загальнодоступному сервері. Це означатиме, що атака на лялькового майстра дозволить отримати певні паролі програми або db для всіх наших різних програм на всіх наших серверах.

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

# 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 назад до каталогу модулів верхнього рівня. Це означає, що вони мають однаковий каталог модулів. Потім ми переконуємося, що переважна більшість класів, які ми пишемо, знаходяться в каталозі модулів і використовуються обома сайтами. Це має приємну перевагу - змушує нас мислити загалом і не прив’язувати клас до певного сайту.

Що стосується безпеки, ми розміщуємо нашого лялькового майстра (і решту нашої мережі) за нашим брандмауером, тому ми не так заклопотані, як зберігати конфігурацію централізовано. Ляльковий майстер надсилатиме конфігурацію лише тим хостам, яким він довіряє. Очевидно, що вам потрібно захистити цей сервер.

Я не можу оцінити, наскільки потрібна ваша параноїя, це дуже залежить від вашого оточення. Однак я можу впевнено сказати, що два основні моменти вашої існуючої конфігурації все-таки можуть застосовуватися. Ви можете забезпечити перехід змін із безпечного середовища (сховище у вашому офісі) до менш безпечного середовища, де б ви не знаходилися. Ви змінюєте процес з SFTP'ing на купу серверів і вручну вводите файли, щоб розмістити SFTP'ing своєму ляльковому майстрові, і дозволяєте Лялькові поширювати файли і розміщувати їх у потрібному місці. Ваш головний магазин все ще зберігається, а ваші ризики зменшуються.

Я не вірю, що ні натискання, ні тягання по суті є більш безпечними, ніж інші моделі. Маріонетка робить велику роботу із забезпечення конфігурацій під час транзиту, а також автентифікації як клієнта, так і сервера, щоб переконатися, що існує двостороння довіра.

Щодо декількох мереж - ми працюємо з центральним «майстерним» ляльковим майстром із супутниковими ляльковими майстрами у кожному місці, яке виступає клієнтами центрального майстра.

Один із підходів до проектування полягає в тому, щоб мати лялькового майстра місцевим розташуванням кожного сайту систем і використовувати інструмент розгортання для перенесення змін до лялькових майстрів. (Використання git з git гачками теж може працювати).

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

Також можна висунути маніфести на кожен сервер, а маріонетковий клієнт розібрати маніфести та застосувати відповідні конфігурації.

хоча ви кажете "зовнішній", я дійсно сумніваюся, що до вашого лялькового майстра потрібно підключити довільних людей. ви завжди можете кинути VPN в суміш. один мій друг одного разу запитав мене "чи потрібно турбуватися про безпеку протоколу, якщо з'єднання надійне?" хоча я не згоден з таким ставленням, зайвий шар ніколи не шкодить і, безумовно, творить чудеса в моїй особистої параної. окрім того, її забава тунельних тунелів.

Марк Берджесс, автор cfengine та університетський професор (який, мабуть, маріонетка завдячує своєю спадщиною), написав багато про поштовх. Він стверджує, що тягнути за своєю суттю є більш безпечним. Якщо ви подивитесь на веб-сайт cfengine, у них зафіксовано лише 1 інцидент безпеки мережі за 17 років. Burgess стверджує, що це через дизайн дизайну. Я думаю, що єдиний пункт компромісу неминучий. Мене б більше турбували маршрути атаки до цього моменту.

Ви можете запустити ляльку без центрального майстра, якщо хочете. Один із методів, який я бачив, - це використання сховища git та створення скриптів, які об'єднують та розгортають оновлення лише у тому випадку, якщо тег підписаний одним із заздалегідь встановленого списку gpg-ключів. Люди навіть розробили, як отримати збережені конфігурації (використовуються, наприклад, для налаштування моніторингу нагіосів на центральному сервері з ресурсу, обробленого на іншому сервері).

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

Детальніше читайте на http://current.workingdirectory.net/posts/2011/puppet-without-masters/