Skip to main content

Prerequisite for deployment on the Cloud Platform

We use two Pod Security Policies in the Cloud Platform, restricted and privileged.

By default, any new environment/namespace will be assigned the restricted policy


The main impact of the restricted policy is that it prevents pods/containers from running as the root user.

A container’s user is usually defined in its Dockerfile. If no user is explicitly specified in the Dockerfile, the chances are that it will run as root.

Not being able to use root also implies that it is impossible to bind to a privileged port (e.g. 80, 443).

The policies only take effect after the container has started. Anything in the Dockerfile can be run as root at image build time e.g. to install required software.

How to adapt to the pod security policies

Most of the time, your application’s Dockerfile can be easily adapted by:

  • Creating a user with a UID which is greater than 1 (which is the UID reserved for root)

  • Giving this user any required permissions to access the files/directories the application requires.

  • Adding a USER clause in your Dockerfile to switch to your non-root user


FROM busybox

RUN mkdir -p /opt/myFolder && \
    adduser --disabled-password myNewUser -u 1001 && \
    chown -R myNewUser:myNewUser /opt/myFolder

USER 1001

CMD myApplication

Depending on the base image, you might also need to explicitly create a group for the user. In the busybox example above, a ‘myNewUser’ group is implicitly created by the adduser command.

You must specify the user by its numeric UID, as above, not by its username. If you use the username (USER myNewUser) then the pod security policy will not be able to tell that that is a non-root user, and your container will not be scheduled.

A more complete example can be found here : Dockerfile

Adapting the NGINX image

Since NGINX binds itself to a privileged port by default, it will not be able to run as-is with the restricted policy.

The cloud-platform team will update this page with relevant documentation regarding nginx, as soon as it is ready. In the meantime, feel free to reach out to the cloud-platform team for help : Getting Help

This page was last reviewed on 16 June 2022. It needs to be reviewed again on 16 September 2022 .
This page was set to be reviewed before 16 September 2022. This might mean the content is out of date.