A container is a great way to isolate a web server or microservice into a package easily deployable to any public, private, or on-prem hosting solution. But with any public process comes the additional security exposure. A standard best-practice in hosting is to not run as root, the super-user in Linux. If the process runs with escalated permissions and the process can be compromised by an attacker, it’s easier for the attacker to pivot their attack at other resources including internal network resources.
Business applications don’t need elevated permissions to reach network resources such as databases and other microservices. The only reason for elevated permissions is to manage the Kubernetes cluster itself.
Shoreline highlights any pods running as root. Though Shoreline can’t alter the read-only container image, the dashboard can raise an alert to help developers build better Dockerfiles.
As a best-practice in containers, one should include the USER directive in their Dockerfile, and define this user with the minimal permissions needed to run the app. If you’re looking to block launching pods with elevated permissions, look to the Kubernetes docs on the built-in Validating Admission web hook.
