Klona en VPN-serveravbild utan att klona dess identitet

Avbildningen startar, tjänsten börjar och klienter ansluter. Det är ögonblicket att stanna och fråga vilken av två mycket olika operationer som just hände. Antingen återställer kopian en logisk gateway som fanns tidigare, eller så lägger den till en andra gateway i flottan. Båda är legitima, och de har olika konsekvenser för identitet och åtkomst. En maskin som kommer upp rent bevisar ingen av dem.

Tre villkor avgör svaret, och det är de tre hinkarna material en avbild kan bära. Sortera dem innan avbilden byggs, inte efter att den rullats ut två gånger.

Bestäm först vilken av de två operationerna du utför

En återställning behåller en tjänsteidentitet. Den gamla instansen är borta, namnet och certifikatet finns kvar, och klienter fortsätter att lita på samma slutpunkt. Ett tillägg skapar en andra identitet som klienter, loggar och återkallelse alla måste skilja på.

Skillnaden är inte kosmetisk. Om två levande värdar presenterar samma gateway-certifikat kan en klient inte skilja dem, en granskningskedja kan inte heller, och återkallelse av det certifikatet tar bort båda på en gång. Det kan vara precis vad en medveten design för hög tillgänglighet vill, och det är sällan vad en snabb avbildskopia avser.

Så det första beslutet är en mening, nedskriven innan avbilden lämnar byggvärden: den här kopian återställer gateway A, eller den här kopian blir gateway B. Allt efteråt är bokföring mot den meningen. Om ingen kan skriva den är kopian inte redo att byggas.

Återanvändbara indata, identitet och behörighet, utrullningstillstånd

Den återanvändbara hinken är den enkla: paket, granskad konfiguration utan hemligheter, tjänstemallar, härdningsinställningar. Det är vad en avbild verkligen är bra på, och den kan reproduceras utan gräns.

Hinken för identitet och behörighet är där kopior går fel. En gateways privata nyckel och certifikat identifierar den gatewayen för varje klient. Certifikatutfärdarens signeringsnyckel är ett annat objekt med en annan makt: den utfärdar identiteter. Att lita på en utfärdare betyder inte att varje ny gateway behöver förmågan att utfärda, och att skicka signeringsnyckeln inuti en avbild ger den förmågan till allt som kan läsa avbilden.

Hinken för utrullningstillstånd är den folk glömmer eftersom den ser ut som konfiguration. Lyssnaradresser, adresspooler, pushade rutter, resolverinställningar och lokal integration kodar alla antaganden om den första värden. En andra nod som kopierar dem kan tilldela från en pool som en annan gateway redan äger, eller peka klienter mot en resurs som bara finns intill originalet.

Vad en ny nod måste få, och av vem

En självständigt administrerad nod bör få egna autentiseringsuppgifter genom den godkända registreringsprocessen, med signeringen där signeringsnyckeln bor i stället för på den nya värden. Anteckna vilken identitet som kan dras tillbaka utan att störa de andra noderna; om svaret är "alla" har designen en identitet som låtsas vara två.

Nätverksvärden förtjänar samma behandling. Välj en pool, en lyssnaradress och en uppsättning pushade rutter som inte krockar med den befintliga gatewayen, och skriv dem i provisioneringsindata i stället för i avbilden. Indatan kan granskas; avbilden inte.

Det finns ett legitimt mellanfall. En stödd återställnings- eller replikeringsdesign kan medvetet behålla en logisk tjänsteidentitet över värdar, med kontrollerad åtkomst till den gamla kopian och en rotationsplan. Det är ett beslut med en ägare, inte ett standardvärde som händer för att avbilden var bekväm.

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

Det första kommandot berättar vilken identitet noden faktiskt presenterar och vem som signerade den. Det andra är en startinventering, inte ett bevis: privat material kan leva utanför den katalogen, i en applikationsdatabas eller i ett ögonblicksskikt som det körande filsystemet inte längre visar.

Vad en kopia av avbilden stilla bär med sig

Att ta bort en fil från den senaste revisionen av en avbild tar inte bort den från äldre revisioner, lagercache eller ögonblicksbilder tagna medan den fanns. Därför måste avbilder som bär autentiseringsuppgifter behandlas som känsliga objekt under hela sin livstid, inte bara när de byggs.

Kontrollera avbildens innehåll och provisioneringsindata som två separata frågor. Avbilden svarar på "vad finns inuti den här artefakten", medan indatan svarar på "vad blir den här instansen vid första start". En ren avbild med ett bootstrap-skript som hämtar en delad nyckel svarar bra på den första frågan och dåligt på den andra.

Håll återställningsavbilder som legitimt innehåller hemligheter begränsade till dem som behöver dem, och anteckna var de lagras. Alternativet, en avbild som är bekväm eftersom den fungerar utan någon provisionering, är samma avbild som ger vem som helst som hittar den gatewayens identitet. Bara en av de två uppgifterna syns i en bygglogg.

Behörighetskontroller före produktion

Innan noden tar trafik, bekräfta fyra saker: identiteten den presenterar, klienterna den tar emot, resurserna den får nå och returvägen för adresserna den delar ut.

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

Kontrollera sedan det negativa fallet, det som fångar olyckor: har den nya noden administratörs- eller klientåtkomst som var avsedd för originalet? En kopierad konfiguration kan bära en extra klientpost, en ärvd hanteringsrutt eller ett push-direktiv som gav mening på den första värden.

Om en avbild med levande hemligheter redan har flyttat utanför sin godkända gräns, byt ut autentiseringsuppgifterna och begränsa kopiorna. Att ta bort filen från den senaste bygget är inte samma sak som att ta autentiseringsuppgifterna ur bruk som äldre kopior fortfarande har, och gapet mellan dessa två fakta är exakt det fönster en angripare behöver.