Nebula-sertifikatets omlasting endret ikke IP-en: her er hvorfor

Du utsteder et nytt vertssertifikat med en annen overlay-adresse, kopierer det over den gamle filen, sender omlastingen, og verten fortsetter å svare på adressen den hadde før. Refleksen er å anta at omlastingen mislyktes eller at feil fil ble lest. Vanligvis skjedde ingen av delene: den kjørende prosessen beholdt bevisst identiteten den allerede hadde, fordi erstatningen endret noe en omlasting ikke kan anvende.

Nebulas støtte for omlasting av PKI er dokumentert med den grensen, og det er lett å overse når den samme dokumentasjonen viser at omlasting fungerer for andre endringer.

Hva en omlasting faktisk leser på nytt

Et vertssertifikat er ikke bare en legitimasjon slik en SSH-nøkkel er. Det bærer overlay-adressen, vertsnavnet, gruppemedlemskapene og et gyldighetsvindu, og alt dette er bundet sammen av CA-ens signatur. Daemonen bruker det signerte innholdet til å avgjøre hvordan den presenterer seg og hvilke regler som gjelder for den.

Omlasting lar prosessen hente fornyet legitimasjon uten å miste tunnelene sine, noe som er verdifullt ved rutinemessig rotasjon: samme adresse, samme navn, samme grupper, senere utløp. Begrensningen er at identiteten må forbli den samme. Endre overlay-adressen, og omlastingsveien kan ikke anvende den, fordi adressen er en del av det den kjørende instansen allerede har forpliktet seg til.

Så atferden du så er den dokumenterte grensen som gjør jobben sin, ikke en stille feil. Filen på disken er ny; identiteten i minnet er gammel; prosessen har ingen støttet måte å forene den forskjellen uten en omstart.

Adresse, navn og grupper er én identitet

Det hjelper å tenke på sertifikatet som én post i stedet for et sett felt du kan redigere uavhengig. Å flytte adressen er ikke som å endre en innstilling, fordi adressen vises i andre verters peer-konfigurasjoner, i tjenestebindinger og i policyer skrevet mot identiteten.

Grupper fortjener sin egen linje fordi de forårsaker en stillere versjon av den samme forvirringen. En vert som beholder adressen, men bytter grupper, kan nå andre tjenester etter en omstart, og en test som bare pinger den gamle adressen vil se helt sunn ut mens tilgangsbeslutningene har endret seg under den. Kontroller én tjeneste som dekkes av en regel, ikke bare tilgjengelighet. Det er forskjellen mellom å bekrefte tunnelen og å bekrefte policyen.

Sammenlign det innlastede sertifikatet med erstatningen

Før du antar at daemonen ignorerte filen, les begge. Skriv ut sertifikatet du vil laste inn, og bekreft feltene du tror du endret, og bekreft deretter at den kjørende konfigurasjonen peker på den stien og ikke på en kopi et annet sted.

nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)

Prosessargumentene betyr mer enn folk forventer. En enhet som sender -config /etc/nebula/config.yml, leser pki.cert-oppføringen i den filen, og et sertifikat installert i en midlertidig katalog påvirker ingenting. Kontroller stien i den kjørende kommandolinjen, ikke stien i dokumentasjonen du fulgte. Hvis de to er forskjellige, har du funnet problemet uten å røre sertifikatet i det hele tatt.

Hvis det nye sertifikatet har en annen adresse og prosessen beholdt den gamle, har du nå en forklaring i stedet for et mysterium. Start den på nytt hvis det er akseptabelt, og behandle adresseendringen som en planlagt nettverksendring og ikke en tilfeldig.

En adresseendring er en nettverksendring

Planlegg det slik du ville planlagt å flytte en maskin. Andre verter har kanskje festet den gamle adressen i konfigurasjonen sin, tjenester kan binde seg eksplisitt til den, og brannmurregler kan være skrevet mot den. Å endre sertifikatet flytter verten, og å flytte verten ugyldiggjør antakelser andre steder.

Hold en andre administrasjonsvei tilgjengelig mens du gjør dette, fordi overlay-forbindelsen kan være nettopp den du avbryter. Å gjøre det over tunnelen du er i ferd med å bryte, er den klassiske måten å gjøre en fem minutters endring om til et besøk på stedet.

Om en omstart er akseptabel avhenger av hva verten gjør, og det er et planleggingsspørsmål, ikke et teknisk. Det som ikke er valgfritt, er å anerkjenne omstartskravet i stedet for å sende omlastingen en femte gang.

Avvikle den gamle legitimasjonen separat

Å installere en erstatning på én maskin lar hver peer fortsatt stole på legitimasjonen den allerede kjenner. Hvis årsaken til endringen var et kompromiss, må den gamle identiteten avvikles gjennom tillits- eller blokklisteprosedyren, slik at peerne faktisk avviser den.

Det er et eget trinn med sin egen verifisering: bekreft fra en annen vert at den gamle identiteten ikke lenger fungerer, i stedet for å anta at den nye filen gjorde jobben. Nebulas dokumentasjon for PKI-konfigurasjon dekker innstillingene som kan lastes på nytt og adressebegrensningen som er beskrevet her, og den er verdt å lese i sin helhet før du roterer noe produksjonsrettet.