Bezpieczeństwo marionetek i topologie sieci

Tło:

W końcu przeznaczam trochę czasu, aby dołączyć do XXI wieku i spojrzeć na Puppet.

W obecnej formie kontrolujemy wersje wszystkich konfiguracji serwerów w repozytorium, które jest przechowywane wewnętrznie w biurze. Gdy aktualizacja wymaga wykonania, zmiany są sprawdzane z powrotem w repozytoriach i ręcznie wypychane na dany komputer. Zwykle oznacza to wysyłanie SFTP do zdalnego komputera, a następnie przenoszenie plików na miejsce, z odpowiednimi uprawnieniami, z powłoki.

Mam więc nadzieję, że Puppet będzie prostym, ale niesamowitym rozszerzeniem tego, co już mamy.

Teraz uważam proces, który obecnie musimy być w miarę bezpieczny. Zakładając, że nasza sieć wewnętrzna będzie zawsze względnie bezpieczniejsza niż sieci publiczne w naszych centrach danych.

• Proces jest zawsze w jedną stronę. Zmienia przejście z bezpiecznego środowiska na niepewne i nigdy na odwrót.

• Główny sklep znajduje się w najbezpieczniejszym możliwym miejscu. Ryzyko naruszenia bezpieczeństwa poprzez kradzież konfiguracji lub wysyłanie złośliwych modyfikacji jest znacznie zmniejszone.

Pytanie:

Z tego, co rozumiem z modelu serwer / klient Puppet, wynika, że ​​klienci odpytują i pobierają aktualizacje bezpośrednio z serwera. Ruch jest zapakowany w SSL, więc nie można go przechwycić ani sfałszować. Ale różni się od tego, co obecnie robimy, ponieważ serwery Puppet musiałyby być hostowane w miejscu publicznym. Albo centralnie, albo jeden dla każdej witryny centrum danych, którą prowadzimy.

Zastanawiam się więc:

• Czy jestem niepotrzebnie paranoikiem w kwestii zmiany z push na pull?

• Czy jestem niepotrzebnie paranoikiem, jeśli chodzi o centralne przechowywanie wszystkich tych informacji w sieci publicznej?

• W jaki sposób inni utrzymują wiele sieci - osobny serwer dla każdej witryny?

Aktualizacja 30/07/09:

Wydaje mi się, że jednym z moich innych poważnych problemów jest zaufanie, więc muszę zaufać jednej maszynie. Puppetmaster (s) będą firewall, zabezpieczone i takie. Ale mimo to każda maszyna publiczna z usługami odsłuchowymi ma pewną powierzchnię ataku.

Przypuszczalnie, jeśli master ma pozwolenie na aktualizację dowolnego pliku na jednym z klientów marionetkowych, wówczas jego kompromis ostatecznie doprowadzi do kompromisu wszystkich jego klientów. „Królowie królestwa”, że tak powiem.

• Czy ta hipoteza jest poprawna?

• Czy jest jakiś sposób, aby to złagodzić?

Ponieważ czasami przechowuję hasła w zmiennych w moich modułach, aby móc wdrażać aplikacje bez konieczności ręcznego kończenia konfiguracji, oznacza to, że nie mogę przyzwoicie umieścić mojego marionetkowego repo na serwerze publicznym. Oznaczałoby to, że zaatakowanie puppetmaster pozwoliłoby na uzyskanie haseł aplikacji lub db wszystkich naszych różnych aplikacji na wszystkich naszych serwerach.

Więc mój puppetmaster jest w naszej prywatnej sieci biurowej i nie uruchamiam demona puppetd na serwerach. Kiedy muszę wdrożyć, używam ssh z prywatnej sieci do serwerów, tworząc tunel i zdalnie wywołując puppetd.
Sztuczka nie polega na ustawianiu zdalnego tunelu i klienta kukiełkowego, aby łączył się z puppetmaster, ale z serwerem proxy, który akceptuje połączenie http i może połączyć się z serwerem puppetmaster w sieci prywatnej. W przeciwnym razie marionetka odmówi wyciągnięcia z powodu konfliktu nazwy hosta z certyfikatami

# 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

To działa dla mnie, mam nadzieję, że ci pomoże

Mamy dwie strony, nasze biuro i nasze colo. Każda strona ma swojego własnego nauczyciela marionetek. Utworzyliśmy repozytorium svn o następującej strukturze:

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

