Feature Overview

Running containers as root is considered a high security risk because if user breaks out of the container, they would have root privileges on the node and therefore OpenShift does not allow running containers as root by default. buildah which is used on OpenShift for building images, requires to run as root and therefore requires exceptions to the "no root containers" security constraint and is considered a security concerns for customers.

With the introduction of user namespaces in Kubernetes, the "no root containers" while  still applies, should be explained more accurately that it applies to running root on the host. For a container that runs in the user namespace, "root" could be allowed while maintaining platform security since container won't be root on the host that it runs on.  Therefore, image builds (buildah) should take advantage of user namespace in order to maintain the same security posture that applies to pods by default outside the user namespaces.

Goals

Enable any authenticated user on OpenShift to build images on the cluster through use of user namespaces without requiring them to make modifications to the default service accounts and default security context constrains available in each namespace.

Requirements

Background, and strategic fit

• Running containers as root is considered a high security risk because if user breaks out of the container, they would have root privileges on the node.
• OpenShift by default does not allow containers to run as root on the platform and is marketed as the “secure by default” platform compared to other Kubernetes distros
• Image builds on OpenShift (classic BuildConfigs, Tekton Pipelines, Shipwright, etc) use buildah for building images from a Dockerfile which needs to run as root for the widest support for Dockerfiles
• We have in the past prioritised UX over security and treated image builds exceptions to the “containers can’t run as root” rule in order to enable users to build images on the platform
  • BuildConfigs pods run with the builder service account to enable buildah to run as root
  • Pipelines use the pipeline service account and a custom SCC similar to anyuid to enable buildah to run as root
• As a result, image builds are not considered to meet the same bar as the platform and some customers go as far as preventing their users from building images on the platform
• Building images on OpenShift should follow the default security constraints that applies to all pods (restricted SCC) while being aware of the user namespaces

Assumptions

• TBD

Customer Considerations

• Ford is one of the larger OpenShift customers that requires this in order to success in establishing OpenShift platform against GCP

Notes

• What are the cases where buildah would fail in user namespaces?
  • Using an id which is more than 65k