Blocklist Nebula: distribuujte ji, maják to neudělá

Vynucení blocklistu je vlastnost hostitele, který kontrolu provádí, ne certifikátu, který se kontroluje. Stroj, který záznam nikdy nenačetl, identitu dál přijímá, a nic v handshake vás neupozorní, že dva peerové se neshodují. Levná oprava a drahá oprava pro jeden prozrazený pověřovací údaj se liší dosahem a vratností, proto vybírejte vědomě. Následující oddíly popisují, co záznam dělá, kam se musí doručit, kdy je rotace lepší odpovědí a jak dokázat, že jedno z toho fungovalo.

Co záznam v blocklistu skutečně dělá

Konfigurace PKI vypočítává otisky, které musí hostitel odmítnout, i když je certifikát platně podepsaný a nevypršelý. Vynucení probíhá lokálně, proti seznamu, který hostitel načetl při spuštění služby. O záznamu nic necestuje uvnitř certifikátu, takže peer se nemůže dozvědět rozhodnutí z pověření, které se mu ukazuje. Proto tu maják nehraje žádnou roli: majáky pomáhají peerům najít se navzájem a přenášet provoz tam, kde přímá cesta selže. Jsou vrstvou objevování a přenosu, ne distribučním kanálem konfigurace.

Aktualizace jednoho stroje mění rozhodnutí toho stroje a každého dalšího peera nechává přesně tak, jak byl. Peer, který důvěřuje podepisující autoritě a záznam nikdy neviděl, nemá důvod cokoli odmítat. Testování odvolání sledováním majáku tedy nic nedokazuje, protože komponent, který sledujete, nikdy nebyl požádán seznam vynucovat.

Identifikujte certifikát, ne zařízení

Použijte otisk pověření, které chcete odmítnout, protože název hostitele, štítek zařízení nebo aktuální adresa označují stroj dnes a něco jiného příští měsíc. Žádný z těchto řetězců se v blocklistu neobjevuje a žádný nepřežije reinstalaci. Vytiskněte certifikát, přečtěte otisk a zkontrolujte, že patří pověření, které se vyřazuje, a ne jeho náhradě. Čtení obou souborů je důležité, když už je náhrada vydaná, protože starý a nový certifikát mohou sdílet jméno a lišit se ve všech ostatních polích.

Zaznamenejte, který otisk byl zablokován a kdy, aby pozdější audit oddělil dokončenou změnu od zamýšlené. Všimněte si i toho, co záznam nedělá: neruší podepisující autoritu a nezastavuje přijetí budoucího certifikátu od této autority. Zablokování certifikátu hostitele a nahrazení kompromitované autority jsou různé operace s různými důsledky.

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

Distribuujte ji jako každou jinou konfiguraci

Berte seznam jako konfiguraci s mechanismem doručení, ne jako soubor, který někdo upraví, když si vzpomene. Tlačte celý seznam místo delty, aby hostitel, který minul dřívější aktualizaci, konvergoval místo hromadění mezer. Dokumentace Nebula PKI doporučuje přesně to a radu stojí za to následovat doslova, místo abyste ji převáděli na ruční proces.

Potvrďte, že běžící služba obsah znovu načetla, ne jen že se soubor na disku změnil. Sledujte, které stroje změnu použily, a držte seznam nesplněných viditelný, dokud nebude prázdný. Notebook zavřený na týden je peer, který se rozhodnutí nikdy nenaučil, a může se znovu připojit ze sítě, kterou nikdo nečekal. Zapište způsob doručení vedle otisku, protože příští odvolání ho znovu použije a právě na prvním se proces ladí.

Blocklist, nebo rotace autority

Záznam v blocklistu je úzký: jedna identita přestane fungovat a všechno ostatní pokračuje. Rotace podepisující autority je široká: každý jím vydaný certifikát se stane nedůvěryhodným a každý hostitel potřebuje nové pověření a novou kotvu důvěry. První je cílené odvolání a druhé migrace, takže potřebují jiná schválení a jiná okna údržby. Tabulka staví obojí vedle sebe podle dosahu, úsilí a vratnosti.

Ztracený notebook volá po blocklistu, protože zasažený okruh je jedna identita a změna je vratná, pokud jste zablokovali špatný otisk. Uniklý klíč autority volá po rotaci, protože blocklist nepomůže s certifikáty, které ještě nebyly vydány. Mezi těmito extrémy se ptejte, zda prozrazené pověření mohlo podepsat ještě něco jiného, protože autorita je víc než jeden hostitel.

Napište rozhodnutí dřív než incident, protože volba pod tlakem obvykle ve výchozím nastavení vytvoří širokou variantu. Ať zvolíte kteroukoli cestu, zbývající pracovní položka je stejná: dokázat, že vynucení proběhlo na hostitelích, na kterých záleží. Zapsání otisku a data v tu chvíli je to, co důkaz později umožní.

Ověřte odmítnutí i zbytek

Připojte se z blokované identity a potvrďte selhání, potom se připojte z oprávněného peera a potvrďte, že stále dosáhne na to, co potřebuje. Změna, která rozbije všechny, není úspěšné odvolání. Udělejte obojí z nových relací, protože cachovaný stav může výsledek skrýt.

Zkontrolujte, zda navázaná relace po změně skončí, a chování si poznamenejte pro svou verzi a konfiguraci, místo abyste předpokládali, že úprava souboru něco ukončí. Volba disconnect_invalid pokrývá klienty, jejichž certifikáty vypršely nebo jsou neplatné, proto potvrďte, jak se uplatní ve vašem případě, než se na ni spolehnete. Pokud je okamžité ukončení požadavek, otestujte to konkrétně a zapište, co jste pozorovali. Potom test zopakujte po restartu, protože hostitel, který seznam vynucuje jen do dalšího spuštění, má problém s doručením, který první test zakryl. Zdravý maják vám říká, že objevování funguje, ne že nějaký peer použil politiku.