Docker Best Practices Validation Report

Audience: DevOps engineers, contributors

WHAT

Validation report analysing DCK Dockerfiles against industry best practices with findings and recommendations.

WHY

Continuous validation against best practices catches regressions early and documents the rationale behind each Docker configuration choice.

HOW

The DCK Dockerfiles were analysed against industry best practices. Below are the findings and recommendations.

Current Good Practices

  1. Non-root User: ✅ All Dockerfiles use a non-root user (dck)
  2. Specific Base Image: ✅ Using Alpine Linux for minimal size
  3. Layer Optimization: ✅ Combining RUN commands where appropriate
  4. WORKDIR Usage: ✅ Properly setting working directory
  5. Health Checks: ✅ Implemented in some Dockerfiles
  6. BuildKit Support: ✅ Using BuildKit syntax for better caching

Improvements Needed

1. Pin Package Versions

Issue: Not pinning specific package versions can lead to non-reproducible builds

# Current
RUN apk add --no-cache bash curl jq

# Better
RUN apk add --no-cache \
    bash=5.2.21-r0 \
    curl=8.5.0-r0 \
    jq=1.7.1-r0

2. Pin Base Image Version

Issue: Using floating tags can cause unexpected changes

# Current
FROM alpine:3.19

# Better
FROM alpine:3.19.1

3. Add Metadata Labels

Issue: Missing OCI standard labels for better image documentation

LABEL maintainer="DCK Team" \
      version="1.0.0" \
      description="DCK - Docker Management Toolkit" \
      org.opencontainers.image.source="https://github.com/phdsystems/dck"

4. Optimize Layer Caching

Issue: COPY order could be optimized

# Better order (least to most frequently changed)
COPY ./docs/ /opt/dck/docs/     # Rarely changes
COPY ./lib/ /opt/dck/lib/       # Sometimes changes
COPY ./src/ /opt/dck/src/       # Often changes
COPY ./dck /opt/dck/            # Most frequently changes

5. Security Hardening

  • Remove sudo in production (use Docker groups instead)
  • Add security scanning with Docker Scout
  • Use –security-opt for runtime restrictions
  • Consider read-only root filesystem where possible

6. Multi-Stage Build Optimization

Current Dockerfiles could benefit from multi-stage builds to:

  • Separate build dependencies from runtime
  • Reduce final image size
  • Improve security by excluding build tools

Image Size Analysis

Dockerfile Current Approach Potential Size
Main Dockerfile Single stage Alpine ~50MB
Dockerfile.dockerkit Multi-stage (good!) ~45MB
Dockerfile.dockerkit-simple Single stage ~48MB

Security Recommendations

  1. Scan with Trivy/Snyk: 
    docker scan dck:latest
trivy image dck:latest
  2. Use Docker Scout: 
    docker scout cves dck:latest
docker scout recommendations dck:latest
  3. Runtime Security: 
    docker run --security-opt=no-new-privileges:true \
           --cap-drop=ALL \
           --cap-add=DAC_OVERRIDE \
           dck:latest

Quick Wins

  1. Update .dockerignore: Ensure build context is minimal
  2. Add HEALTHCHECK: To all production images
  3. Use BuildKit: DOCKER_BUILDKIT=1 for all builds
  4. Cache mount: Use BuildKit cache mounts for package managers

Validation Tools Used

  • Hadolint: Dockerfile linting
  • Docker Scout: Security scanning
  • dive: Image layer analysis
  • docker scan: Vulnerability detection

Next Steps

  1. Apply the improved Dockerfile.best-practices
  2. Update .dockerignore with comprehensive exclusions
  3. Run security scans on built images
  4. Set up CI/CD with automated Docker best practices checks
  5. Consider using distroless or scratch base images for even smaller size

References