Bygg om en Raspberry Pi VPN-apparat utan att kopiera dess nyckel

Att starta en gång från en avbild gör inte en Pi till en apparat som kan byggas om. Det som behövs är en liten uppsättning indata som kan tillämpas igen: en underhållen bas, en deklarerad konfiguration, applikationens beständiga data och en enhetsidentitet som bara tillhör det kortet. Missar du den sista blir varje utbyte en klon av en autentiseringsuppgift.

Stegen nedan är en arbetsordning, inte en verktygsrekommendation. Alla konfigurationssystem som kan uttrycka dem duger.

Lista de fyra typerna av indata först

Basavbilden och dess paket definierar operativsystemet, arkitekturen och varifrån uppdateringarna kommer, och en avbildsbyggare hjälper bara om verktyget den namnger fortfarande underhålls för din utgåva. Den deklarerade konfigurationen är den del en människa granskar: nätverksroller, tjänsteinställningar och de livscykelåtgärder varje tjänst behöver. Beständiga applikationsdata är allt tjänsten inte kan återskapa, och deras placering och säkerhetskopieringsmetod tillhör applikationen, inte avbilden. Enhetsidentiteter och hemligheter är den fjärde indatan, och det är dem folk glömmer när de klonar ett fungerande kort.

Skriv de fyra listorna innan du bygger om något. En lista med en tom rad är ett beslut du ännu inte har fattat.

Håll hemligheter utanför repositoriet och säg var de bor

Ett repositorium är ett bra hem för granskade mallar och icke-hemlig konfiguration, och ett dåligt hem för privata VPN-nycklar, återanvändbara administratörsuppgifter och diagnostikarkiv. Om en hemlighet måste finnas på enheten, notera var den kommer ifrån, vem som får läsa den och hur den roteras. En nyckel som bara lever på ett SD-kort är en enda felpunkt, medan en nyckel kopierad till varje kort är en autentiseringsuppgift för hela flottan utan ägare. Ingen av dem är en återställningsplan.

Testet är enkelt: om repositoriet läckte i morgon, vad skulle en angripare vinna? Mallar och topologinoteringar överlever. En fungerande identitet gör det inte.

Låt automatiseringen äga det den kan köra igen

Ansibles modell håller ett inventarium av hanterade noder åtskilt från spel, uppgifter, roller och hanterare som utlöses när en uppgift rapporterar en ändring. Använd den strukturen för att ge varje tjänst en enda konfigurationsägare i stället för att spela upp en skallhistorik. Föredra åtgärder som är säkra att köra två gånger, och avgör medvetet hur en ändrad fil når den körande processen. En uppgift som säkerställer att en tjänst är startad får den inte nödvändigtvis att läsa in en konfiguration du just skrev om.

Separera också administratörsfaserna. Uppstartskonnektivitet, rutinkonfiguration och VPN-beroende hantering är tre olika fönster, och det tredje kan ta bort din egen åtkomst om ombyggnaden återställer nätverket under det. Behåll en oberoende väg in.

Återställ data och identitet med avsikt

Containervolymer består oberoende av containerns livscykel, medan det skrivbara lagret inuti en container inte gör det, och därför återskapar en container från sin avbild inte det tillstånd applikationen använde, såsom volymernas dokumentation beskriver. Notera volymerna, bind-monteringarna och de externa tjänster apparaten är beroende av, och använd applikationens egen säkerhetskopierings- och återställningsprocess. En container som startar utan fel är inte bevis för att dess databas och filer stämmer överens.

För identitet, avgör om du återställer samma enhet eller registrerar en ersättare, eftersom det är olika åtgärder med olika städning.

Stäm av den gamla peerns åtkomst innan du aktiverar en identitet någon annanstans, och testa först därefter den ombyggda apparaten i en isolerad miljö eller återställningsmiljö. Kontrollera nödvändiga data, rätt identitet, en uppdateringsväg med ägare och den avsedda nätverkspolicyn.

En startbar avbild är en av fyra indata, och den är lättast att återskapa.