Aurora Libros works, it is well organized and it is reproducible. What it is not is hardened. In this lesson you walk through the four attack surfaces of a container platform and apply the defenses one by one: an unprivileged user, a read-only filesystem, trimmed kernel capabilities, seccomp, vulnerability scanning and image signing.

Essential warning. Everything that follows consists of technical best practices, not a security policy. The specific decisions —what gets exposed, which CVE is accepted, which controls are mandatory— must be validated with the security or compliance officer in your organization. No configuration in this course replaces a professional audit or the regulatory compliance that applies to you.

1. Threat model: what a container isolates and what it does not
2. The daemon: the docker group is root
3. Rootless Docker
4. --userns-remap, the middle-ground alternative
5. The image: a minimal base pinned by digest
6. distroless and scratch versus Alpine
7. Secrets in layers: the proof with docker history
8. Runtime: --read-only and --tmpfs
9. Kernel capabilities
10. no-new-privileges, seccomp and AppArmor
11. Resources as a defense, and why --privileged is a mistake
12. Vulnerability scanning: Scout and Trivy
13. Supply chain: SBOM, Cosign and provenance
14. The hardened compose.prod.yaml
15. Security checklist

A container is not a virtual machine. It shares the host's kernel, and that kernel is the only real boundary:

The four surfaces are defended with different tools and none of them covers the others: an image with no CVEs, run as root with --privileged, is still a disaster.

This is the claim that meets the most resistance and the easiest one to demonstrate. Belonging to the docker group is equivalent to having root on the host, without sudo and without a trace in the sudo logs.

You have just read the host's password hashes without being root. And you can go further: by mounting / in write mode, a user in the docker group can add themselves to /etc/sudoers, install an SSH key in /root/.ssh/authorized_keys or modify a systemd unit. The reason is structural: the docker client only sends requests to /var/run/docker.sock, and the daemon runs as root. Whoever can talk to that socket commands the daemon, and the daemon commands the host. Three operational consequences:

• Adding somebody to the docker group is granting them root. Treat it that way in your access management.
• Never mount /var/run/docker.sock inside a container "for convenience". It is the most exploited escape route there is. If a tool needs it (a CI agent, Portainer), use a socket proxy that filters the allowed requests.
• If the team does not need root on the host, the right answer is rootless mode.

In rootless mode the daemon runs as your user, not as root, leaning on user namespaces (lesson 05-07). If somebody escapes the container, they show up as an unprivileged host user.

The mount happens, but the file is unreadable: inside the container you are root, and that root is remapped to your real host UID, which cannot read /etc/shadow. The escalation ceases to exist.

For Aurora Libros on a shared server, rootless is the default choice. For a dedicated server with restricted access, hardened classic mode is defensible; make that call with your security officer.

If you cannot migrate to rootless, --userns-remap keeps the daemon running as root but remaps container users to an unprivileged range on the host. You enable it with {"userns-remap": "default"} in /etc/docker/daemon.json:

Inside, the process is root (uid 0); on the host it runs as UID 165536, which has no privileges at all. The cost: existing volumes change effective owner, and it is incompatible with --network host and with containers that share user namespaces. It is a reasonable intermediate step, not a substitute for rootless.

Every package in the image is a potential CVE. The rules, in order of impact: an official, minimal base (node:22-alpine instead of node:22 goes from ~1.1 GB to ~142 MB, and with it hundreds of packages); pin by digest, because a tag is mutable and a digest is not; do not install what you do not need (no curl, vim, git or build-essential in the final image); an unprivileged USER (lesson 02-04); and update the base regularly, because pinning by digest without ever refreshing it is freezing vulnerabilities in place.

You get the digest with docker image inspect node:22-alpine --format '{{index .RepoDigests 0}}', and it is the only reference that guarantees today's image is exactly the one you audited. In development you can use tags; in compose.prod.yaml, digests.

distroless contains the interpreter and its libraries, and nothing else: no sh, no apk, no wget. An attacker who achieves command execution finds no tools to work with. The price is real: you cannot run docker exec ... sh, and aurora-api's HEALTHCHECK based on wget stops working (you would have to probe from outside or include a small health binary). scratch only works for static binaries —Go, Rust—, not for Node.js. For aurora-api, Alpine is the right balance between surface and operability; distroless is the next step up if your organization requires it.

A secret that passes through a layer stays in the image forever, even if you delete it afterwards.

The three failures: the ARG stays in the build metadata, the ENV in the image configuration, and the deleted file is still in the layer where it was created, under a whiteout (lesson 05-02). Anybody who pulls the image gets them back.

The fixes, depending on the moment: during the build, BuildKit's RUN --mount=type=secret (lesson 05-05); at runtime, files mounted in /run/secrets/ with the _FILE pattern (lesson 04-05); inside the image, never.

