Stage 9 - Docker Security
Docker security starts with a realistic assumption: containers are isolated, but they are not magic sandboxes. They share the host kernel, so reducing privileges matters.
Security model
Running as root inside a container is common, but risky. If the application is compromised, the attacker receives more power inside the container. A Dockerfile should create or use a non-root user after package installation and file preparation.
trusted base image
minimal packages
non-root user
scan image
inject secrets at runtime
Users, scanners, and secrets
Image scanning checks known vulnerabilities in OS packages and libraries. It is not a proof of safety. It is an early warning system that catches known CVEs before deployment.
Secrets should arrive at runtime, not during image build. If a Dockerfile copies .env or a private key, deleting it later does not necessarily remove it from image history. Environment variables are convenient, but highly sensitive values need a controlled secret mechanism in the target platform.
Least privilege in practice
Least privilege means the process receives only the permissions it needs. In Docker, this starts with not running the application as root unless there is a clear reason. It also includes limiting Linux capabilities, avoiding unnecessary mounts, and not exposing the Docker socket to ordinary application containers.
The Docker socket is especially dangerous. A container with access to it can often control Docker on the host. For a beginner, the rule is simple: do not mount the Docker socket unless you deeply understand the consequence and the container is meant to manage Docker.
File ownership must match the runtime user. Switching to a non-root user without preparing permissions can break application startup. Security and operability have to be designed together.
Scanning is not the whole story
Vulnerability scanning finds known problems in packages and libraries. It does not know whether your application exposes an admin endpoint, logs tokens, or uses secrets incorrectly.
Treat scan results as one input. Fix critical and high issues, understand whether the vulnerable package is actually present in the runtime path, and rebuild images regularly from updated base images.
Security also depends on process: who can push images, who can approve base image updates, and where secrets are stored. Docker gives tools, but the workflow decides whether they are used well.
Where security controls apply
Docker security controls apply on the Docker host that runs the container. A non-root user, read-only filesystem, limited capabilities, and mounted secrets all affect the container process on that host. They do not automatically protect every other machine where the same source code exists.
Image scanning can run locally, in CI, or in a registry. The strongest workflow scans images before they are deployed. Scanning only on a developer laptop is useful for learning, but CI or registry scanning makes the check part of the team process.
Secrets also depend on the environment. Local development may use a .env file with fake values. Production should use the platform secret mechanism, because real secrets should not live in image layers, Git history, or casual local files.
Commands to run and inspect
Run these commands in a terminal on the machine where Docker is installed. For local learning, that is your laptop terminal. For a VPS, first connect to the server with SSH, then run the commands there. Do not paste commands blindly: run one command, inspect what changed, then run the next one.
docker run --user 10001:10001 app:prod
docker history app:prod
docker scout cves app:prod
docker inspect app:prod
Reference table
| Topic | What it means | Practical consequence |
|---|---|---|
| Non-root user | Lower runtime privileges | Reduces damage after compromise |
| Scanner | Known vulnerability check | Finds CVEs, not design flaws |
| Secret injection | Values supplied at runtime | Avoids secrets in image layers |
Risk reduction rule
Do not ask whether a container is “secure” in general. Ask what it can do if compromised. Can it write important files? Does it run as root? Does it contain secrets? Does it include unnecessary tools?
Security improves when every answer becomes smaller: fewer packages, fewer privileges, fewer secrets in the image, and fewer exposed capabilities.
Checkpoint
Continue when you can explain why non-root users, vulnerability scanning, and runtime secret injection solve different parts of the security problem.
Practical security exercise
Inspect an image before trusting it. Check which user the process runs as, whether the history contains suspicious copied files, and whether the base image is larger than necessary. Then run a vulnerability scan. The scan is useful, but it is only one signal; it cannot tell you whether your secrets handling or runtime privileges are designed well.
Short takeaway
Main security orientation: reduce the attack surface before the container starts. Fewer packages, fewer privileges, fewer secrets in image history, and fewer exposed capabilities create a more understandable runtime environment.