CIS Docker Benchmark

The CIS Docker Benchmark v1.6.0 is the de-facto compliance baseline for Docker deployments. It catalogues 117 controls across the host, the daemon, images, runtime, operations, and Swarm. Sockguard sits at the API boundary, so the controls it can enforce are the runtime ones in Section 5: when a docker run would violate them, sockguard rejects the request with 403 before dockerd executes it. The CIS posture becomes an admission gate, not just an audit finding.

This page maps each inspectable Section 5 control to the sockguard knob that enforces it. The ready-made cis-docker-benchmark.yaml preset turns every one of them on at once.

Quick start

docker run -d \
  --name sockguard \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /etc/sockguard/cis-docker-benchmark.yaml:/etc/sockguard/config.yaml:ro \
  -v sockguard-sock:/run/sockguard \
  ghcr.io/codeswhat/sockguard:latest

The preset is bundled in the container image at /etc/sockguard/cis-docker-benchmark.yaml. Mount it as config.yaml to activate.

A workload that violates any of the mapped controls gets a 403 with the deny reason naming the specific knob:

{
  "message": "request denied by sockguard policy"
}

(The preset uses deny_verbosity: minimal so the response never echoes the violating field; the structured access log in Observability records the full deny reason.)

What sockguard enforces

The preset wires every row above to its CIS-compliant default. Edit the preset to widen a knob only when a workload genuinely requires it; that edit is itself the auditable record of why your CIS posture diverges from the benchmark.

Beyond Section 5 — controls sockguard influences

What sockguard cannot enforce

These controls live above or below the Docker Engine API. Sockguard does not see them, so the preset cannot help. Track them with the recommended companion tool.

For a complete CIS posture, run the preset above plus docker-bench-security periodically against the host. The two are complementary: sockguard catches runtime violations as they happen, docker-bench-security catches configuration drift on the host and daemon.

Verifying the posture

A two-step verification per workload:

1. Negative test. Try to run a non-compliant container through sockguard. It must come back 403:

   curl -X POST --unix-socket /run/sockguard/sockguard.sock \
     -H 'Content-Type: application/json' \
     -d '{"Image":"alpine","HostConfig":{"Privileged":true}}' \
     http://localhost/containers/create
   # → HTTP/1.1 403 Forbidden

2. Positive test. Run a compliant container. It must succeed with the usual 201:

   curl -X POST --unix-socket /run/sockguard/sockguard.sock \
     -H 'Content-Type: application/json' \
     -d '{
           "Image":"alpine",
           "HostConfig":{
             "ReadonlyRootfs":true,
             "Memory":67108864,
             "PidsLimit":50,
             "CpuShares":256,
             "CapDrop":["ALL"],
             "SecurityOpt":["no-new-privileges:true"]
           }
         }' \
     http://localhost/containers/create
   # → HTTP/1.1 201 Created

The structured access log records both with the matching rule and (on deny) the violated knob; pipe it into your SIEM as the auditable evidence that the CIS posture is live, not just documented.

Customizing the preset

The preset's body-inspection block is intentionally verbose — every CIS- mapped knob is set explicitly even when the value equals the secure default. Editing the file is therefore the canonical place to record why your deployment diverges from CIS:

request_body:
  container_create:
    # CIS 5.5: production workload needs /srv/data mounted. Diverges
    # from the benchmark intentionally — approved 2026-05-20 by
    # security.
    allowed_bind_mounts:
      - "/srv/data:/data"

A git diff of the preset is the audit trail. If the file matches the shipped baseline, the deployment is CIS-aligned by inspection.