Passa al contenuto principale

Dockerfile Hardening Checklist Akira

Checklist per ridurre attack surface, drift di build e findings Trivy.

Base Image​

  1. Usare immagini runtime minimali: python:3.12-slim per servizi Python e node:20-alpine per frontend Node.
  2. Valutare il pin a digest (@sha256:...) per release riproducibili. Quando si aggiorna il digest, rieseguire Trivy su PR prima del merge.
  3. Evitare immagini full-fat se il runtime non richiede toolchain di build.

Build​

  1. Preferire multi-stage build: stage builder separato e runtime con soli artifact necessari.
  2. Non copiare .git, .venv, node_modules, .env o cache locali nel build context. Mantenere .dockerignore allineato.
  3. Installare package OS con --no-install-recommends e rimuovere /var/lib/apt/lists/* nello stesso layer.
  4. Usare cache BuildKit solo per package manager cache, non per secret.

Runtime​

  1. Creare ed eseguire un utente non-root nel runtime stage (USER akira o UID dedicato).
  2. Usare CMD exec-form, per esempio ["uvicorn", "..."], evitando shell-form.
  3. Esporre solo la porta del processo applicativo.
  4. Aggiungere HEALTHCHECK coerenti con il servizio: backend /healthz o /health/ready, frontend /, worker con check di processo o probe custom.
  5. Preferire filesystem read-only in compose/deploy e montare volumi solo dove il processo deve scrivere stato.

CI​

  1. Ogni immagine runtime deve passare Trivy image scan con CRITICAL bloccanti.
  2. HIGH resta report-only via SARIF finché il progetto non definisce una finestra di remediation dedicata.
  3. Ogni ignore in .trivyignore deve indicare componente, motivo, mitigazione e data di review.
  4. Eseguire hadolint sui Dockerfile prima di merge.