How to Run Kali Linux in Docker

You do not always need a full Kali virtual machine. When you want a couple of tools for a quick check — resolve some DNS, curl an internal endpoint, run nmap against a lab host — spinning up a whole VM is heavy and slow. Docker lets you run Kali as a lightweight, disposable container that starts in seconds, leaves no mess on your host, and can be thrown away the moment you are done. This lesson shows you how to pull the official image, work inside it, install the tools you need, persist your output, attach it to a lab network, clean up afterward, and finally bake a custom toolbox image with a Dockerfile.

Why Kali works well as a disposable container

A container is a lightweight, isolated process wrapped around its own filesystem — not a full machine with its own kernel. That difference is exactly why Kali-in-Docker is so useful for a DevOps engineer:

• It starts in seconds. No boot, no GUI, no waiting. You get a shell almost instantly.
• It is disposable. Install ten tools, make a mess, then delete the container and your host is untouched. The next container starts clean.
• It is portable. The same image runs on your laptop, a build agent, or any server with Docker. Your toolbox travels with you.
• It is scriptable. A container is easy to launch from a CI pipeline or a one-line command, which makes Kali tools available inside automation.

The trade-off is that a container is not a general-purpose desktop. There is no GUI by default, it shares your host’s kernel, and some low-level network tools need extra permissions (covered near the end). For command-line tools — which is most of what a DevOps engineer reaches for — none of that matters.

🛠️ DevOps Perspective — Think of the Kali image as an ephemeral toolbox you can drop onto any Docker host. Need to run a scripted TLS check or a port scan from inside a CI job? Pull the image, run one command against a target you control, capture the output, and the container disappears when the job ends. Nothing is installed permanently on the build agent, and every run starts from the same known-good image — reproducible, and clean.

Pulling the official Kali image

Kali publishes an official image on Docker Hub. Pull the rolling release:

docker pull kalilinux/kali-rolling

This downloads the base image — a minimal Kali system that is deliberately small. It does not include the hundreds of tools a full Kali install ships with; you add only the ones you need (more on that below). Keeping the base lean is what makes it fast to pull and quick to start.

To confirm it is on your machine:

docker images kalilinux/kali-rolling

💡 Note — kali-rolling tracks Kali’s rolling release, so re-pulling later gives you a newer snapshot. For repeatable results in automation, pin to a dated tag when one is available, or build your own image (shown at the end) and tag it yourself.

Running a Kali container

The most useful way to start is an interactive container with a shell:

docker run -it kalilinux/kali-rolling

Two flags do the work here:

• -i (interactive) keeps STDIN open so you can type into the container.
• -t (tty) allocates a terminal so the shell behaves like a normal prompt.

Together, -it drops you into a root shell inside the container:

┌──(root㉿a1b2c3d4e5f6)-[/]
└─#

You are now inside Kali. Commands you run here execute in the container, isolated from your host. When you type exit, the shell ends and the container stops.

To run a single command and return immediately — handy for scripts — skip the interactive shell and pass the command directly:

docker run kalilinux/kali-rolling cat /etc/os-release

That starts a container, runs one command, prints the result, and stops. It is the container equivalent of a one-liner.

🧪 Try It — Run docker run -it kalilinux/kali-rolling, then inside the container run uname -a and cat /etc/os-release. Notice the kernel version matches your host (containers share the host kernel) while the OS release reports Kali. Type exit to leave. Run it again and confirm the second container knows nothing about the first — it starts fresh every time.

Working in the interactive shell

Inside the container you have a normal Debian-based shell as root, but the base image is minimal — some commands you expect may be missing until you install them. Start by refreshing the package index, exactly as you would on any Kali or Debian system:

apt update

(There is no sudo prompt here because the container’s default user is already root.) From this shell you can install tools, run them, edit files, and inspect the environment. Because the whole container is disposable, this is a safe place to experiment — break it, delete it, start again.

Installing selected tools inside the container

