Requirements for deploying a container to the Cloud Platform
Overview
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:
restricted
pod, for normal applicationsprivileged
pod, 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
Overview
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 root
.
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 usenginx-unprivileged
.
Most of the time, you can adapt your Dockerfile
by:
- 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
USER
instruction 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.
Getting support
If you need help with any of the above requirements, your local team or the Cloud Platform can provide advice.