Skip to main content

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 applications
  • privileged 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 use nginx-unprivileged.

Most of the time, you can adapt your Dockerfile by:

  1. creating a user with a UID that is greater than 1 (which is the UID reserved for root)
  2. giving this user the required permissions to access the files/directories that are required for the application
  3. 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.

This page was last reviewed on 18 November 2022. It needs to be reviewed again on 18 February 2023 .
This page was set to be reviewed before 18 February 2023. This might mean the content is out of date.