The base image is intentionally bare. You install what you need with apt, drawing from Kali’s normal repositories:

apt update && apt install -y nmap curl dnsutils

That gives you a port scanner, an HTTP client, and DNS lookup tools (dig, nslookup) — a solid starting kit for infrastructure work. Install only what the task needs; every package adds size and start-up weight.

When you want a themed bundle rather than individual packages, use Kali’s metapackages — curated groups of related tools. For example:

apt install -y kali-tools-information-gathering

Metapackages are large, so pull them deliberately. For a container you will throw away in five minutes, a couple of targeted packages usually beat a giant metapackage. If you find yourself installing the same set every time, that is a strong signal to bake them into a custom image (final section) instead of reinstalling on every run.

🔎 Troubleshooting Tip — If apt install fails with “Unable to locate package,” you almost always forgot apt update first — the fresh container ships with an empty package index. Run apt update, then retry the install.

Persisting output with volumes

Anything you write inside a container vanishes when the container is removed. That is the point of a disposable toolbox — but it means scan results, capture files, and reports vanish too. To keep output, mount a volume: a directory on your host that appears inside the container.

docker run -it -v "$(pwd)/kali-output:/output" kalilinux/kali-rolling

The -v <host-path>:<container-path> flag maps a folder. Here your host’s ./kali-output directory shows up as /output inside the container. Write your results there:

nmap -oN /output/scan.txt 192.168.56.0/24

When the container is gone, scan.txt is still sitting in ./kali-output on your host. The volume is the bridge between an ephemeral container and durable results.

⛔ Production Warning — Only scan hosts you own or are explicitly authorized to test. The 192.168.56.0/24 example above is a private lab range (the kind used by local VMs). Never point a scan at production systems, third-party infrastructure, or networks you do not control.

Docker networking: attaching to a lab network

By default a container joins Docker’s bridge network and can reach the internet, but it is isolated from your other containers. When you are building a security lab — a Kali container alongside a target container — put them on a shared user-defined network so they can see each other by name.

docker network create lab-net
docker run -d --name target --network lab-net vulnerables/web-dvwa
docker run -it --network lab-net kalilinux/kali-rolling

Now, from inside the Kali container, the target is reachable simply as target:

ping target
nmap target

Docker’s built-in DNS resolves the container name to its address on lab-net. This gives you a completely self-contained practice range — attacker and target, both containers, both disposable, isolated from the rest of your machine and from any real network. The companion lesson Your First DevOps Security Lab builds this idea out into a full hands-on exercise.

🔐 Security Note — Some network tools need capabilities a container does not get by default. Anything that crafts raw packets — nmap’s SYN scan (-sS), OS detection, arp-scan, custom hping3 probes — needs --cap-add=NET_RAW, and some manipulation needs --cap-add=NET_ADMIN. Add only the specific capability required, and only on hosts and networks you control:

docker run -it --cap-add=NET_RAW --cap-add=NET_ADMIN kalilinux/kali-rolling

Avoid --privileged; it hands the container broad access to the host and is rarely what you actually need. Prefer named capabilities over blanket privilege.

Cleaning up: rm, —rm, and prune

Disposable only helps if you actually dispose. Stopped containers pile up quietly and keep their filesystems around. A few habits keep things tidy.

See what exists, including stopped containers:

docker ps -a

Remove a specific stopped container by name or ID:

docker rm target

Better, make the container clean up after itself. Add --rm and Docker deletes it automatically the moment it stops:

docker run -it --rm kalilinux/kali-rolling

For a throwaway toolbox, --rm should be your default — you almost never want the shell you just exited to linger. When cruft does accumulate, sweep it in bulk:

docker container prune

That removes all stopped containers after a confirmation prompt. To reclaim more space, docker image prune clears unused images. Treat prune as a broom, not a scalpel — read the prompt before you confirm.

Building a customized Kali toolbox with a Dockerfile

Reinstalling the same tools on every run gets old fast. Bake them into an image once with a Dockerfile — a plain-text recipe Docker follows to build a reusable image.

