Reducing what a compromise can do.
WHY IT MATTERS
Root inside a container is closer to root on the host than people assume.
WHAT THE DEFAULT IS
Root, in most images.
WHAT TO DO
Create a user in the image, and switch to it.
WHAT TO BE CAREFUL WITH
File ownership, since the application must read what it needs Ports below the privileged threshold Writing to locations owned by root
WHAT TO DO ABOUT PORTS
Listen on a high port, and map it.
WHY THAT IS FINE
The published port on the host is what users see.
WHAT TO DO ABOUT WRITABLE DIRECTORIES
Create them in the image, owned by the application user.
WHAT TO SET AT RUN TIME
A user identifier, where the image did not set one.
WHAT ORCHESTRATORS PROVIDE
A security context specifying the user and group.
WHAT TO ADD THERE
Running as a non-root user Preventing privilege escalation Dropping all capabilities, adding back only what is needed
WHAT CAPABILITIES ARE
Fine-grained privileges, rather than all-or-nothing root.
WHAT MOST APPLICATIONS NEED
None.
WHAT A READ-ONLY ROOT FILESYSTEM PROVIDES
An attacker unable to write tools into the container.
WHAT IT REQUIRES
Writable mounts for temporary files.
WHAT TO TEST
That the application works under all of this.
