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 |
|