FrançaisGet started

Advanced Docker: hardening a container and keeping it alive

Removing a container's unneeded privileges, keeping secrets out of the image, capping its resources, monitoring it with a HEALTHCHECK and choosing its restart policy.

  • 26 cards
  • 4 topics
  • Free
Study this deck

The outline, topic by topic

Each topic is weighted the way the exam weighs it.

  1. Concepts
  2. Questions
  3. Sort and link
  4. Scenarios

A few cards from the deck

  • Principle of least privilege: what is it?

    Show the answer

    A security rule that says a process should receive only the rights it needs for its task, and nothing more.

    For a container: unprivileged user, read-only file system, --cap-drop ALL, never --privileged. If the service is compromised, the attacker inherits little.

  • Why should you never mount /var/run/docker.sock in a container?

    • Whoever talks to the daemon can start a privileged container: that is root on the host
    • The socket is too slow and slows down all the other containers running on the host machine
    • Docker forbids mounting any file of the host system inside a container, whatever it is
    • The container could no longer use its own virtual network once the socket is mounted
    Show the answer

    Whoever talks to the daemon can start a privileged container: that is root on the host

    The socket is the API of the daemon, which runs as root. A process that can call it can create a container mounting the host's whole disk: least privilege is bypassed in one stroke.

  • The … option makes the container's file system unmodifiable; a temporary writable folder is added with ….

    Show the answer

    The --read-only option makes the container's file system unmodifiable; a temporary writable folder is added with --tmpfs /tmp.

    Real output of docker run --rm --read-only alpine touch /x: touch: /x: Read-only file system. An intruder can no longer drop a tool or modify the code.

  • Non-root container: what is it?

    Show the answer

    A container whose process runs as an unprivileged user, set in the image by USER or at launch by --user, rather than as user 0.

    Without USER, the service runs as root in the container: a flaw in the service then gives the attacker all of root's rights inside and, without a user namespace, an escape lands them as root on the host.

  • docker ps shows Restarting (1) 5 seconds ago for a container started with --restart always, and it has been going on for an hour. What is the probable cause and the right response?

    • The health check is failing in a loop: remove the image's HEALTHCHECK to settle the problem
    • The process fails and always restarts it: read docker logs, fix, then bound with on-failure:5
    • The container lacks memory: double --memory so that it finally lasts through the end of its start-up
    • It is always' normal behaviour: it is enough to wait for it to stabilise on its own
    Show the answer

    The process fails and always restarts it: read docker logs, fix, then bound with on-failure:5

    (1) is the exit code: the process fails, Docker restarts it endlessly (with a growing delay). The logs say why; on-failure:5 avoids the infinite loop by giving up after five tries.

Study this deck