Remember the pattern Aurora Libros already uses: DB_PASSWORD_FILE=/run/secrets/db_password, and the application reads the file at startup. The secret lives on the host, not in the image and not in the environment.

If the container's filesystem is read-only, an attacker cannot drop a binary or modify the code.

Almost no application works without writing somewhere: you have to grant tmpfs for those specific paths.

Note noexec and nosuid: even if the attacker manages to write a binary into /tmp, they will not be able to run it. To find out which paths an application needs to write to, start it read-only and read the errors; /tmp plus some cache directory is usually enough.

Being root inside a container is not being root on the host: Linux splits privileges into capabilities, and Docker grants a subset of about fourteen by default. The good practice is to drop them all and give back only the ones you need.

For aurora-api, which listens on 3000 and runs as the node user, the answer is clean: no capabilities at all, that is, cap_drop: [ALL] with no cap_add whatsoever.

no-new-privileges:true in security_opt prevents a process from gaining privileges through setuid binaries, and cuts off an entire family of local escalations at the root.

seccomp filters system calls. Docker's default profile blocks around 40 of the 300-plus available, including the most dangerous ones: mount, reboot, kexec_load, init_module, ptrace (on older kernels), clone with new namespace flags, and bpf.

A custom profile is a JSON file with a default action and a list of allowed calls:

You apply it with security_opt: [seccomp:./security/aurora-api-seccomp.json]. Building a custom profile is delicate work: you have to trace the application (with strace or auditd) to discover which calls it really uses, and one forgotten call produces intermittent failures that are hard to diagnose. Start with the default profile —which is already a solid defense— and take on a custom one only if your context demands it.

AppArmor (Debian/Ubuntu) and SELinux (RHEL/Fedora) operate at a different level: they control which files and operations a process may touch. Docker applies the docker-default profile if AppArmor is active. On SELinux, the :z / :Z option on mounts relabels the content so the container can access it (-v data:/data:Z), and leaving it out is the cause of the classic Permission denied on Fedora with apparently correct permissions. What you must never do: seccomp=unconfined or apparmor=unconfined to "fix" an error.

The limits from lesson 03-07 are not only about capacity: they are a defense against denial of service. A compromised container that mines cryptocurrency, exhausts memory or launches a fork bomb is contained by its pids_limit: 200 and its deploy.resources.limits.

And --privileged, in one line: it disables almost every protection at once. It grants all capabilities, disables seccomp and AppArmor, and gives access to every device on the host.

If something needs a specific device, grant it with --device=/dev/xxx; if it needs a specific capability, with --cap-add. --privileged is the equivalent of removing the door because the key was hard to find.

How to read a report, in decision order:

Trivy gives you the same thing from the command line and lends itself to automation:

--exit-code 1 is the key to integration: it makes the command fail and, with it, the pipeline (lesson 06-02). The sensible workflow has three checkpoints: when building locally, on every pull request, and periodically against the images already deployed. And a note about the socket: mounting docker.sock into the scanner is exactly what section 2 advises against; it is acceptable on your own machine, but in CI you should scan the image tarball or use a scanner without access to the daemon.

An SBOM (Software Bill of Materials) is the inventory of everything inside an image. Without one, when a new CVE appears you cannot answer the most basic question: does it affect me?

Cosign signs images cryptographically and verifies their origin:

The signature is stored as an additional artifact in the registry itself. With keyless signing you can sign using the pipeline's OIDC identity, without managing private keys —which, in practice, is the biggest advantage: the key nobody has to guard is the key nobody leaks.

Provenance attestations answer "who built this, from which commit and with which Dockerfile", and are generated during the build: docker buildx build --provenance=mode=max --sbom=true -t auroralibros/aurora-api:1.2.0 --push ./api, and can be queried with docker buildx imagetools inspect.

About the old mechanism: Docker Content Trust (DOCKER_CONTENT_TRUST=1) and Notary v1 were the first attempt at signing on Docker Hub. They still work, but they are on the way out: the industry has moved to Cosign and the Sigstore ecosystem. If you are starting today, start with Cosign.

Always verify the merge before deploying: docker compose -f compose.yaml -f compose.prod.yaml config | grep -E 'read_only|cap_drop|no-new'.

Go through this list before every deployment and review it with your security officer: it is a technical starting point, not a certificate of compliance.

Believing a container isolates like a VM. It shares the kernel: a kernel flaw affects everybody.

Adding people to the docker group as if it were a minor permission, or mounting /var/run/docker.sock into a container. The first is granting root with no trace in sudo; the second is the most exploited escape route there is.

Passing secrets with ARG or ENV in the Dockerfile. They stay in the layers and in the metadata. docker history reveals them.

Using --privileged to work around a permissions error, or disabling seccomp/AppArmor to make something work. Grant the specific thing that is missing (--cap-add, --device); the other approach is switching off the alarm instead of dealing with the fire.

