Lista blokowanych Nebula: rozprowadź ją, latarnia tego nie zrobi

Egzekwowanie listy blokowanych jest właściwością hosta, który sprawdza, a nie certyfikatu, który jest sprawdzany. Maszyna, która nigdy nie wczytała wpisu, nadal akceptuje tożsamość, a nic w uzgadnianiu nie ostrzega, że dwa peery się nie zgadzają. Tanie i drogie rozwiązanie dla jednego ujawnionego poświadczenia różnią się zasięgiem i odwracalnością, więc wybieraj świadomie. Poniższe sekcje opisują, co robi wpis, gdzie trzeba go dostarczyć, kiedy rotacja jest lepszą odpowiedzią i jak udowodnić, że jedno z nich zadziałało.

Co właściwie robi wpis na liście blokowanych

Konfiguracja PKI wymienia odciski palców, które host musi odrzucić, nawet jeśli certyfikat jest prawidłowo podpisany i niewygasły. Egzekwowanie odbywa się lokalnie, wobec listy wczytanej przez ten host przy starcie usługi. Nic z wpisu nie podróżuje w certyfikacie, więc peer nie może poznać decyzji z okazanego mu poświadczenia. Dlatego latarnia nie odgrywa tu żadnej roli: latarnie pomagają peerom się odnaleźć i przekazują ruch tam, gdzie bezpośrednia ścieżka zawodzi. Są warstwą odkrywania i przekazywania, a nie kanałem dystrybucji konfiguracji.

Aktualizacja jednej maszyny zmienia decyzje tej maszyny i pozostawia każdy inny peer dokładnie takim, jaki był. Peer, który ufa urzędowi podpisującemu i nigdy nie widział wpisu, nie ma powodu niczego odrzucać. Testowanie unieważnienia przez obserwację latarni niczego więc nie dowodzi, bo obserwowany komponent nigdy nie został poproszony o egzekwowanie listy.

Zidentyfikuj certyfikat, nie urządzenie

Użyj odcisku palca poświadczenia, które zamierzasz odrzucić, ponieważ nazwa hosta, etykieta urządzenia czy bieżący adres identyfikują dziś jedną maszynę, a w przyszłym miesiącu inną. Żaden z tych ciągów nie występuje na liście blokowanych i żaden nie przetrwa reinstalacji. Wydrukuj certyfikat, odczytaj odcisk palca i sprawdź, że należy do wycofywanego poświadczenia, a nie do jego następcy. Odczytanie obu plików ma znaczenie, gdy następca jest już wydany, bo stary i nowy certyfikat mogą dzielić nazwę i różnić się w każdym innym polu.

Zapisz, który odcisk palca zablokowano i kiedy, aby późniejszy audyt odróżnił zmianę zakończoną od zamierzonej. Zanotuj też, czego wpis nie robi: nie unieważnia urzędu podpisującego i nie powstrzymuje akceptacji przyszłego certyfikatu z tego urzędu. Zablokowanie certyfikatu hosta i wymiana przejętego urzędu to różne operacje o różnych konsekwencjach.

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

Rozprowadzaj ją jak każdą inną konfigurację

Traktuj listę jak konfigurację z mechanizmem dostarczania, a nie plik, który ktoś edytuje, gdy sobie przypomni. Wypychaj całą listę, a nie deltę, aby host, który przegapił wcześniejszą aktualizację, zbiegał się zamiast gromadzić luki. Dokumentacja PKI Nebula zaleca dokładnie to, a radę warto stosować dosłownie, zamiast przekształcać ją w ręczny proces.

Potwierdź, że działająca usługa wczytała zawartość ponownie, nie tylko że plik na dysku się zmienił. Śledź, które maszyny zastosowały zmianę, i utrzymuj listę zaległości widoczną, dopóki nie będzie pusta. Laptop zamknięty na tydzień to peer, który nigdy nie poznał decyzji, i może połączyć się ponownie z sieci, której nikt się nie spodziewał. Zapisz metodę dostarczania obok odcisku palca, bo następne unieważnienie ją powtórzy, a przy pierwszym debuguje się ten proces.

Lista blokowanych czy rotacja urzędu

Wpis na liście blokowanych jest wąski: jedna tożsamość przestaje działać, a wszystko inne trwa. Rotacja urzędu podpisującego jest szeroka: każdy wydany przez niego certyfikat staje się niezaufany, a każdy host potrzebuje nowego poświadczenia i nowej kotwicy zaufania. Pierwsze to ukierunkowane unieważnienie, drugie to migracja, więc wymagają różnych zgód i różnych okien serwisowych. Tabela zestawia oba pod względem zasięgu, nakładu i odwracalności.

Zgubiony laptop wymaga listy blokowanych, bo promień rażenia to jedna tożsamość, a zmiana jest odwracalna, jeśli zablokowano zły odcisk palca. Ujawniony klucz urzędu wymaga rotacji, bo lista blokowanych nie pomoże przy certyfikatach jeszcze niewydanych. Między tymi skrajnościami zapytaj, czy ujawnione poświadczenie mogło podpisać coś jeszcze, bo urząd to więcej niż jeden host.

Zapisz decyzję przed incydentem, bo wybór pod presją domyślnie skłania się ku szerokiej opcji. Niezależnie od drogi pozostałe zadanie jest identyczne: udowodnić, że egzekwowanie nastąpiło na hostach, które się liczą. Zapisanie odcisku palca i daty w tym momencie jest tym, co umożliwia dowód później.

Sprawdź odrzucenie i resztę

Połącz się z zablokowanej tożsamości i potwierdź błąd, potem połącz się z autoryzowanego peera i potwierdź, że nadal dociera do tego, czego potrzebuje. Zmiana, która psuje wszystko, nie jest udanym unieważnieniem. Zrób oba z świeżych sesji, bo stan z pamięci podręcznej może ukryć wynik.

Sprawdź, czy ustanowiona sesja kończy się po zmianie, i zanotuj zachowanie dla swojej wersji i konfiguracji, zamiast zakładać, że edycja pliku cokolwiek kończy. Opcja disconnect_invalid obejmuje klientów, których certyfikaty wygasły lub są nieprawidłowe, więc potwierdź, jak stosuje się w twoim przypadku, zanim na niej polegasz. Jeśli natychmiastowe zakończenie jest wymogiem, przetestuj to konkretnie i zapisz, co zaobserwowałeś. Następnie powtórz test po restarcie, bo host, który egzekwuje listę tylko do następnego rozruchu, ma problem z dostarczaniem, który pierwszy test ukrył. Zdrowa latarnia mówi, że odkrywanie działa, a nie że jakikolwiek peer zastosował politykę.