Nebula-blokkeringsliste: distribuer henne sjølv, fyrlykta gjer det ikkje

Handheving av blokkeringslista er ein eigenskap ved verten som utfører kontrollen, ikkje ved sertifikatet som blir kontrollert. Ei maskin som aldri lasta oppføringa, held fram med å godta identiteten, og ingenting i handshake-en åtvarar deg om at to peer-ar er usamde. Den billege og den dyre løysinga for éin lekt legitimasjon skil seg i rekkjevidde og i reversibilitet, så vel medvite. Delane nedanfor dekkjer kva oppføringa gjer, kvar ho må leverast, når rotasjon er det beste svaret, og korleis du beviser at éi av dei verka.

Kva ei oppføring i blokkeringslista faktisk gjer

PKI-konfigurasjonen listar fingeravtrykk som ein vert må avvise sjølv om sertifikatet er gyldig signert og ikkje er utgått. Handheving skjer lokalt, mot lista som den verten lasta då tenesta starta. Ingenting ved oppføringa fer inni sertifikatet, så ein peer kan ikkje lære avgjerda frå legitimasjonen han blir vist. Det er difor ei fyrlykt ikkje har noka rolle her: fyrlykter hjelper peer-ar å finne kvarandre og videresende trafikk der ein direkte veg sviktar. Dei er eit oppdagings- og videresendingslag, ikkje ein distribusjonskanal for konfigurasjon.

Å oppdatere éi maskin endrar avgjerdene til den maskina og lèt kvar annan peer stå nøyaktig som han var. Ein peer som stolar på den signerande styresmakta og aldri såg oppføringa, har inga grunn til å nekte noko. Å teste tilbakekalling ved å sjå på fyrlykta beviser difor ingenting, fordi komponenten du ser på aldri vart beden om å handheve lista.

Identifiser sertifikatet, ikkje eininga

Bruk fingeravtrykket til legitimasjonen du vil avvise, fordi eit vertsnamn, ei einingseetikett eller ei noverande adresse identifiserer ei maskin i dag og noko anna neste månad. Ingen av dei strengane står i blokkeringslista, og ingen av dei overlever ein reinstallasjon. Skriv ut sertifikatet, les fingeravtrykket, og kontroller at det høyrer til legitimasjonen som blir fasa ut og ikkje til etterfylgjaren hans. Å lese båe filene er viktig når ein etterfylgjar alt er utstedt, sidan det gamle og det nye sertifikatet kan dele namn og skilje seg i kvart andre felt.

Noter kva fingeravtrykk som vart blokkert og når, slik at ein seinare revisjon skil ei fullført endring frå ei planlagd. Noter òg kva oppføringa ikkje gjer: ho gjer ikkje den signerande styresmakta ugyldig, og ho stoggar ikkje at eit framtidig sertifikat frå den styresmakta blir godteke. Å blokkere eit vertssertifikat og å byte ut ei kompromittert styresmakt er ulike operasjonar med ulike fylgjer.

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

Distribuer henne som kvar annan konfigurasjon

Behandle lista som konfigurasjon med ein leveringsmekanisme, ikkje som ei fil nokon redigerer når dei hugsar det. Skyv heile lista i staden for ein delta, slik at ein vert som gjekk glipp av ei tidlegare oppdatering, konvergerer i staden for å samle hol. Nebula PKI-dokumentasjonen tilrår nettopp det, og rådet er verdt å fylgje bokstaveleg i staden for å omsetje det til ein manuell prosess.

Stadfest at den køyrande tenesta lasta innhaldet på nytt, ikkje berre at fila på disken endra seg. Spor kva maskiner som brukte endringa, og hald den opne lista synleg til ho er tom. Ein laptop som har vore att i ei veke, er ein peer som aldri lærte avgjerda, og han kan kople seg til på nytt frå eit nettverk ingen venta. Noter leveringsmetoden ved sida av fingeravtrykket, fordi neste tilbakekalling brukar han på nytt, og den fyrste er der prosessen blir feilsøkt.

Blokkeringsliste eller rotasjon av styresmakt

Ei oppføring i blokkeringslista er smal: éin identitet sluttar å verke og alt anna held fram. Å rotere den signerande styresmakta er breitt: kvart sertifikat ho utferda blir mistruga, og kvar vert treng ny legitimasjon og eit nytt tillitsanker. Det fyrste er ein målretta tilbakekalling og det andre er ein migrasjon, så dei treng ulike godkjenningar og ulike vedlikehadsvindauge. Tabellen set dei to side om side på rekkjevidde, arbeid og reversibilitet.

Ein tapt laptop krev blokkeringslista, fordi skadeomfanget er éin identitet og endringa er reversibel om du blokkerte feil fingeravtrykk. Ein lekt styresmaktsnøkkel krev rotasjon, fordi blokkeringslista ikkje kan hjelpe med sertifikat som enno ikkje er utferda. Mellom desse ytterpunkta, spør om den eksponerte legitimasjonen kunne ha signert noko anna, sidan ei styresmakt er meir enn éin vert.

Skriv avgjerda ned før ein hending, fordi val under press har ein tendens til å gje det breie alternativet som standard. Kva veg du enn tek, er det attverande arbeidspunktet identisk: bevis at handheving skjedde på dei vertane som tel. Å registrere fingeravtrykket og datoen i det augeblikket er det som gjer beviset mogleg seinare.

Stadfest avvisinga og resten

Kople til frå den blokkerte identiteten og stadfest feilen, kople så til frå ein autorisert peer og stadfest at han framleis når det han treng. Ei endring som bryt alle, er ikkje ei vellukka tilbakekalling. Gjer båe frå ferske økter, fordi mellomlagra tilstand kan skjule resultatet.

Kontroller om ei etablert økt sluttar etter endringa, og noter åtferda for din versjon og konfigurasjon i staden for å gå ut frå at redigering av ei fil avsluttar noko. disconnect_invalid-valet dekkjer klientar der sertifikata er utgåtte eller ugyldige, så stadfest korleis det gjeld i ditt tilfelle før du stolar på det. Viss umiddelbar avslutting er eit krav, test det spesifikt og noter det du såg. Gjenta så testen etter ein omstart, fordi ein vert som berre handhevar lista til neste omstart, har eit leveringsproblem som den fyrste testen skjulte. Ei frisk fyrlykt fortel deg at oppdaging verkar, ikkje at nokon peer har brukt ein policy.