Docker Health Checks

How to use DISA-required Docker health checks in container images deployed to Game Warden, including Dockerfile and Kubernetes alternatives.

The Defense Information Systems Agency (DISA) requires a Docker health check to verify the health of applications running inside containers. This check validates that services are running and responsive, ensuring continued availability.

Game Warden recommends using a healthcheck command directly in your container image to meet this requirement.

You may use a Kubernetes Liveness Probe instead of a Docker healthcheck. To remain compliant, justify this exception in Findings.

Note

DISA specification — From Container Image Creation and Deployment Guide (Section 2.6):

"Ensuring a container service is still executing and handling workloads is necessary to validate service availability. Adding the health check instruction, HEALTHCHECK, within Docker, to the container image, provides a mechanism for the container platform to periodically check the running container instance against that instruction to ensure the instance is still working. Based on the reported health status, the container platform can then exit a non-working container and instantiate a new one bringing the service back to an available state. Short lived containers that do not require a health check can be submitted for a waiver."

IA Control: SC-5 | CCI: CCI-002385


Docker healthcheck requirements

Embed a Docker healthcheck command in your container image to verify the container's health at configured intervals. If the health check fails, Docker marks the container as unhealthy and may restart it, depending on your configuration.

Important
  • The Department of War (DOW) requires a health check even though newer versions of Docker do not enforce it.
  • In Game Warden, missing health checks may appear as Healthcheck not found in scan results due to compliance scanning.
  • Iron Bank base images do not include a healthcheck by default.

Health check options in Game Warden

You can meet DISA's requirement in two ways:

  1. Docker healthcheck (recommended) — Add the healthcheck instruction directly to your Dockerfile.
  2. Kubernetes liveness probe (acceptable alternative) — If you use a liveness probe instead, document this in Findings:
    • In Vulnerability dropdown, select Policy N/A.
    • In Justification, enter: Using Kubernetes liveness probe.

Common implementation methods

Below is a Dockerfile that includes a healthcheck command using the curl command.

dockerfile
FROM python:3.8-slim
WORKDIR /app
COPY . /app
RUN pip install --no-cache-dir -r requirements.txt

HEALTHCHECK --interval=10s --timeout=5s --start-period=15s \
  CMD curl --fail localhost:8080/health || exit 1

EXPOSE 8080
CMD ["python", "app.py"]

Run this curl command every 10 seconds to verify localhost:8000/health. Mark the container unhealthy if the command fails.

Dockerfile with wget

You can use wget to add the health check to the Dockerfile:

dockerfile
FROM alpine:3.12
RUN apk update && apk add --no-cache wget

HEALTHCHECK --interval=10s --timeout=5s --start-period=15s \
   CMD wget --spider http://localhost || exit 1

This method allows you to check if a URL is accessible without downloading content (--spider).


Docker image best practices

  • Expose a health endpoint that returns 200 only when the app is actually ready (connections open, migrations done, deps reachable). This enables safe autoscaling and zero-downtime deploys.

    Example: App exposes /healthz and returns 200 only when ready:

    dockerfile
    HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
    CMD curl -fsS http://localhost:8080/healthz || exit 1
    
  • Never run processes as root inside containers.

    Example: Create unprivileged user:

    dockerfile
    RUN addgroup -S app && adduser -S app -G app
    USER app
    
  • Each RUN, COPY, ADD makes a layer. Combine related commands and clean caches to shrink images.

  • Exclude anything not needed at runtime/build (node_modules, tests, .git, IDE files, secrets).

  • Use immutable, descriptive tags (for example, 1.4.3, 2025.10.01-sha.abcd123). This makes rollbacks/audits reliable.

  • Never bake API keys, tokens, or certs into layers or files. Inject via env vars/secret stores at deploy. Configure CI scanners (for example, Trivy) to fail the build when they detect secrets.

  • Build artifacts in one stage, then copy only the required artifacts into the final image.

  • Choose distroless, Alpine, or Chainguard images when possible, and avoid large base images unless you need them. If you only need to serve static files or a single binary, use the scratch base image (0-byte base image).

  • Smaller images lead to faster pulls and a smaller attack surface.

October 19, 2026
Was this page helpful?