Hardening Docker Containers Basics: A KaliLinux.net Lab Guide

There is no single switch for hardening Docker containers basics. It is mostly deleting defaults you never needed. On KaliLinux.net we treat container labs like any other target: understand the basline, reduce exposure, then verify. This guide stays in an isolated lab you own, using Kali Linux 2024.1 as the workstation. The goal is a smaller attack surface, not a claim of perfect security.

Each change should be small enough to test, revert, and measure.

Build from a minimal image and a non-root user

Start with a small base image, then add only required packages. Run the process as a non-root user inside the contaner, because root in a contaner can still map to dangerous host capabilities. Set a read-only root filesystem when the app allows it, and mount only the paths it needs. Keep build secrets out of final layers by using multi-stage builds and clearing caches.

• Use a minimal base image and pin the tag.
• Create a dedicated user and group in the Dockerfile.
• Drop write access with --read-only unless the app needs it.
• Mount state directories as volumes instead of writing to the image.
• Remove package caches and temporary files in the same build layer.

Restrict capabilities, networks, and secrets

Docker’s default bridge network uses 172.17.0.0/16, so contaner traffic can reach neighbors unless you segment it. Publish only required ports, avoid --privileged, and drop Linux capabilities with --cap-drop=ALL, then add back only what the service needs. Keep secrets out of image layers and environment dumps; use a secret manager or mounted files with tight permissions. The Docker Engine security documentation gives the current defaults and options. Network policies and host firewall rules should match the same intent, especially when multiple contaners share one host.

Verify the result from Kali

Use Kali tools only against your own contaner or lab network. Check listening ports with nmap, inspect running processes, and review image history for leaked secerts. Compare before and after hardening so the change is measurable. If a service still needs root, document why and revisit it later. Save the