Klon en VPN-serverimage uden at klone dens identitet

Imaget starter, tjenesten går i gang, og klienter forbinder. Det er øjeblikket, hvor man skal stoppe op og spørge, hvilken af to meget forskellige operationer der netop er sket. Enten gendanner kopien én logisk gateway, som fandtes tidligere, eller den tilføjer en anden gateway til flåden. Begge er legitime, og de har forskellige konsekvenser for identitet og adgang. En maskine, der kommer rent op, beviser ingen af dem.

Tre betingelser afgør svaret, og det er de tre spande materiale, et image kan bære. Sortér dem, før imaget bygges, ikke efter det er blevet udrullet to gange.

Afgør først, hvilken af de to operationer du udfører

En gendannelse beholder én tjenesteidentitet. Den gamle instans er væk, navnet og certifikatet bliver, og klienter fortsætter med at stole på det samme endepunkt. En tilføjelse skaber en anden identitet, som klienter, logfiler og tilbagekaldelse alle skal kunne skelne.

Forskellen er ikke kosmetisk. Hvis to levende værter præsenterer det samme gateway-certifikat, kan en klient ikke skelne dem, et revisionsspor kan heller ikke, og tilbagekaldelse af det certifikat fjerner begge på én gang. Det kan være præcis, hvad et bevidst design for høj tilgængelighed ønsker, og det er sjældent, hvad en hastig image-kopi har i sinde.

Så den første beslutning er en sætning, skrevet ned før imaget forlader build-værten: denne kopi gendanner gateway A, eller denne kopi bliver gateway B. Alt derefter er bogholderi mod den sætning. Hvis ingen kan skrive den, er kopien ikke klar til at blive bygget.

Genbrugelige input, identitet og autoritet, udrulningstilstand

Den genbrugelige spand er den nemme: pakker, gennemgået konfiguration uden hemmeligheder, tjenesteskabeloner, hærdningsindstillinger. Det er her, et image for alvor er godt, og det kan gengives uden grænse.

Spanden for identitet og autoritet er der, hvor kopier går galt. En gateways private nøgle og certifikat identificerer den gateway over for hver klient. Certifikatmyndighedens signeringsnøgle er et andet objekt med en anden magt: den udsteder identiteter. At stole på en udsteder betyder ikke, at hver ny gateway har brug for evnen til at udstede, og at sende signeringsnøglen med inde i et image giver den evne til alt, der kan læse imaget.

Spanden for udrulningstilstand er den, folk glemmer, fordi den ligner konfiguration. Lytteadresser, adressepuljer, push-ruter, resolver-indstillinger og lokal integration koder alle antagelser om den første vært. En anden node, der kopierer dem, kan allokere fra en pulje, som en anden gateway allerede ejer, eller pege klienter mod en ressource, der kun findes ved siden af originalen.

Hvad en ny node skal have, og af hvem

En selvstændigt administreret node bør modtage sine egne legitimationsoplysninger gennem den godkendte registreringsproces, med signeringsoperationen hvor signeringsnøglen bor i stedet for på den nye vært. Notér, hvilken identitet der kan trækkes tilbage uden at forstyrre de andre noder; hvis svaret er "alle", har designet én identitet, der foregiver at være to.

Netværksværdier fortjener samme behandling. Vælg en pulje, en lytteadresse og et sæt push-ruter, der ikke kolliderer med den eksisterende gateway, og skriv dem i provisioneringsinputtet i stedet for i imaget. Inputtet kan gennemgås; imaget kan ikke.

Der findes et legitimt mellemtilfælde. Et understøttet gendannelses- eller replikeringsdesign kan bevidst holde én logisk tjenesteidentitet på tværs af værter, med kontrolleret adgang til den gamle kopi og en rotationsplan. Det er en beslutning med en ejer, ikke en standard, der sker, fordi imaget var bekvemt.

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 kommando fortæller, hvilken identitet noden faktisk præsenterer, og hvem der har signeret den. Den anden er en startopgørelse, ikke et bevis: privat materiale kan ligge uden for den mappe, i en applikationsdatabase eller i et snapshotlag, som det kørende filsystem ikke længere viser.

Hvad en kopi af imaget stille bærer med sig

At slette en fil fra den nyeste revision af et image fjerner den ikke fra ældre revisioner, lagercache eller snapshots taget, mens den fandtes. Derfor skal images med legitimationsoplysninger behandles som følsomme objekter hele deres levetid, ikke kun i det øjeblik de bygges.

Kontrollér imageindholdet og provisioneringsinputtet som separate spørgsmål. Imaget svarer på "hvad er inde i dette artefakt", mens inputtet svarer på "hvad bliver denne instans ved første opstart". Et rent image med et bootstrap-script, der henter en delt nøgle, svarer godt på det første spørgsmål og dårligt på det andet.

Hold gendannelsesimages, der legitimt indeholder hemmeligheder, begrænset til de personer, der har brug for dem, og notér, hvor de opbevares. Alternativet, et image der er bekvemt, fordi det virker uden nogen provisionering, er det samme image, der giver enhver, der finder det, gatewayens identitet. Kun én af de to opgaver dukker op i en build-log.

Adgangskontroller før produktion

Før noden tager trafik, bekræft fire ting: den identitet, den præsenterer, de klienter, den vil acceptere, de ressourcer, den må nå, og returvejen for de adresser, den uddeler.

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

Kontrollér derefter det negative tilfælde, som er det, der fanger ulykker: har den nye node administrator- eller klientadgang, der var beregnet til originalen? En kopieret konfiguration kan bære en ekstra klientpost, en nedarvet administrationsrute eller en push-direktiv, der gav mening på den første vært.

Hvis et image med levende hemmeligheder allerede har bevæget sig ud over sin godkendte grænse, udskift legitimationsoplysningerne, og indgræns kopierne. At fjerne filen fra det seneste build er ikke det samme som at tage de legitimationsoplysninger ud af drift, som ældre kopier stadig har, og kløften mellem de to kendsgerninger er præcis det vindue, en angriber har brug for.