Docker Security Best Practices: 8 Checks Before Deployment

Docker security best practices work best as repeatable deployment checks. Packaging an application in a container makes delivery more predictable, but the application, container runtime, host and deployment credentials still need protection. Start by asking what an attacker could control if one container were compromised.

This guide covers a Linux Docker Engine deployment. Adapt each control to your application and test it outside production first. A useful security review records both the intended configuration and evidence that it behaves as expected.

1. Protect the Docker daemon and its socket

Access to a rootful Docker daemon is highly privileged. Restrict who can use its Unix socket and review membership of the host’s docker group. Giving an account Docker access is not the same as giving it a limited ability to restart one service.

Do not expose an unauthenticated Docker API over TCP. If remote administration is required, use a supported authenticated connection, such as Docker over SSH or mutual TLS, and restrict network access. Avoid mounting the Docker socket inside an application container: marking that socket mount read-only does not make API requests read-only.

2. Run application processes with appropriate privileges

Set a non-root application user in the image where the workload permits it. Check that this user can read its configuration and write only to the directories it needs. Do not solve a permission error by granting broad access to the whole filesystem.

Rootless Docker is a separate control that runs the daemon and containers without a root host account. Docker documents prerequisites and limitations, including resource and networking considerations. Evaluate it for your environment rather than assuming that a non-root process inside a container provides the same protection.

3. Use identifiable, maintained container images

Choose an image from a source you can evaluate and record the exact version and digest deployed. A floating tag can point to different content later. Digest pinning improves reproducibility, but it also creates a responsibility to review and adopt newer builds.

Scan application dependencies and image layers in your build pipeline. For significant findings, record the affected component, available fix, application impact and owner. Rebuild after updating the base image, then run application tests. A clean scan cannot prove that software has no vulnerabilities.

4. Reduce container capabilities and filesystem access

Review privileged mode, added Linux capabilities, host namespaces and device access. Keep the runtime’s isolation controls unless a documented requirement justifies an exception. Test capability reduction against real application behaviour.

A read-only root filesystem can limit unexpected writes, but applications may still need specific writable paths for temporary files or data. Provide those paths deliberately. Mount only the host directories the workload needs and use read-only mounts for inputs where appropriate.

5. Review published ports and service boundaries

Publish only the application ports that consumers need. A database used by another container often does not need a publicly published host port. Keep administrative endpoints on an approved private access path.

Binding a published port to localhost can be appropriate for a local reverse proxy, but it is not a substitute for reviewing the complete network path and Docker version. Test access from the intended client and from a location that should be denied. Include IPv6, cloud security rules and host firewall behaviour in that review.

6. Deliver secrets without baking them into images

Keep credentials out of Dockerfiles, source control and image build arguments. Use a secret-delivery mechanism suited to the platform and restrict access to the files or services that provide it. Rotate credentials when exposure is suspected.

Compose secrets, Swarm secrets and Kubernetes Secrets have different storage and delivery behaviour. Check the actual mechanism rather than assuming a shared name means identical protection. Avoid printing secret values in application logs or build output.

7. Set resource limits and useful operational checks

Choose memory, CPU and process limits using observed workload behaviour. An unrealistically low limit can cause repeated failures; an unlimited noisy workload can affect neighbours. Monitor resource use after deployment and adjust through a reviewed change.

A container being marked running is not proof that its application is ready. Add a health check appropriate to the service, monitor error rates and make sure someone owns alerts. Retain enough logs to investigate failures without storing unnecessary sensitive information.

8. Verify the effective runtime configuration

These read-only commands help review a running container. Replace app with its actual name. Run them only with authorised daemon access.

docker inspect --format '{{.Config.User}}' app
docker inspect --format '{{.HostConfig.Privileged}}' app
docker inspect --format '{{.HostConfig.ReadonlyRootfs}}' app
docker port app

A blank user field means the container uses the image’s default user, commonly root when no user is configured; inspect the image and running process before concluding. Review mounts, capability settings and security options as well. Avoid sharing full inspection output publicly because it can contain configuration values.

A Docker security checklist for your release review

• Confirm who can administer the daemon and why.
• Record the image digest, scan findings and update owner.
• Check process identity, mounts, privileges and published ports.
• Verify secret delivery, resource limits and application health.
• Test rollback and recovery using the previous approved configuration.

For related delivery-pipeline controls, read the Jenkins security and incident-response guide. Docker security best practices become more useful when these checks are part of each release rather than a one-time hardening exercise.

Official references

• Docker Engine security
• Rootless Docker prerequisites and limitations
• Docker group privileges
• Docker container run reference