En VPN-konfiguration överlever bara återskapandet av containern om du monterar den
En fil som redigeras i en körande container bor i ett lager som försvinner. Jämför bind mounts, volymer och secrets, återskapa sedan och verifiera fyra saker.
Du redigerar WireGuard-konfigurationen inuti en körande container, det fungerar, och nästa image-uppdatering raderar den. Ingenting var felkonfigurerat. Filen bodde i containerns skrivbara lager, som bara finns för den containerinstansen. Jämförelsen som spelar roll är inte vilket verktyg du använder, utan vilka indata din utrullning deklarerar. Allt du har redigerat för hand är indata som utrullningen inte känner till.
Två slags tillstånd, det ena är engångs
En container har ett skrivbart lager för ändringar som görs under körning, och det lagret kastas när containern ersätts. Det är inte ett konfigurationslager och inte en säkerhetskopia. Imagen plus de deklarerade indata är hela definitionen av vad som körs.
Fråga vilka av dina VPN-filer som är deklarerade indata och vilka som är tillfälligheter:
docker diff wg-vpn
docker inspect --format '{{json .Mounts}}' wg-vpnDiff listar vad som ändrats i det skrivbara lagret, och det är precis mängden saker som kommer att försvinna. Mount-listan visar vad som överlever. Att jämföra de två svarar på frågan innan du förlorar något.
Bind mount, namngiven volym eller secret: vad var och en skyddar
Alla tre kan hålla en VPN-profil, och de skiljer sig i vem som kan läsa den och vad som händer vid ersättning.
| Mechanism | Survives recreation | Who can read it |
|---|---|---|
| Writable layer | No | Anyone with container access, until it is gone |
| Bind mount | Yes, while the host path exists | Whatever the host permissions allow |
| Named volume | Yes, until the volume is removed | Managed by the runtime |
| Secret | Yes, as a declared input | The container process, by design |
En bind mount mappar en värdssökväg, så filen är lika skyddad som den sökvägen och lika synlig som värdens rättigheter tillåter. En namngiven volym hanteras av runtime och överlever borttagning av containern, vilket gör den till det säkrare standardvalet för tillstånd som utrullningen äger. En secret-mekanism är för material som du inte vill ha i en image eller en miljövariabel.
Behandla inte varje miljövariabel och varje värdskfil som likvärdigt skydd, för det är de inte.
Att redigera inuti containern är fällan
Fällan är inte verktyget, utan riktningen på redigeringen. En ändring gjord inuti en körande container är osynlig för utrullningen, så nästa återskapande rullar tyst tillbaka den och symptomet ser ut som en regression i imagen. Om du måste ändra något där för att diagnostisera, kopiera ut det direkt och lägg det i det deklarerade indata. Återskapa sedan för att bevisa att utrullningen reproducerar det.
En profil kan bära privata nycklar och kontomaterial, vilket gör en säkerhetskopia av den filen till en uppgift för hemlighetshantering i stället för en filkopia. Håll ägarskap och läsåtkomst begränsade till containerns faktiska process i stället för att vidga en värdskatalog så att ett behörighetsfel försvinner.
Den vidgningen är hur en bekvämlighet i containern blir en exponering av värden.
Återskapa medvetet och verifiera sedan fyra saker
Notera imageversionen, enheten och förmågorna som krävs, nätverksanslutningen och de beständiga indata. Listan över enheter och förmågor är särskilt viktig för en VPN-container, eftersom tunneln behöver nätverksenheten och behörigheten att konfigurera den.
Bekräfta vilket genererat körtidstillstånd som ska byggas upp igen i stället för att sparas. Nycklarna som tunneln genererade vid första starten är tillstånd, och att behålla dem eller generera dem igen är ett beslut med konsekvenser för varje peer som känner till den gamla publika nyckeln.
Efter ett kontrollerat återskapande, verifiera identitet, routing, DNS och den nödvändiga felspärren. En process som startar utan fel bevisar ingen av de fyra. Kontrollera det medan tunneln är uppe och igen efter att du har stoppat den, eftersom felspärren bara visar sig när tunneln försvinner.
Håll en återställningskopia utanför containern
Håll en återställningskopia som lever oberoende av containern, och testa att återställa den via den dokumenterade processen. En otestad säkerhetskopia av en VPN-profil är ett hopp, särskilt när återställningsvägen involverar behörigheter som containerprocessen behöver.
Om en container som äger en VPN ersätts, samordna applikationerna som delar dess nätverksstack inom den livscykel som runtime stöder.
Den samordningen är skillnaden mellan en omstart och ett avbrott. Utrullningen bör beskriva var konfigurationen kommer från, och volymdokumentationen är platsen att kontrollera vad runtime faktiskt bevarar.