See how to check containers that are running as root within your Kubernetes clusters.
Hi, I'm here to discuss the Insights action item called should not be allowed to run as root, and to demonstrate some ways in which you can mitigate the security vulnerability. In the Insights UI I've already selected a container running in my cluster that falls under this action item. I click on the action item. It gives you information about the type of Kubernetes object, the namespace, and the name of the Kubernetes object. This helps you easily identify the resource that you need to change. There's also a description section, which includes a short explainer of the action item. And a remediation section, which will provide steps to take to remediate the action item. For this action item, the remediation step says that we should set securityContext.runAsNonRoot=true and it provides examples of what this looks like.
To add the security context parameter, you'll typically want to go to the source of your resource definition. So like a helm values file or a flat manifest file that you have in your repo, whatever the case may be for how you deploy things in your environment. For the purposes of this demo, I'm editing a pod definition file that I have on my local machine. This pod with nonroot.yaml file. Let's take a look at it. As the remediation step says, you can add a security context at the pod or the container level. It's best to do it at the pod level so that it's a default for all the containers, unless you have a compelling reason not to.
What happens when you try to run a pod with this security context key defined? Let's take a look. I'm going to do a k apply -f pod-with-nonroot.yaml to deploy this pod. I have kube control alias to K on my system. When we hit enter, we see that it says the pod has been created. But if we look at the pod, the status says, create container config error. So the pod is not actually running, and we can determine why by doing a k describe po pod-run-as-non-root.
In the events, we'll see this message here, Error: container has runAsNonRoot and image will run as root. The API server is refusing to run to start this pod because we set that security context setting.
Now you have a container that can't run in your cluster, how do you fix it? Generally in your Docker file you'll want to create your own user in group and switch to that user in group before you run your entry point or command arguments.
The other thing that you can do is add the run as user directive to your manifest file. For example here, not only do we have under the security context the RunasNonRoot, we've also specified an alternate user to RunAsUser. The value for this key has to be a user ID, and it has to be a user that exists in the container. Keep in mind that when you switch over and run as NonRoot, you'll want to make sure that the user you create has proper permissions to run the processes within your container.