Nebula potrzebuje trzech plików: CA, certyfikatu hosta i klucza hosta

Jeśli dasz komuś katalog Nebula, zwykle skopiuje wszystko, łącznie z plikiem, który nigdy nie powinien opuścić twojej stacji roboczej. Zamieszanie jest zrozumiałe, bo trzy pliki w bloku PKI hosta wyglądają podobnie, a dwa z nich to certyfikaty. Każdy odpowiada na inne pytanie, a tylko dwa należą do węzła. Zanim cokolwiek skopiujesz, posortuj je według roli.

Trzy pliki, trzy różne zadania

Certyfikat CA to kotwica zaufania: mówi hostowi, którym organom wierzyć, gdy inny host przedstawia swoją tożsamość. Certyfikat hosta to własne poświadczenie węzła, podpisane przez ten organ. Klucz hosta to pasująca do niego prywatna połowa i należy dokładnie do jednej maszyny. Węzeł z certyfikatem CA i własną parą może dołączyć do overlayu i udowodnić, kim jest. Węzeł z kluczem kogoś innego też może podawać się za tę osobę, i to właśnie ten błąd ma uniemożliwiać ten układ.

Kopiowanie działającego katalogu hosta na drugą maszynę nie jest więc skrótem. To zduplikowana tożsamość o przewidywalnym wyniku.

Klucz podpisujący nigdy nie podróżuje

Klucz podpisujący CA nie jest częścią żadnej konfiguracji hosta. Tworzy nowe tożsamości, a kto go ma, może wystawić certyfikat dla dowolnego adresu overlay i dowolnej grupy. Partnerzy potrzebują tylko publicznego certyfikatu CA do weryfikacji podpisów, więc prywatna połowa nie ma na kliencie żadnej roli. Trzymaj go na maszynie, na której wystawia się certyfikaty, a przypadkową kopię traktuj jak incydent, nie jak wygodę.

Jeśli kilka osób musi wystawiać certyfikaty, daj im proces zamiast kopii klucza. Wspólny klucz podpisujący na laptopie to władza, której nikt nie może zaudytować ani odwołać.

Co jest w środku certyfikatu hosta

Certyfikat hosta wiąże z kluczem więcej niż nazwę pliku. Niesie adres overlay węzła, jego nazwę i przynależność do grupy, wszystko podpisane, aby partner mógł zdecydować, czy go zaakceptować. Dlatego zmiana nazwy hosta oznacza wystawienie nowego certyfikatu, a nie edycję wiersza konfiguracji.

nebula-cert print -path host.crt pokazuje, co faktycznie wystawiono. Przeczytaj go, zanim uznasz, że certyfikat zawiera zamierzony adres.

Przeładowanie nie zawsze wystarcza

Niektóre ustawienia PKI przeładowują się na sygnał, a inne nie. Certyfikat, którego adres overlay się zmienił to klasyczny przypadek wymagający ponownego uruchomienia procesu, a nie przeładowania.

Sprawdź, które ścieżki działający proces naprawdę otworzył, a nie tylko które ścieżki wymienia plik konfiguracyjny. Potem zmień jedno poświadczenie, sprawdź łączność i logi, i dopiero wtedy zajmij się następnym. Przeładowanie, które wygląda na udane, gdy stary certyfikat zostaje w pamięci, daje niezgodność przypominającą problem z routingiem. Ponowne uruchomienie jest tanie; debugowanie tożsamości, którą połowa overlayu nadal widzi po staremu, tanie nie jest.

Usunięcie tożsamości wymaga listy blokad

Zastąpienie utraconego lub ujawnionego poświadczenia ma dwie połowy. Nowy certyfikat przywraca dostęp, a stara tożsamość musi przestać być akceptowana. To osobne operacje, a wykonanie tylko pierwszej zostawia przejęte poświadczenie ważnym.

Lista blokad to plik, który rozdajesz hostom, a nie coś, co lighthouse sam rozsyła. Zaplanuj, jak dotrze do każdego węzła, także tych, które są dziś offline, i zapisz, które odciski palców zablokowałeś. Wymień klucz na maszynie wystawiającej i trzymaj dane nowego certyfikatu razem z rekordem hosta. Unieważnienie, które istnieje tylko na maszynie, którą edytowałeś, nie jest unieważnieniem.