Deler du en VPN Compose-fil? Fjern hemmelighetene fra den renderte kopien

Hver gang du deler en Compose-fil, finnes det to artefakter: den du skrev, og den et verktøy renderer etter at variablene er erstattet. Den andre er ofte mer følsom enn den første, og det er den folk limer inn i en feilrapport uten å lese den. Hvis du bare går gjennom kildefilen, går du gjennom feil dokument.

Sammenlign hva hver kopi kan inneholde før du bestemmer hva som skal fjernes.

Den renderte modellen er et annet dokument

Compose løser opp miljøvariabler, slår sammen overstyringsfiler og produserer en effektiv konfigurasjon som en leser ikke lenger kan skille fra håndskrevne verdier. En referanse som et variabelnavn i kilden blir selve kontotokenet i utdataet. Strukturen som gjør filen nyttig for diagnostikk overlever den transformasjonen; det gjør også alt som aldri burde ha vært i den.

Render filen selv før du legger den ved, og behandle det utdataet som artefakten du går gjennom. Hvis du ikke kan rendre den, kan du ikke vite hva du er i ferd med å publisere.

Hemmeligheter sitter på flere steder enn nøkkelfeltet

Begynn med det åpenbare: private nøkler, forhåndsdelte nøkler, tokens, passord og tilkoblings-URL-er som bygger inn påloggingsinformasjon. Se deretter på alt filen peker på, fordi en referanse ikke er en fjerning. En miljøfil som er montert i tjenesten, en konfigurasjonsfil som er bundet fra verten, en etikett som bærer et token, og et kommandoparameter som inneholder et passord reiser alle med utrullingen selv når YAML-en ser ren ut. En nøkkel som er limt inn i en variabel med et beroligende navn, er fortsatt en nøkkel.

Vertbaner og tjenestenavn lekker en annen type informasjon. Et hjemmekatalognavn, et internt vertsnavn eller et nettverksområde kan identifisere en person eller en organisasjon uten å inneholde en eneste påloggingsinformasjon, og den konteksten er verdt å fjerne av samme grunn.

En hemmelighetsdeklarasjon er ikke hemmeligheten

Compose-hemmelighetsobjekter skiller deklarasjonen fra materialet: tjenesten får en bane eller et mål, og innholdet bor et annet sted. Å beholde deklarasjonen mens materialet erstattes er vanligvis den riktige byttehandelen, fordi gjennomleseren må se at en hemmelighet finnes og hvordan den er montert. Det som ikke må overleve, er innholdet selv.

Etiketter og kommentarer fortjener samme behandling. En kommentar som sier hvilken hvelvbane som holder produksjonsnøkkelen, forteller en angriper hvor de skal se, selv om den ikke inneholder en nøkkel.

Behold formen slik at filen fortsatt kan diagnostisere

En fjerning som tar bort nettverksmodusen, image-versjonen eller kapabilitetsinnstillingene, produserer en fil som ingen kan feilsøke med. Erstatt de følsomme verdiene og behold relasjonene: hvilken tjeneste monterer hva, hvilket nettverk den kobler seg til, hvilken enhet den trenger. Det er den delen en leser bruker for å forklare en manglende rute eller en utilgjengelig enhet. Det er også versjonen en kollega kan sammenligne med sin egen fungerende utrulling.

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

Ikke rull ut den redigerte kopien som om den var det fungerende originaldokumentet. Det er en beskrivelse, og en beskrivelse som er redigert for å se trygg ut, vil feile på måter som ligner konfigurasjonsfeil.

Hvis materialet har blitt eksponert, bytt det ut

Å fjerne vedlegget fjerner ikke kopiene andre allerede har laget, og speil og cacher beholder sine egne. Bruk utstederens tilbakekallings- og erstatningsprosess for alt som lekket, og oppdater deretter utrullingen. Rekkefølgen betyr noe, fordi erstatning først og tilbakekalling senere etterlater et vindu med to gyldige påloggingsdata.

I støttetråder bør du starte med den nøyaktige feilen, image-versjonen, nettverksmodusen og den ene ikke-hemmelige innstillingen som betyr noe. Den kombinasjonen forklarer en manglende enhet eller en brutt rute mye oftere enn nøkkelen.