Delar du en VPN Compose-fil? Ta bort hemligheterna från den renderade kopian

Varje gång du delar en Compose-fil finns två artefakter: den du skrev och den ett verktyg renderar efter att variablerna ersatts. Den andra är ofta känsligare än den första, och det är den folk klistrar in i en felrapport utan att läsa den. Om du bara granskar källfilen granskar du fel dokument.

Jämför vad varje kopia kan innehålla innan du bestämmer vad som ska tas bort.

Den renderade modellen är ett annat dokument

Compose löser upp miljövariabler, slår ihop överstyrningsfiler och producerar en effektiv konfiguration som en läsare inte längre kan skilja från handskrivna värden. En referens som ett variabelnamn i källan blir själva kontotoken i utdata. Strukturen som gör filen användbar för diagnostik överlever den transformationen; det gör också allt som aldrig borde ha funnits i den.

Rendera filen själv innan du bifogar den och behandla den utdata som artefakten du granskar. Om du inte kan rendera den kan du inte veta vad du är på väg att publicera.

Hemligheter sitter på fler ställen än i nyckelfältet

Börja med det uppenbara: privata nycklar, fördelade nycklar, tokens, lösenord och anslutnings-URL:er som bäddar in inloggningsuppgifter. Titta sedan på allt filen pekar på, för en referens är inte en borttagning. En miljöfil som monterats i tjänsten, en konfigurationsfil som bundits från värden, en etikett som bär en token och ett kommandoargument som innehåller ett lösenord reser alla med utrullningen även när YAML:en ser ren ut. En nyckel som klistrats in i en variabel med ett lugnande namn är fortfarande en nyckel.

Värdvägar och tjänstenamn läcker en andra sorts information. Ett hemkatalognamn, ett internt värdnamn eller ett nätverksområde kan identifiera en person eller organisation utan att innehålla en enda inloggningsuppgift, och den kontexten är värd att ta bort av samma skäl.

En hemlighetsdeklaration är inte hemligheten

Compose hemlighetsobjekt skiljer deklarationen från materialet: tjänsten får en sökväg eller ett mål, och innehållet bor någon annanstans. Att behålla deklarationen medan materialet byts ut är oftast rätt byte, eftersom granskaren behöver se att en hemlighet finns och hur den monteras. Det som inte får överleva är innehållet självt.

Etiketter och kommentarer förtjänar samma behandling. En kommentar som säger vilken valvsökväg som håller produktionsnyckeln talar om för en angripare var den ska titta även om den inte innehåller någon nyckel.

Behåll formen så att filen fortfarande kan diagnostisera

En borttagning som tar bort nätverksläget, image-versionen eller kapacitetsinställningarna ger en fil som ingen kan felsöka med. Ersätt de känsliga värdena och behåll relationerna: vilken tjänst monterar vad, vilket nätverk den ansluter till, vilken enhet den behöver. Det är den del en läsare använder för att förklara en saknad rutt eller en otillgänglig enhet. Det är också den version en kollega kan jämföra med sin egen fungerande utrullning.

docker compose -f compose.yaml config > rendered.yaml
grep -nE 'PRIVATE_KEY|PASSWORD|TOKEN|PSK|PrivateKey|passphrase' rendered.yaml
wc -l rendered.yaml

Rulla inte ut den redigerade kopian som om den vore det fungerande originalet. Det är en beskrivning, och en beskrivning som redigerats för att se säker ut kommer att misslyckas på sätt som liknar konfigurationsfel.

Om material har exponerats, byt ut det

Att ta bort bilagan tar inte bort de kopior som andra redan gjort, och speglar och cachar behåller sina egna. Använd utgivarens återkallnings- och ersättningsprocess för allt som läckt och uppdatera sedan utrullningen. Ordningen spelar roll, eftersom ersättning först och återkallning senare lämnar ett fönster med två giltiga inloggningsuppgifter.

I supporttrådar, börja med det exakta felet, image-versionen, nätverksläget och den enda icke-hemliga inställning som spelar roll. Den kombinationen förklarar en saknad enhet eller en bruten rutt mycket oftare än nyckeln.