Configure a Pod to run with a limited SecurityContext
As Subkube is a shared platform, containers are only allowed to run in so-called 'restricted' PodSecurityPolicies. This guide walks through the steps of creating a deployment, seeing it fail, updating it to use a SecurityContext, and seeing it run successfully.
Prerequisites
- A Namespace in a Subkube Project
- Kubectl
Steps
Setting up a basic Deployment
For this example, we will use the echoserver image, which sets up a simple HTTP
server which replies everything sent to it.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | |
Let's apply the supplied, unmodified deployment, to a namespace, called demo
in our example:
1 | |
Initial testing
Because we don't want to set up any Services or an Ingress, we'll use a PortForward to connect to the Deployment:
1 2 | |
😕
Figuring out why our Pod fails
Let's check the logs and see what is going wrong
1 2 | |
We are shown a CreateContainerConfigError while trying to fetch the Pod's logs. Let's look in to that:
1 2 3 4 5 6 | |
Because we haven't configured our Deployment to run with an appopriate SecurityContext, the Kubernets control plane isn't allowing Pods in our Deployment to run.
Setting a SecurityContext
We can easily fix this by setting a SecurityContext. For many containers this is
as easy as setting the runAsUser property to the value 65534, which translates
to the nobody user account.
By default, the echo-server image runs on port 80, but because our container
won't be running as root, the container will be unable to allocate the port,
and the Pod will fail. Instead, we want to run the echo-server on a different port,
say 8080.
Let's update our Deployment manifest accordingly:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | |
Now we should apply the modified deployment:
1 | |
Testing our revised Deployment
Let's again try to start our PortForward:
1 | |
That should've worked. Now we can use curl to test our Deployment:
1 2 | |