Scanning once and forgetting about it, or pinning by digest and never refreshing it. CVEs appear after publication; an image that was clean in March can be vulnerable in June without anybody touching it.

Tip: apply hardening service by service and by measuring. Add read_only, start it, read the error, add exactly the tmpfs you need; then cap_drop: [ALL], start it, read the error, add exactly the capability you need. It is slower than copying a template, and it is the only way to know why each line is there.

Exercise 1. Demonstrate privilege escalation from the docker group: read a host file your user cannot read and explain exactly why it works. Then reason out which two configurations would prevent it.

Exercise 2. Harden aurora-api incrementally: user, read_only, cap_drop: [ALL] and no-new-privileges. Document what breaks at each step, which tmpfs is needed, and verify at the end that /health and /books still respond.

Exercise 3. Prove that a secret passed with ARG stays in the image: build it, retrieve the secret with docker history even though the file has been deleted, and explain why Aurora Libros' _FILE pattern does not have that problem.

Solution 1.

The same file, the same user, two opposite outcomes. The reason lies in who performs the operation: the docker command reads nothing, it only sends a request to the daemon's socket; the daemon runs as root and mounts / inside the container with its own privileges. Inside, the process is also root, so it reads whatever it likes. Your user never needed permission because your user was never the one reading the file.

The two configurations that prevent this are rootless mode (the daemon runs as your user and the root inside is remapped to your real UID, which cannot read /etc/shadow) and --userns-remap (the container's root is remapped to an unprivileged UID, with the same effect on the mount).

The management conclusion is the one that matters: usermod -aG docker somebody is a grant of root and must go through the same approval process as granting passwordless sudo.

Solution 2.

The only step that failed was the second, for a specific reason: the application writes its PID file to /tmp. A 64 MB tmpfs with noexec,nosuid solves it without handing write access back to the rest of the filesystem. cap_drop: [ALL] broke nothing because aurora-api listens on 3000 (unprivileged) and was already running as the node user: this is where the decision you made back in lesson 02-04 pays off.

The result is a container in which an attacker with code execution cannot write a binary, cannot run it if they do write it to /tmp, has no kernel capabilities, cannot escalate through setuid and cannot spawn more than 200 processes. The application, meanwhile, responds exactly as before.

Solution 3.

Three linked facts: the file does not exist in the final filesystem, the token shows up in the build history, and it shows up as well inside the exported layer's data. The first explains why so many people believe deleting the file is enough; the second and third explain why it is not: the ARG stays in the metadata and the deleted content is still in its layer, hidden only by a whiteout (lesson 05-02).

Aurora Libros' _FILE pattern does not have that problem because the secret never enters the image. The image contains only DB_PASSWORD_FILE=/run/secrets/db_password, which is a path, not a value:

The metadata holds nothing but a path; the value arrives through a read-only mount that exists only while the container lives. If you publish that image on Docker Hub tomorrow, no secret travels inside it. For secrets needed during the build —a private npm token— the equivalent solution is BuildKit's RUN --mount=type=secret, and that is exactly what you will see in lesson 05-05.

Aurora Libros is hardened and, more importantly, you know why every line of that hardening is there. You started from the threat model: a container isolates processes, files and networking, but it shares the kernel, and the four surfaces —image, runtime, daemon and registry— demand different defenses that do not substitute for one another. You have demonstrated, by reading /etc/shadow without being root, that belonging to the docker group means having root on the host, and you know the two answers: rootless mode with its real limitations (low ports, slightly slower networking, no --network host) and --userns-remap as an intermediate step.

On the image you apply a minimal base pinned by digest, the comparison between Alpine, distroless and scratch with its cost in operability, and the irrefutable proof that a secret passed through ARG or ENV stays in the layers forever. At runtime, --read-only with noexec,nosuid tmpfs for just what is needed, cap_drop: [ALL] with the table of capabilities that really matter —and aurora-api with none at all—, no-new-privileges, the default seccomp profile and when to write your own, AppArmor and SELinux with its :Z, resource limits as denial-of-service containment, and why --privileged is almost always a mistake. You scan with Docker Scout and Trivy knowing how to read a report —the fixed version is the decisive piece of data— and how to integrate it with --exit-code 1; and you secure the supply chain with SBOMs, Cosign signing and provenance attestations, leaving Content Trust as the legacy mechanism it is. All of it condensed into a compose.prod.yaml commented line by line and a checklist of seventeen verifiable controls. And the opening warning still stands: this is a solid technical floor, not a policy, so validate every decision with the security or compliance officer in your organization.

In lesson 05-04 we change targets and go back to the image, this time with the scales in front of us: why size matters (download time, cost, attack surface, scaling speed), how to measure with history and dive to find the fat layer, which base to choose with real numbers, and above all multi-stage builds, with which those 142 MB of aurora-api will come down to a specific figure without losing any of what you have just hardened.