Flytt Docker-hemmeligheter ut av miljøvariabler – Compose har en egen vei

Dockers veiledning for Compose secrets viser hvordan du gir en tjeneste eksplisitt tilgang til et passord eller token som en fil under /run/secrets/. Definer først hemmeligheten øverst i compose.yaml, og før den deretter opp under secrets for tjenesten som trenger den. Applikasjonen leser filen i containeren i stedet for å få selve verdien som miljøvariabel.

Kilden og bruken er to forskjellige ledd. En lokal fil eller en miljøvariabel på verten leverer verdien til Compose, mens tjenesten får en montert fil når den er tildelt hemmeligheten. Eksempelet nedenfor bruker en lokal fil og viser også en tjeneste som starter uten tilgang til den.

Hvorfor ikke bruke containerens miljø?

Dockers råd om miljøvariabler anbefaler varsomhet med sensitive verdier og å vurdere secrets. Miljøvariabler er praktiske for vanlig konfigurasjon, men et passord som sendes inn gjennom tjenestens environment eller env_file, ligger i prosessmiljøet. Andre prosesser i containeren kan arve verdien, og feilsøking kan føre til at den skrives i logger.

Med en secret står det i compose.yaml hvilken tjeneste som skal ha filen. En overordnet secrets-definisjon alene gir ingen tjeneste tilgang; tildelingen må også stå under den aktuelle tjenesten. Dette snevrer inn hvem som får verdien og gjør tilgangen synlig i konfigurasjonen. Det gjør ikke innholdet ufarlig: En prosess som kan lese filen inne i den tildelte containeren, kan fremdeles lese hemmeligheten. Løsningen krever derfor at applikasjonen behandler filen som sensitiv.

Et minimalt oppsett med fil på verten

Lag katalogen secrets ved siden av compose.yaml, og legg en fil med navnet api_token.txt der. Bruk en vilkårlig demoverdi hvis du vil prøve oppsettet. De neste to avsnittene er de to linjene i en komplett compose.yaml; skriv hver av dem på én linje. Den kompakte YAML-formen holder eksempelet kort, men har samme nøkkelstruktur som et innrykket Compose-dokument.

services: {app: {image: "alpine:latest", command: [sh, -c, "test -s /run/secrets/api_token && echo klar"], secrets: [api_token]}, worker: {image: "alpine:latest", command: [sh, -c, "test ! -e /run/secrets/api_token && echo uten-tilgang"]}}

secrets: {api_token: {file: ./secrets/api_token.txt}}

Den nederste linjen kobler navnet api_token til kildefilen ./secrets/api_token.txt på verten. Stien er relativ til Compose-filen, og filen må finnes der oppsettet kjøres. Den øverste linjen gir bare app en secrets-tildeling. I denne Linux-baserte demonstrasjonen skal app derfor finne innholdet som /run/secrets/api_token, mens worker ikke får den filen montert.

Kjør docker compose up fra prosjektkatalogen etter at du har opprettet kildefilen. Testkommandoen i app skriver klar bare hvis den monterte filen finnes og ikke er tom; kommandoen i worker skriver uten-tilgang bare hvis samme sti ikke finnes der. De skriver ikke ut tokenet. Dette er en demonstrasjon av tildeling og filtilgang, ikke en applikasjon som faktisk bruker et API-token.

Hold en virkelig kildefil utenfor versjonskontroll, og begrens hvem som kan lese den på verten. Hvis prosjektet bygger et eget containerbilde fra samme katalog, må du også unngå at filen tas med i byggekonteksten eller kopieres inn i bildet. Secret-tildelingen er ment å gi verdien ved kjøring, ikke å bake den inn i et bilde som kan distribueres videre.

Hvordan applikasjonen bruker verdien

Testkommandoen bruker ikke tokenet som applikasjonsdata; den undersøker bare at filen er tilgjengelig. En virkelig applikasjon må åpne /run/secrets/api_token og lese innholdet derfra når den trenger passordet eller tokenet. Et program som støtter konfigurasjon med en filsti til en hemmelighet, kan peke på den monterte filen. Da blir den sensitive verdien værende utenfor containerens miljøvariabler.

Noen containerbilder bruker en miljøvariabel som slutter på _FILE for dette formålet. Verdien av en slik variabel er filstien, for eksempel /run/secrets/api_token, ikke tokenet i filen. Det er en konvensjon i enkelte bilder, ikke noe Compose automatisk legger til i alle programmer. Sjekk derfor hvilken innstilling applikasjonen faktisk støtter. Dersom den bare godtar selve tokenet som miljøvariabel, må programmet eller oppstartslogikken tilpasses for å lese filen direkte.

Navnet etter /run/secrets/ følger normalt navnet på hemmeligheten som tjenesten får tildelt. I eksempelet er det api_token, selv om filen på verten heter api_token.txt og ligger i en annen katalog. Denne forskjellen er nyttig når samme oppsett flyttes mellom maskiner: Applikasjonen trenger den interne stien, mens Compose-konfigurasjonen bestemmer hvor kilden ligger.

Velg kilde uten å blande miljøene

Compose-referansen for secrets beskriver file og environment som kilder: Den første leser en fil, mens den andre henter verdien fra en miljøvariabel på verten. En environment-kilde er støttet av Docker Compose, men ikke når oppsettet distribueres med docker stack deploy.

Hvis verten allerede har API_TOKEN, kan den overordnede definisjonen i et Compose-oppsett bruke secrets: {api_token: {environment: API_TOKEN}}. Behold da secrets: [api_token] under app; applikasjonen leser fremdeles /run/secrets/api_token. Dette er en annen dataflyt enn environment: {API_TOKEN: ...} under app, som legger selve verdien i containerens miljø. Det avgjørende er hvor environment står, og om tjenesten er tildelt en secret.

Når du distribuerer med docker stack deploy

En secret med miljøvariabel på verten som kilde må få en annen kilde før samme definisjon brukes med docker stack deploy. Bruk en filbasert kilde eller referer til en ekstern secret som allerede finnes i plattformen. Tildelingen under tjenestens secrets må fremdeles være eksplisitt, slik at riktig tjeneste får tilgang til verdien.

Ta også hensyn til at eksempelet bruker en lokal fil. En filsti som fungerer på utviklingsmaskinen, er ikke automatisk tilgjengelig på maskinen der en stack distribueres. Sørg for at riktig kildefil finnes i distribusjonsmiljøet, og at applikasjonen fortsatt leser den tildelte filstien inne i containeren.

Les også:

• Kahoot eller Mentimeter: konkurranse og anonyme svar trekker hver sin vei
• GitHub Actions-hemmeligheter: loggmaskering er ingen garanti
• DeepL eller Google Oversetter: norsk tekst har ingen enkel vinner