Klone et VPN-serverbilde uten å klone identiteten

Bildet starter, tjenesten går i gang, og klienter kobler til. Det er øyeblikket for å stoppe og spørre hvilken av to svært ulike operasjoner som nettopp skjedde. Enten gjenoppretter kopien én logisk gateway som fantes tidligere, eller den legger til en ny gateway i flåten. Begge er legitime, og de har ulike konsekvenser for identitet og tilgang. En maskin som kommer rent opp beviser ingen av dem.

Tre betingelser avgjør svaret, og det er de tre bøttene med materiale et bilde kan bære. Sorter dem før bildet bygges, ikke etter at det er rullet ut to ganger.

Avgjør først hvilken av de to operasjonene du utfører

En gjenoppretting beholder én tjenesteidentitet. Den gamle instansen er borte, navnet og sertifikatet blir, og klienter fortsetter å stole på samme endepunkt. En tilføyelse skaper en ny identitet som klienter, logger og tilbakekalling alle må skille.

Forskjellen er ikke kosmetisk. Hvis to levende verter presenterer samme gateway-sertifikat, kan en klient ikke skille dem, et revisjonsspor kan heller ikke, og tilbakekalling av det sertifikatet fjerner begge på én gang. Det kan være nettopp det en bevisst høyttilgjengelighetsdesign vil, og det er sjelden det en rask bildekopi har tenkt.

Så den første beslutningen er en setning, skrevet ned før bildet forlater byggeverten: denne kopien gjenoppretter gateway A, eller denne kopien blir gateway B. Alt etterpå er bokføring mot den setningen. Hvis ingen kan skrive den, er kopien ikke klar til å bygges.

Gjenbrukbare inndata, identitet og myndighet, utrullingstilstand

Den gjenbrukbare bøtta er den enkle: pakker, gjennomgått konfigurasjon uten hemmeligheter, tjenestemaler, herdingsinnstillinger. Det er dette et bilde virkelig er godt på, og det kan reproduseres uten grense.

Bøtta for identitet og myndighet er der kopier går galt. En gateways private nøkkel og sertifikat identifiserer den gatewayen overfor hver klient. Sertifikatmyndighetens signeringsnøkkel er et annet objekt med en annen makt: den utsteder identiteter. Å stole på en utsteder betyr ikke at hver ny gateway trenger evnen til å utstede, og å sende signeringsnøkkelen inne i et bilde gir den evnen til alt som kan lese bildet.

Bøtta for utrullingstilstand er den folk glemmer fordi den ser ut som konfigurasjon. Lyttadresser, adressepuljer, push-ruter, resolver-innstillinger og lokal integrasjon koder alle antakelser om den første verten. En ny node som kopierer dem kan tildele fra en pulje en annen gateway allerede eier, eller peke klienter mot en ressurs som bare finnes ved siden av originalen.

Hva en ny node må få, og av hvem

En selvstendig administrert node bør få egne legitimasjoner gjennom den godkjente registreringsprosessen, med signeringsoperasjonen der signeringsnøkkelen bor i stedet for på den nye verten. Noter hvilken identitet som kan trekkes tilbake uten å forstyrre de andre nodene; hvis svaret er "alle", har designet én identitet som later som den er to.

Nettverksverdier fortjener samme behandling. Velg en pulje, en lyttadresse og et sett push-ruter som ikke kolliderer med den eksisterende gatewayen, og skriv dem i provisjoneringsinndataene i stedet for i bildet. Inndataene kan gjennomgås; bildet kan ikke.

Det finnes et legitimt mellomtilfelle. Et støttet gjenopprettings- eller replikeringsdesign kan bevisst holde én logisk tjenesteidentitet på tvers av verter, med kontrollert tilgang til den gamle kopien og en rotasjonsplan. Det er en beslutning med en eier, ikke en standard som skjer fordi bildet 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 forteller hvilken identitet noden faktisk presenterer og hvem som signerte den. Den andre er en startoversikt, ikke et bevis: privat materiale kan ligge utenfor den katalogen, i en applikasjonsdatabase eller i et snapshot-lag som det kjørende filsystemet ikke lenger viser.

Hva en kopi av bildet stillferdig bærer med seg

Å slette en fil fra den nyeste revisjonen av et bilde fjerner den ikke fra eldre revisjoner, lagercache eller snapshots tatt mens den fantes. Derfor må bilder med legitimasjon behandles som følsomme objekter hele levetiden, ikke bare i øyeblikket de bygges.

Kontroller bildeinnholdet og provisjoneringsinndataene som separate spørsmål. Bildet svarer på "hva er inne i dette artefaktet", mens inndataene svarer på "hva blir denne instansen ved første oppstart". Et rent bilde med et bootstrap-skript som henter en delt nøkkel svarer godt på det første spørsmålet og dårlig på det andre.

Hold gjenopprettingsbilder som legitimt inneholder hemmeligheter begrenset til dem som trenger dem, og noter hvor de lagres. Alternativet, et bilde som er praktisk fordi det virker uten noen provisjonering, er det samme bildet som gir hver den som finner det gatewayens identitet. Bare én av de to oppgavene dukker opp i en byggelogg.

Adgangskontroller før produksjon

Før noden tar trafikk, bekreft fire ting: identiteten den presenterer, klientene den vil godta, ressursene den har lov til å nå, og returveien for adressene den 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 fanger ulykker: har den nye noden administrator- eller klienttilgang som var ment for originalen? En kopiert konfigurasjon kan bære en ekstra klientoppføring, en nedarvet administrasjonsrute eller en push-direktiv som ga mening på den første verten.

Hvis et bilde med levende hemmeligheter allerede har flyttet seg utover sin godkjente grense, erstatt legitimasjonen og begrens kopiene. Å fjerne filen fra den siste byggingen er ikke det samme som å ta ut av drift legitimasjonen som eldre kopier fortsatt har, og gapet mellom de to fakta er nøyaktig vinduet en angriper trenger.