Klonowanie obrazu serwera VPN bez klonowania jego tożsamości

Obraz się uruchamia, usługa startuje, a klienci się łączą. To moment, by zatrzymać się i zapytać, która z dwóch bardzo różnych operacji właśnie się odbyła. Albo kopia przywraca jedną logiczną bramę, która istniała wcześniej, albo dodaje do floty drugą bramę. Obie są uzasadnione i mają różne skutki dla tożsamości i dostępu. Maszyna, która wstaje czysto, nie dowodzi żadnej z nich.

Trzy warunki rozstrzygają odpowiedź i są to trzy kosze materiału, który obraz może nieść. Posortuj je przed zbudowaniem obrazu, a nie po tym, jak został dwa razy wdrożony.

Najpierw zdecyduj, którą z dwóch operacji wykonujesz

Przywrócenie zachowuje jedną tożsamość usługi. Stara instancja zniknęła, nazwa i certyfikat zostają, a klienci nadal ufają temu samemu punktowi końcowemu. Dodanie tworzy drugą tożsamość, którą klienci, dzienniki i unieważnianie muszą rozróżniać.

Różnica nie jest kosmetyczna. Jeśli dwa działające hosty przedstawiają ten sam certyfikat bramy, klient nie potrafi ich rozróżnić, ścieżka audytu też nie, a unieważnienie tego certyfikatu usuwa oba naraz. To może być dokładnie to, czego chce świadomy projekt wysokiej dostępności, i rzadko to, co ma na myśli pośpieszna kopia obrazu.

Pierwszą decyzją jest więc zdanie, zapisane zanim obraz opuści host budujący: ta kopia przywraca bramę A albo ta kopia staje się bramą B. Wszystko później to księgowość wobec tego zdania. Jeśli nikt nie potrafi go napisać, kopia nie jest gotowa do zbudowania.

Wejścia wielokrotnego użytku, tożsamość i uprawnienia, stan wdrożenia

Kosz wielokrotnego użytku jest tym łatwym: pakiety, przejrzana konfiguracja bez sekretów, szablony usług, ustawienia utwardzania. W tym obraz jest naprawdę dobry i można go odtwarzać bez ograniczeń.

Kosz tożsamości i uprawnień to miejsce, w którym kopie się psują. Klucz prywatny i certyfikat bramy identyfikują tę bramę wobec każdego klienta. Klucz podpisywania urzędu certyfikacji to inny obiekt o innej mocy: wydaje tożsamości. Zaufanie do wystawcy nie oznacza, że każda nowa brama potrzebuje zdolności wydawania, a wysłanie klucza podpisywania wewnątrz obrazu daje tę zdolność wszystkiemu, co potrafi odczytać obraz.

Kosz stanu wdrożenia to ten, o którym ludzie zapominają, bo wygląda jak konfiguracja. Adresy nasłuchu, pule adresów, wypychane trasy, ustawienia resolvera i integracja lokalna kodują założenia o pierwszym hoście. Drugi węzeł, który je kopiuje, może przydzielać z puli, którą już posiada inna brama, albo kierować klientów do zasobu, który istnieje tylko obok oryginału.

Co nowy węzeł musi otrzymać i od kogo

Niezależnie zarządzany węzeł powinien otrzymać własne dane uwierzytelniające w zatwierdzonym procesie rejestracji, a operacja podpisywania powinna odbywać się tam, gdzie mieszka klucz podpisywania, a nie na nowym hoście. Zapisz, którą tożsamość można wycofać bez zakłócania innych węzłów; jeśli odpowiedź brzmi "wszystkie", projekt ma jedną tożsamość udającą dwie.

Wartości sieciowe zasługują na takie samo traktowanie. Wybierz pulę, adres nasłuchu i zestaw wypychanych tras, które nie kolidują z istniejącą bramą, i zapisz je w wejściach zaopatrzenia, a nie w obrazie. Wejście można przejrzeć; obrazu nie.

Istnieje uzasadniony przypadek pośredni. Wspierany projekt odzyskiwania lub replikacji może świadomie utrzymywać jedną logiczną tożsamość usługi na wielu hostach, z kontrolowanym dostępem do starej kopii i planem rotacji. To decyzja z właścicielem, a nie domyślne zachowanie, które zdarza się dlatego, że obraz był wygodny.

openssl x509 -in /etc/openvpn/server/server.crt -noout -subject -issuer -dates
find /etc/openvpn -name '*.key' -o -name '*.pem' | head -20

Pierwsze polecenie mówi, jaką tożsamość węzeł faktycznie przedstawia i kto ją podpisał. Drugie to inwentarz początkowy, nie dowód: prywatny materiał może żyć poza tym katalogiem, w bazie danych aplikacji albo w warstwie migawki, której działający system plików już nie pokazuje.

Co kopia obrazu po cichu ze sobą niesie

Usunięcie pliku z najnowszej wersji obrazu nie usuwa go ze starszych wersji, pamięci podręcznych warstw ani migawek wykonanych, gdy istniał. Dlatego obrazy zawierające dane uwierzytelniające trzeba traktować jako obiekty wrażliwe przez cały ich żywot, a nie tylko w chwili budowania.

Sprawdź zawartość obrazu i wejścia zaopatrzenia jako dwa osobne pytania. Obraz odpowiada na pytanie "co jest wewnątrz tego artefaktu", a wejścia odpowiadają na "czym stanie się ta instancja przy pierwszym starcie". Czysty obraz ze skryptem startowym pobierającym współdzielony klucz dobrze odpowiada na pierwsze pytanie, a źle na drugie.

Trzymaj obrazy odzyskiwania, które legalnie zawierają sekrety, ograniczone do osób, które ich potrzebują, i zapisuj, gdzie są przechowywane. Alternatywa, obraz wygodny, bo działa bez żadnego zaopatrzenia, to ten sam obraz, który daje każdemu, kto go znajdzie, tożsamość bramy. Tylko jedno z tych dwóch zadań pojawia się w dzienniku budowania.

Kontrole dopuszczenia przed produkcją

Zanim węzeł przyjmie ruch, potwierdź cztery rzeczy: tożsamość, którą przedstawia, klientów, których przyjmie, zasoby, do których wolno mu dotrzeć, oraz drogę powrotną dla adresów, które rozdaje.

systemctl status openvpn-server@lab --no-pager
ss -lunp 'sport = :1194'
ip -4 route show table all | grep -F '10.90.'

Potem sprawdź przypadek negatywny, który wyłapuje wypadki: czy nowy węzeł ma dostęp administratora lub klienta, który był przeznaczony dla oryginału? Skopiowana konfiguracja może nieść dodatkowy wpis klienta, odziedziczoną trasę zarządzania albo dyrektywę push, która miała sens na pierwszym hoście.

Jeśli obraz zawierający żywe sekrety wyszedł już poza zatwierdzoną granicę, wymień dane uwierzytelniające i ogranicz kopie. Usunięcie pliku z ostatniego builda to nie to samo, co wycofanie z użycia danych uwierzytelniających, które starsze kopie wciąż trzymają, a luka między tymi dwoma faktami jest dokładnie oknem, którego potrzebuje napastnik.