Requirements for deploying a container to the Cloud Platform
The Cloud Platform Kubernetes cluster uses two “Pod Securty Policies” for pod authorisation within the cluster. A pod is where your container image runs.
Pods in the cluster are run one of two ways, as a:
restrictedpod, for normal applications
privilegedpod, for services to manage cluster-wide things such as automated TLS certificates
By default, and as is best practice, any new namespace on the Cloud Platform will use the
restricted policy for its pods.
Requirements for your container image
Running container images as non-root
The main thing to note is that
restricted namespaces cannot run container images as a
root user once deployed onto the Cloud Platform. This also means that your container image cannot bind services to
system ports (e.g. 80 for HTTP, 443 for HTTPS).
You can use
root commands during build time (e.g. to install software), but not after your container has started running on the Cloud Platform.
A container’s user is usually defined in its
Dockerfile. If no user is explicitly defined, it is likely it will run as
How to run your container image as non-root
Some Docker images will have a unprivileged variant. For example, if you run
nginx, you can use
Most of the time, you can adapt your
- creating a user with a UID that is greater than 1 (which is the UID reserved for root)
- giving this user the required permissions to access the files/directories that are required for the application
- adding a
USERinstruction to use a non-root user
For example, to run
busybox as a non-root user, you can:
FROM busybox RUN mkdir -p /opt/your-folder && \ adduser --disabled-password nonRootUser -u 1001 && \ chown -R nonRootUser:nonRootUser /opt/your-folder USER 1001 CMD myApplication
Depending on your base image, you might need to explicitly create a group for the user. In the above example, a “nonRootUser” group is implicitly created by the
adduser command. An example of how to do this can be found in the multi-container demo application.
Pod Security Policies require that you specify the user by its numeric UID, not by its username. This is because Pod Security Policies cannot tell that a username is for a non-root user.
If you need help with any of the above requirements, your local team or the Cloud Platform can provide advice.