⬡

Docker Compose Validator

Vang containerbeveiligingsrisico's op

Invoer

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

Resultaat5 bevindingen

!privileged: true geeft vrijwel toegang op hostniveau.
!Een wachtwoord staat in leesbare tekst. Gebruik secrets of een externe secretstore.
△Plaats de image op een onveranderlijke versie of digest in plaats van :latest.
△De gepubliceerde poort lijkt op alle interfaces open te staan; bind indien mogelijk aan 127.0.0.1.
△Overweeg read_only: true wanneer het rootbestandssysteem niet beschrijfbaar hoeft te zijn.

Inleiding

De Docker Compose Validator beoordeelt een geplakte compose.yaml op vijf containerbeveiligingsrisico's die in productie-incidenten opduiken: privileged mode, geheimen in leesbare tekst, niet-gepinde images, poorten die aan alle interfaces zijn gebonden en een beschrijfbaar rootbestandssysteem.

Compose-bestanden lezen als configuratie, maar ze worden de beveiligingsgrens van uw containers. Kleine fouten hier vertalen zich direct naar risico op hostniveau.

Doel

Markeer privileged: true, dat dicht bij toegang op hostniveau ligt.
Detecteer wachtwoorden en inloggegevens die inline in het bestand staan.
Waarschuw voor :latest-imagetags, die niet reproduceerbaar zijn.
Waarschuw voor gepubliceerde poorten die op alle interfaces openstaan en voor het ontbreken van read_only: true.

Invoerwaarden

Een plaksel van compose.yaml (of het services-gedeelte ervan).
De YAML-structuur wordt niet diep geparseerd; controles zijn patroongebaseerd op de zichtbare tekst.

Hoe het werkt

Het bestand wordt met vijf patrooncontroles gescand. privileged: true is een hoge bevinding omdat het vrijwel elke capability verleent en de meeste isolatie uitschakelt.

Elke regel met een wachtwoordtoewijzing (password: of PASSWORD=) is een hoge bevinding: geheimen horen in Docker secrets of een externe secretstore.

image: ...:latest levert een waarschuwing op omdat hetzelfde bestand na verloop van tijd andere inhoud kan trekken; een onveranderlijke digest of een gepinde versie is reproduceerbaar.

Een gepubliceerde poort (host:container) die niet aan 127.0.0.1 is gebonden, is een waarschuwing, net als een service zonder read_only: true op zijn rootbestandssysteem.

Testbaar voorbeeld

Probeer het — de analyse draait lokaal in uw browser.

Voorbeeld

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

Verwachte uitvoer

Hoog: privileged: true geeft vrijwel toegang op hostniveau.
Hoog: Een wachtwoord staat in leesbare tekst. Gebruik secrets of een externe secretstore.
Waarschuwing: Plaats de image op een onveranderlijke versie of digest in plaats van :latest.
Waarschuwing: De gepubliceerde poort lijkt op alle interfaces open te staan.
Waarschuwing: Overweeg read_only: true wanneer het rootbestandssysteem niet beschrijfbaar hoeft te zijn.

De uitvoer lezen

Verwijder privileged mode waar mogelijk; de meeste workloads hebben alleen specifieke capabilities nodig.
Verplaats inline geheimen naar Docker secrets of een externe vault, en roteer alles wat is vastgelegd.
Gepinde tags of digests maken implementaties reproduceerbaar en rollbacks voorspelbaar.
Poorten aan 127.0.0.1 binden houdt services privé, tenzij een proxy ze bewust blootstelt.

Risico's

privileged: true op een gecompromitteerde container is in de praktijk compromittering van de host.
Inline wachtwoorden lekken in images, registries en logs en worden nooit netjes geroteerd.
:latest breekt rollback: de werkende image van gisteren kan worden overschreven door de kapotte build van vandaag.

Beperkingen

Patrooncontroles kunnen risico's missen die met YAML-anchors, environment-bestanden of Dockerfile-instructies worden uitgedrukt.
Het voert de Compose-parser niet uit, dus YAML-syntaxisFouten worden hier niet gerapporteerd.
Het kan kwetsbaarheden in de images zelf niet detecteren.

Officiële referenties

FAQ

Wanneer is privileged: true gerechtvaardigd?

Vrijwel nooit in productie. Sommige legacy-drivers en specifieke apparaattoegang hebben het nodig, maar de veilige weg is de exact benodigde capabilities verlenen en devices: gebruiken voor hardwaretoegang.

Wat moet ik gebruiken in plaats van inline wachtwoorden?

Docker secrets voor swarm, environment-bestanden met beperkte rechten en externe verwijzingen voor vault-achtige geheimen. Het punt is dat geheimen nooit in het compose-bestand of de image staan.

Breekt read_only: true apps die bestanden schrijven?

Alleen als ze naar het rootbestandssysteem schrijven. Beschrijfbare paden (uploads, caches) kunnen als volumes worden gemount of met tmpfs worden gedeclareerd, terwijl de rest alleen-lezen blijft.