From 150838069b172d635f26a8d670089a6660421934 Mon Sep 17 00:00:00 2001 From: Wonderfall Date: Thu, 31 Mar 2022 00:37:03 +0200 Subject: [PATCH] typo --- content/posts/docker-hardening.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/posts/docker-hardening.md b/content/posts/docker-hardening.md index f5967d8..e8fc0cc 100644 --- a/content/posts/docker-hardening.md +++ b/content/posts/docker-hardening.md @@ -79,7 +79,7 @@ root can be avoided in different ways in the final container: - Container creation time: via the tools available (`user:` in the Compose file). - Container runtime: degrading privileges with entrypoints scripts (`gosu UID:GID`). -Well-made images with security in mind will have a `USER` instruction. In my experience, most peole will run images blindly, so it's good harm reduction. Setting the user manually works in some images that aren't designed without root in mind, and it's also great to mitigate some *scenarii* where the image is controlled by an attacker. You also won't have surprises when mounting volumes, so I highly recommend setting the user explicitly and make sure volume permissions are correct once. Some images allow users to define their own UID/GID user with environment variables, with an entrypoint script that runs as root and takes care of the volume permissions before dropping privileges. While technically fine, it is still attack surface, and it requires the `SETUID`/`SETGID` capabilities to be available in the container. +Well-made images with security in mind will have a `USER` instruction. In my experience, most people will run images blindly, so it's good harm reduction. Setting the user manually works in some images that aren't designed without root in mind, and it's also great to mitigate some *scenarii* where the image is controlled by an attacker. You also won't have surprises when mounting volumes, so I highly recommend setting the user explicitly and make sure volume permissions are correct once. Some images allow users to define their own UID/GID user with environment variables, with an entrypoint script that runs as root and takes care of the volume permissions before dropping privileges. While technically fine, it is still attack surface, and it requires the `SETUID`/`SETGID` capabilities to be available in the container. As mentioned just above, [user namespaces](https://www.man7.org/linux/man-pages/man7/user_namespaces.7.html) are a solution to ensure root in the container is not root on the host. Docker supports user namespaces, for instance you could set the default mapping in `/etc/docker/daemon.json`: