Hvordan Docker-hemmeligheter fungerer, og hvor utviklere misbruker dem
Docker-hemmeligheter ble introdusert for å administrere sensitive data som API-nøkler, databasepassord og tokens på en sikker måte. De fungerer ved å montere hemmeligheter som filer i /løp/hemmeligheter inne i en container, kun tilgjengelig for den containeriserte tjenesten. Denne mekanismen holder hemmeligheter ute av miljøvariabler og logger, i hvert fall i teorien. Problemet starter når utviklere omgår denne mekanismen. I stedet for å bruke Docker Compose-hemmelighetene funksjonen riktig, hemmeligheter er ofte hardkodet inn Dockerfile, committett til Git, eller injisert gjennom miljøvariabler. Disse snarveiene gjør hemmeligheter sårbare for utilsiktet eksponering gjennom logger, containerlag eller versjonshistorikk.
# Risky
ENV DB_PASSWORD=mysecretpassword
⚠️ Usikkert eksempel, ikke bruk i produksjon
Når denne linjen er lagt til, legges den inn i bildet. Alle som har tilgang til bildet (byggebuffer, register eller CI/CD logger) kan trekke den ut. Enda verre er det at dette mønsteret ofte går ubemerket hen under gjennomganger fordi det «bare fungerer».
Docker Compose Secrets og de skjulte risikoene i delte konfigurasjoner
Docker Compose forenkler apper med flere containere, men Docker Compose-hemmeligheter kommer med skjulte risikoer. Utviklere deler ofte Docker Compose.yml or .og V filer på tvers av team og miljøer, via Git, Slack eller delte disker.
services:
app:
image: myapp
secrets:
- db_password
secrets:
db_password:
file: ./secrets/db_password.txt
⚠️ Demonstrasjonseksempel, ikke inkluder ekte hemmeligheter i versjonerte filer
Problemet? Disse Docker komponere hemmeligheter referanser antar lokale filer, men i praksis blir disse filene versjonert eller distribuert på en usikker måte. Hemmeligheter sniker seg inn i Git-repoer, dukker opp i pull requests, eller bli kopiert til andre mapper. Antagelsen om at «vi alle vet at vi ikke skal commit «hemmeligheter» er ikke en sikkerhetspolicy.
Verre er det at miljøer som iscenesettelse og produksjon kan gjenbruke det samme Docker-compose.yml, noe som skaper en falsk følelse av separasjon. En feilkonfigurert .og V fil, og produksjonshemmeligheter injiseres i et testmiljø.
CI/CD Pipelines: Der Docker Secret Handling bryter
In CI/CD, Docker-hemmeligheter falle fra hverandre hvis de ikke isoleres. Hemmeligheter lekker ofte på tre steder: logger, bildelag og delte løpere.
Logger: CI-trinn utskrift ekko $HEMMELIG_KEY for å feilsøke problemer. Men disse loggene lagres, noen ganger offentlig. Verktøy som GitHub-handlinger or GitLab lagre logger i dager eller uker.
BildelagHvis en Dockerfile legger til en hemmelighet under bygging:
RUN echo "$SECRET_KEY" > /app/config.txt
⚠️ Usikkert eksempel, dette avslører hemmeligheter i bildelag
Det Docker-hemmelighet er nå en del av et bildelag. Selv om du sletter filen senere, forblir det forrige laget i bildehistorikken.
Delte løpere: Mange CI/CD Plattformer bruker delte løpere. Hvis hemmeligheter ikke er riktig omfangsdefinert eller ryddet opp, kan andre bygg få tilgang til dem. Enda verre er det at hemmeligheter noen ganger sendes som miljøvariabler til alle trinn som standard.
Sikring av Docker i kode, Pipelines og registre
Å låse ned Docker-hemmeligheter, utviklingsteam trenger lagdelte forsvar:
- Bruk hemmelige administratorer som AWS Secrets Manager, HashiCorp Vault eller Doppler. Disse verktøyene roterer og injiserer hemmeligheter sikkert i containerne dine under kjøring.
- Begrens omfangAldri eksponer produksjonshemmeligheter i utviklings-/testmiljøer. Bruk rollebasert tilgangskontroll (RBAC) for å begrense hvem som kan injisere eller lese hemmeligheter.
- Unngå ENV-variabler for hemmeligheter. Bruk Docker-hemmelighet volumer eller montere hemmeligheter som filer eksplisitt.
- Rydd opp i byggSørg for at hemmeligheter ikke er bakt inn i bilder eller liggende igjen i mellomliggende filer.
- Skann containere og repositorierBruk verktøy som inspiserer bilder, git-historikk og CI/CD konfigurasjoner for lekkede hemmeligheter.
Beste fremgangsmåter for å forhindre eksponering av Docker-hemmeligheter
- Flyktige hemmeligheterGenerer engangshemmeligheter under CI-kjøringer. Disse utløper og kan ikke brukes på nytt hvis de blir stjålet.
- Forseglede hemmeligheterBruk Kubernetes Sealed Secrets eller SOPS for å kryptere hemmeligheter i Git. Dette sikrer at hemmeligheter versjoneres sikkert.
- CI/CD PolitikkHåndhev retningslinjer som ingen hemmeligheter i Dockerfile, blokkbygging basert på hemmelighetsdeteksjon og loggbruk av Docker-hemmeligheter for pipeline.
- Pre-commit hooks: Blokker commitmed hemmeligheter ved hjelp av verktøy som git-hemmeligheter or oppdage hemmeligheter.
- Uforanderlig infrastrukturIkke endre hemmeligheter i containere. Gjenoppbygg og distribuer på nytt med nye Docker-hemmeligheter i stedet.
Konklusjon
Når det misbrukes, Docker-hemmeligheter bli en belastning i stedet for en sikkerhetsfunksjon. Fra Docker Compose-hemmeligheter lekker gjennom YAML-filer til CI/CD pipelineVed å avsløre hemmeligheter i logger eller lag, er risikoen reelle og forebyggbare.
Bruke verktøy som Xygeni, team kan oppdage eksponerte hemmeligheter tidlig, håndheve retningslinjer for håndtering av hemmeligheter og skanne etter sikkerhetsavvik på tvers av kode, containere og pipelines. Behandle din Docker hemmelighet strategi som kritisk infrastruktur. Sikre det slik du mener det.
