Klone eit VPN-serverbilete utan å klone identiteten

Biletet startar, tenesta går i gang, og klientar koplar til. Det er augeblinken for å stoppe og spørje kva av to svært ulike operasjonar som nettopp skjedde. Anten gjenopprettar kopien éin logisk gateway som fanst tidlegare, eller ho legg til ein ny gateway i flåten. Begge er legitime, og dei har ulike konsekvensar for identitet og tilgang. Ein maskin som kjem reint opp beviser ingen av dei.

Tre vilkår avgjer svaret, og det er dei tre bøttene med materiale eit bilete kan bere. Sorter dei før biletet blir bygd, ikkje etter at det er rulla ut to gonger.

Avgjer først kva av dei to operasjonane du utfører

Ei gjenoppretting held på éin tenesteidentitet. Den gamle instansen er borte, namnet og sertifikatet blir verande, og klientar held fram med å stole på same endepunkt. Eit tillegg skaper ein ny identitet som klientar, loggar og tilbakekalling alle må skilje.

Skilnaden er ikkje kosmetisk. Viss to levande vertar presenterer same gateway-sertifikatet, kan ein klient ikkje skilje dei, eit revisjonsspor kan heller ikkje, og tilbakekalling av det sertifikatet fjernar begge på éin gong. Det kan vere nettopp det ein medviten høgtilgjengelegheitsdesign vil, og det er sjeldan det ein rask biletekopi har tenkt.

Så den første avgjerda er ei setning, skriven ned før biletet forlèt byggjevarten: denne kopien gjenopprettar gateway A, eller denne kopien blir gateway B. Alt etterpå er bokføring mot den setninga. Viss ingen kan skrive ho, er kopien ikkje klar til å bli bygd.

Gjenbrukbare inndata, identitet og myndigheit, utrullingstilstand

Den gjenbrukbare bøtta er den enkle: pakkar, gjennomgått konfigurasjon utan hemmelegheiter, tenestemalar, herdingsinnstillingar. Det er dette eit bilete verkeleg er godt på, og det kan reproduserast utan grense.

Bøtta for identitet og myndigheit er der kopiar går gale. Den private nøkkelen og sertifikatet til ein gateway identifiserer den gatewayen overfor kvar klient. Signeringsnøkkelen til sertifikatmyndigheita er eit anna objekt med ei anna makt: han gjev ut identitetar. Å stole på ein utgivar tyder ikkje at kvar ny gateway treng evna til å gje ut, og å sende signeringsnøkkelen inne i eit bilete gir den evna til alt som kan lese biletet.

Bøtta for utrullingstilstand er den folk gløymer fordi ho ser ut som konfigurasjon. Lyttaradresser, adressebasseng, push-ruter, resolver-innstillingar og lokal integrasjon kodar alle føresetnader om den første verten. Ein ny node som kopierer dei kan dele ut frå eit basseng ein annan gateway alt eig, eller peike klientar mot ein ressurs som berre finst ved sida av originalen.

Kva ein ny node må få, og av kven

Ein sjølvstendig administrert node bør få eigne legitimasjonar gjennom den godkjende registreringsprosessen, med signeringsoperasjonen der signeringsnøkkelen bur i staden for på den nye verten. Noter kva identitet som kan trekkjast tilbake utan å forstyrre dei andre nodane; viss svaret er "alle", har designet éin identitet som latar som han er to.

Nettverksverdiar fortener same handsaming. Vel eit basseng, ei lyttaradresse og eit sett push-ruter som ikkje kolliderer med den eksisterande gatewayen, og skriv dei i provisjoneringsinndataene i staden for i biletet. Inndataene kan gjennomgåast; biletet kan ikkje.

Det finst eit legitimt mellomtilfelle. Eit støtta gjenopprettings- eller replikeringsdesign kan medvite halde éin logisk tenesteidentitet på tvers av vertar, med kontrollert tilgang til den gamle kopien og ein rotasjonsplan. Det er ei avgjerd med ein eigar, ikkje ein standard som skjer fordi biletet var praktisk.

openssl x509 -in /etc/openvpn/server/server.crt -noout -subject -issuer -dates
find /etc/openvpn -name '*.key' -o -name '*.pem' | head -20

Den første kommandoen fortel kva identitet noden faktisk presenterer og kven som signerte han. Den andre er ei startoversikt, ikkje eit bevis: privat materiale kan liggje utanfor den katalogen, i ein applikasjonsdatabase eller i eit snapshot-lag som det køyrande filsystemet ikkje lenger viser.

Kva ein kopi av biletet stillferdig ber med seg

Å slette ei fil frå den nyaste revisjonen av eit bilete fjernar ho ikkje frå eldre revisjonar, lagercache eller snapshots tekne medan ho fanst. Difor må bilete med legitimasjon handsamast som sensitive objekt heile levetida, ikkje berre i augeblinken dei blir bygde.

Kontroller bileteinnhaldet og provisjoneringsinndataene som separate spørsmål. Biletet svarar på "kva er inne i dette artefaktet", medan inndataene svarar på "kva blir denne instansen ved første oppstart". Eit reint bilete med eit bootstrap-skript som hentar ein delt nøkkel svarar godt på det første spørsmålet og dårleg på det andre.

Hald gjenopprettingsbilete som legitimt inneheld hemmelegheiter avgrensa til dei som treng dei, og noter kvar dei er lagra. Alternativet, eit bilete som er praktisk fordi det verkar utan noko provisjonering, er det same biletet som gir kven som helst som finn det, identiteten til gatewayen. Berre éin av dei to oppgåvene dukkar opp i ein byggjelogg.

Tilgangskontrollar før produksjon

Før noden tek imot trafikk, stadfest fire ting: identiteten han presenterer, klientane han vil godta, ressursane han har lov til å nå, og returvegen for adressene han deler ut.

systemctl status openvpn-server@lab --no-pager
ss -lunp 'sport = :1194'
ip -4 route show table all | grep -F '10.90.'

Kontroller deretter det negative tilfellet, som er det som fangar ulukker: har den nye noden administrator- eller klienttilgang som var meint for originalen? Ein kopiert konfigurasjon kan bere ei ekstra klientoppføring, ein nedarva administrasjonsrute eller eit push-direktiv som gav meining på den første verten.

Viss eit bilete med levande hemmelegheiter alt har flytta seg utover den godkjende grensa si, erstatt legitimasjonen og avgrens kopiane. Å fjerne fila frå den siste bygginga er ikkje det same som å ta ut av drift legitimasjonen som eldre kopiar framleis har, og gapet mellom dei to fakta er nøyaktig vindauget ein åtakar treng.