# Dockerfile
FROM kalilinux/kali-rolling

# Refresh the index and install a fixed toolset in one layer
RUN apt update && apt install -y \
      nmap \
      curl \
      dnsutils \
      openssl \
    && rm -rf /var/lib/apt/lists/*

# Where you will drop scan output (pair with -v at run time)
WORKDIR /output

CMD ["/bin/bash"]

A few things worth noting:

• FROM kalilinux/kali-rolling starts from the official base you already know.
• The single RUN installs everything in one layer; rm -rf /var/lib/apt/lists/* drops the package index afterward to keep the image small.
• CMD ["/bin/bash"] means running the image drops you into a shell, just like the base — but now your tools are already there.

Build it and give it a name:

docker build -t my-kali-toolbox .

From now on, your whole toolbox is one command — no apt install step, identical every time:

docker run -it --rm -v "$(pwd)/kali-output:/output" my-kali-toolbox

This is the ephemeral-toolbox idea in its finished form: a versioned, reproducible Kali image you can commit to a repo, share with your team, or pull into a CI pipeline. If you want to go deeper on writing solid Dockerfiles and composing multi-container setups, the Docker Academy walks through it, the Docker Compose Generator helps you wire a lab of several containers together visually, and the Docker Production Readiness Auditor checks an image or Compose file for the security and reliability issues that matter once something leaves your laptop.

Kali VM vs Kali Container

Both have a place. Use this table to pick the right one for the job.

Aspect	Kali VM	Kali Container
Startup	Minutes (full boot)	Seconds (process start)
Isolation	Strong — own kernel, fully separated from host	Shares the host kernel; process-level isolation
Persistence	Persistent by default; state survives reboots	Ephemeral by default; use volumes to keep output
GUI tools	Full desktop and GUI apps work out of the box	CLI-focused; GUI needs extra setup and is awkward
Resource use	Heavy — dedicated RAM, CPU, and disk	Light — shares host resources, minimal overhead
Disposability	Slower to rebuild; snapshots help	Delete and recreate in seconds
When to use	Long-running work, GUI tools, maximum isolation, a persistent lab	Quick CLI tasks, CI/automation, throwaway toolboxes, container-network labs

In short: reach for a VM when you want a durable, isolated desktop environment (see Installing Kali in a VM), and reach for a container when you want a fast, disposable, scriptable command-line toolbox.

🧪 Try It — Build the my-kali-toolbox image above, then run it with --rm and a mounted -v volume. From inside, resolve a public name with dig example.com and save it with dig example.com > /output/dns.txt. Exit, and confirm dns.txt is on your host while the container is already gone. You have just used Kali as a truly disposable toolbox — tools baked in, output kept, container vanished.

Where this fits

Now that you can run Kali as a container, the tools themselves matter more than the packaging. The lesson Kali Tools for DevOps Engineers covers which tools earn a place in your toolbox and why, and Your First DevOps Security Lab puts the container-network approach from this lesson to work in a complete, safe, hands-on exercise.

What You Learned

• Kali runs beautifully as a disposable container — it starts in seconds, leaves your host clean, and is easy to script into automation, at the cost of no GUI and a shared host kernel.
• The workflow is pull → run → install → use → dispose: docker pull kalilinux/kali-rolling, docker run -it for an interactive shell, apt install (or a metapackage) for tools, and --rm or docker rm/prune to clean up.
• Volumes make output durable — mount a host directory with -v host:/output so scan results survive after the container is deleted.
• User-defined networks build self-contained labs — put a Kali container and a target container on a shared docker network so they reach each other by name, isolated from everything else.
• Raw-packet tools need explicit capabilities — add --cap-add=NET_RAW/NET_ADMIN (never blanket --privileged), and only on hosts and networks you own or are authorized to test.
• A Dockerfile turns your toolbox into a reusable, versioned image — bake in a fixed toolset once, then launch an identical, reproducible Kali environment with a single command.