Katalog modułów pod każdą witryną jest katalogiem svn: externals z powrotem do katalogu modułów najwyższego poziomu. Oznacza to, że współużytkują dokładnie ten sam katalog modułów. Następnie upewniamy się, że zdecydowana większość klas, które piszemy, znajduje się w katalogu modułów i jest używana przez obie strony. Ma to tę zaletę, że zmusza nas do ogólnego myślenia i nie wiąże klasy z konkretną witryną.

Jeśli chodzi o bezpieczeństwo, hostujemy naszego puppetmaster (i resztę naszej sieci) za naszą zaporą ogniową, więc nie przejmujemy się centralnym przechowywaniem konfiguracji. Puppetmaster wyśle ​​konfigurację tylko do hostów, którym ufa. Oczywiście musisz zabezpieczyć ten serwer.

Nie jestem w stanie ocenić, jak potrzebna jest twoja paranoja, zależy ona w dużej mierze od twojego środowiska. Jednak mogę śmiało powiedzieć, że dwa główne punkty twojej obecnej konfiguracji mogą nadal obowiązywać. Możesz zapewnić przejście zmiany z bezpiecznego środowiska (repozytorium w biurze) do mniej bezpiecznego środowiska, gdziekolwiek znajduje się twój puppetmaster. Zmieniasz proces z SFTP na pakiet serwerów i ręcznie umieszczasz pliki na SFTP na swoim puppetmaster i pozwalasz Puppet dystrybuować pliki i umieszczać je we właściwym miejscu. Twój główny sklep jest nadal repozytorium, a ryzyko jest ograniczone.

Nie sądzę, aby pchanie lub pchanie było z natury bezpieczniejsze niż inny model. Puppet wykonuje świetną robotę, zabezpieczając przesyłane konfiguracje, a także uwierzytelniając zarówno klienta, jak i serwer, aby zapewnić dwukierunkowe zaufanie.

Jeśli chodzi o wiele sieci - obsługujemy go za pomocą centralnego „głównego” marionetkowego mistrza z sattelitowymi marionetkami w każdej lokalizacji, działającego jako klienci centralnego głównego.

Jednym z podejść projektowych jest posiadanie lokalnego puppetmastera w każdym miejscu systemów i użycie narzędzia do wdrażania w celu wprowadzania zmian w puppetmasters. (Używanie git z hakami git również może działać).

Pozwoliłoby to uniknąć obaw związanych z usługami odsłuchowymi w sieci publicznej, ponieważ ruch sieci marionetkowej byłby tylko wewnętrzny.

Możliwe jest również wypchnięcie manifestów na każdy serwer i zlecenie klientowi lalkowemu przeanalizowania manifestów i zastosowania odpowiednich konfiguracji.

chociaż mówisz „zewnętrznie”, naprawdę wątpię, by arbitralni ludzie musieli połączyć się z twoim marionetkiem. zawsze możesz wrzucić VPN do miksu. mój przyjaciel zapytał mnie kiedyś „czy musisz się martwić o bezpieczeństwo protokołu, jeśli połączenie jest bezpieczne?” chociaż nie zgadzam się z tym podejściem, dodatkowa warstwa nigdy nie boli i na pewno działa cuda na moją osobistą paranoję. poza tym fajnie jest tunelować tunele.

Mark Burgess, autor cfengine i profesor uniwersytecki (który wydaje się zawdzięczać swojemu marionetce) napisał dużo o pchaniu i ciągnięciu. Twierdzi, że pociągnięcie jest z natury bardziej bezpieczne. Jeśli spojrzysz na stronę cfengine, mieli oni tylko 1 incydent bezpieczeństwa sieci w ciągu 17 lat. Burgess twierdzi, że dzieje się tak z powodu konstrukcji ściągającej. Myślę, że jeden punkt kompromisu jest nieunikniony. Byłbym bardziej zaniepokojony trasami ataku do tego momentu.

Możesz uruchomić marionetkę bez centralnego mistrza, jeśli chcesz. Jedną z metod, które widziałem, jest użycie repozytorium git i posiadanie skryptów, które scalą i wdrożą aktualizację tylko wtedy, gdy znacznik jest podpisany przez jedną ze wstępnie ustawionych list kluczy gpg. Ludzie nawet wymyślili, jak uzyskać zapisane konfiguracje (używane np. Do konfigurowania monitorowania nagios na centralnym serwerze z zasobu przetwarzanego na innym serwerze).

Jeśli więc centralny serwer git został przejęty, inne serwery nie zastosowałyby z niego żadnych aktualizacji. Klucze gpg byłyby na laptopach admin sys lub coś w tym rodzaju, wraz z pewnym sposobem cofania kluczy.

Czytaj więcej na http://current.workingdirectory.net/posts/2011/puppet-without-masters/