Hver gang du deler en Compose-fil, findes der to artefakter: det, du skrev, og det, et værktøj genererer, efter at variabler er erstattet. Det andet er ofte mere følsomt end det første, og det er det, folk sætter ind i en fejlrapport uden at læse det. Hvis du kun gennemgår kildefilen, gennemgår du det forkerte dokument.

Sammenlign, hvad hver kopi kan indeholde, før du beslutter, hvad der skal fjernes.

Den genererede model er et andet dokument

Compose udfolder miljøvariabler, fletter override-filer og producerer en effektiv konfiguration, som en læser ikke længere kan skelne fra håndskrevne værdier. En reference som et variabelnavn i kilden bliver selve kontotokenet i outputtet. Den struktur, der gør filen nyttig til diagnostik, overlever den transformation; det gør alt, hvad der aldrig burde have været i den, også.

Generer filen selv, før du vedhæfter den, og behandl det output som det artefakt, der gennemgås. Hvis du ikke kan generere den, kan du ikke vide, hvad du er ved at offentliggøre.

Hemmeligheder sidder flere steder end i nøglefeltet

Begynd med det åbenlyse: private nøgler, foruddelte nøgler, tokens, adgangskoder og forbindelses-URL’er, der indlejrer legitimationsoplysninger. Se derefter på alt, hvad filen peger på, fordi en reference ikke er en redigering. En miljøfil, der er monteret i tjenesten, en konfigurationsfil, der er bundet fra værten, et label, der bærer et token, og et kommandoparameter, der indeholder en adgangskode, rejser alle med udrulningen, selv når YAML’en ser ren ud. En nøgle, der er indsat i en variabel med et beroligende navn, er stadig en nøgle.

Værtstier og tjenestenavne lækker en anden slags information. Et hjemmemappenavn, et internt værtsnavn eller et netværksområde kan identificere en person eller en organisation uden at indeholde en enkelt legitimationsoplysning, og den kontekst er værd at fjerne af samme grund.

En hemmelighedserklæring er ikke hemmeligheden

Compose-hemmelighedsobjekter adskiller erklæringen fra materialet: tjenesten får en sti eller et mål, og indholdet bor et andet sted. At beholde erklæringen og erstatte materialet er normalt den rigtige byttehandel, fordi gennemlæseren skal kunne se, at en hemmelighed findes, og hvordan den er monteret. Det, der ikke må overleve, er indholdet selv.

Labels og kommentarer fortjener samme behandling. En kommentar, der siger, hvilken bokssti der holder produktionsnøglen, fortæller en angriber, hvor der skal kigges, selv om den ikke indeholder en nøgle.

Behold formen, så filen stadig kan diagnosticere

En redigering, der fjerner netværkstilstanden, image-versionen eller kapabilitetsindstillingerne, producerer en fil, som ingen kan fejlfinde med. Erstat de følsomme værdier, og behold relationerne: hvilken tjeneste monterer hvad, hvilket netværk den tilslutter sig, hvilken enhed den har brug for. Det er den del, en læser bruger til at forklare en manglende rute eller en utilgængelig enhed. Det er også den version, en kollega kan sammenligne med sin egen fungerende udrulning.

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

Udrul ikke den redigerede kopi, som om den var det fungerende original. Det er en beskrivelse, og en beskrivelse, der er redigeret til at se sikker ud, vil fejle på måder, der ligner konfigurationsfejl.

Hvis materiale er blevet afsløret, skal du erstatte det

At fjerne vedhæftningen fjerner ikke de kopier, andre allerede har lavet, og spejle og caches beholder deres egne. Brug udstederens tilbagekaldelses- og erstatningsproces for alt, hvad der er lækket, og opdater derefter udrulningen. Rækkefølgen betyder noget, fordi erstatning først og tilbagekaldelse senere efterlader et vindue med to gyldige legitimationsoplysninger.

I supporttråde skal du begynde med den præcise fejl, image-versionen, netværkstilstanden og den ene ikke-hemmelige indstilling, der betyder noget. Den kombination forklarer en manglende enhed eller en brudt rute meget oftere end nøglen.

Relaterede artikler