⬡

compose-validator

Fang opp sikkerhetsrisikoer i containere

Inndata

services:
  api:
    image: example/api:latest
    ports:
      - "8080:8080"
    environment:
      - DB_PASSWORD=change-me
    privileged: true

Resultat5 funn

!privileged: true gir nesten tilgang på vertsnivå.
!Et passord står i klartekst. Bruk secrets eller en ekstern secret-store.
△Fest bildet til en uforanderlig versjon eller digest i stedet for :latest.
△Publisert port ser ut til å være åpen på alle grensesnitt; bind til 127.0.0.1 når mulig.
△Vurder read_only: true når rotfilsystemet ikke trenger å være skrivbart.

Innledning

compose-validatoren gjennomgår en innlimt compose.yaml for fem container-sikkerhetsrisikoer som dukker opp i produksjonshendelser: privilegert modus, hemmeligheter i klartekst, ikke-festede bilder, porter bundet til alle grensesnitt og et skrivbart rotfilsystem.

Compose-filer leses som konfigurasjon, men de blir sikkerhetsgrensen for containerne dine. Små feil her oversettes direkte til risiko på vertsnivå.

Mål

Merk privileged: true, som er nær tilgang på vertsnivå.
Oppdag passord og påloggingsinformasjon skrevet direkte i filen.
Advar om :latest-bildetagger, som ikke er reproduserbare.
Advar om publiserte porter som er åpne på alle grensesnitt, og om fravær av read_only: true.

Inndata

Et utklipp av compose.yaml (eller services-delen av den).
YAML-strukturen analyseres ikke dypt; kontrollene er mønsterbaserte på den synlige teksten.

Slik fungerer det

Filen skannes med fem mønsterkontroller. privileged: true er et høyt funn fordi det gir nesten alle capabilities og slår av det meste av isolasjonen.

Enhver linje med en passordtilordning (password: eller PASSWORD=) er et høyt funn: hemmeligheter hører hjemme i Docker secrets eller en ekstern secret-store.

image: ...:latest gir en advarsel fordi den samme filen kan hente forskjellig innhold over tid; en uforanderlig digest eller en festet versjon er reproduserbar.

En publisert port (vert:container) som ikke er bundet til 127.0.0.1 er en advarsel, det samme er en tjeneste uten read_only: true på rotfilsystemet sitt.

Testbart eksempel

Prøv det — analysen kjører lokalt i nettleseren din.

Eksempel

services:
  api:
    image: example/api:latest
    ports:
      - "8080:8080"
    environment:
      - DB_PASSWORD=change-me
    privileged: true

Forventet utdata

Høyt: privileged: true gir nesten tilgang på vertsnivå.
Høyt: Et passord står i klartekst. Bruk secrets eller en ekstern secret-store.
Advarsel: Fest bildet til en uforanderlig versjon eller digest i stedet for :latest.
Advarsel: Publisert port ser ut til å være åpen på alle grensesnitt.
Advarsel: Vurder read_only: true når rotfilsystemet ikke trenger å være skrivbart.

Les utdataene

Fjern privilegert modus når det er mulig; de fleste arbeidsmengder trenger bare spesifikke capabilities.
Flytt innebygde hemmeligheter til Docker secrets eller en ekstern vault, og roter alt som har blitt lagret i versjonskontroll.
Festede tagger eller digester gjør distribusjoner reproduserbare og rulleback forutsigbare.
Å binde porter til 127.0.0.1 holder tjenester private med mindre en proxy bevisst eksponerer dem.

Risikoer

privileged: true på en kompromittert container er i praksis kompromittering av verten.
Innebygde passord lekker inn i bilder, registre og logger og roteres aldri rent.
:latest bryter rulleback: gårsdagens fungerende bilde kan overskrives av dagens ødelagte build.

Begrensninger

Mønsterkontroller kan gå glipp av risikoer uttrykt med YAML-ankere, miljøfiler eller Dockerfile-instruksjoner.
Det kjører ikke Compose-parseren, så YAML-syntaksfeil rapporteres ikke her.
Det kan ikke oppdage sårbarheter i selve bildene.

Offisielle referanser

FAQ

Når er privileged: true berettiget?

Nesten aldri i produksjon. Noen eldre drivere og spesifikk enhetstilgang trenger det, men den trygge veien er å gi de nøyaktige capabilities som kreves og bruke devices: for maskinvaretilgang.

Hva bør jeg bruke i stedet for innebygde passord?

Docker secrets for swarm, miljøfiler med begrensede rettigheter og eksterne referanser for vault-lignende hemmeligheter. Poenget er at hemmeligheter aldri ligger i compose-filen eller bildet.

Bryter read_only: true apper som skriver filer?

Bare hvis de skriver til rotfilsystemet. Skrivbare baner (opplastinger, mellomlagre) kan monteres som volumer eller erklæres med tmpfs, mens resten forblir skrivebeskyttet.