Comparison
Privileged containervsRootless container
Privileged container
someone added one flag to make a mount work, and that container can now reconfigure the host.
A container run with most or all kernel capabilities and without the usual restrictions, effectively giving it host-level power. There are legitimate uses — some node agents genuinely need it — and there is a very long tail of workloads granted it once to unblock something and never revisited. It is the first thing an admission policy should be looking for, because it turns an application compromise into a node compromise.
Full entry →Rootless container
the process inside is uid 1000 rather than root, so a container escape lands the attacker as nobody in particular.
Running a container as an unprivileged user, either by setting a non-root user in the image or by remapping the container's root to an ordinary host user. Default images run as root, and root inside a container is very often root on the host if anything else goes wrong, so this is one of the highest-value settings available. It costs you the ability to bind low ports and write to paths built for root, which is usually a one-line fix and occasionally a rewrite.
Full entry →