In this Cloud Native Short Take, instructor Valentin Hristev explores the Kubernetes Pod Security Admission. Valentin discusses Kubernetes Pod Security Standards (PSS) isolation levels: privileged, baseline, and restricted and how to invoke PSS at the Kubernetes Namespace level using labels. He creates pods that adhere to and violate policies to demonstrate how each of the PSS isolation levels are practically enforced. RX-M, a cloud-native training, consulting, and advisory firm, provides vital strategies, insights, and tactical approaches in its Cloud Native Short Takes series.
Video Transcript
Hello everyone and welcome back to another RX-M Cloud Native Short Take, my name is Valentin Hristev and today we’ll be talking about Kubernetes Pod Security Admission. Do you remember the good old days when we used Pod Security Policies to enforce security? In version 1.21 of Kubernetes they were deprecated. The successor is called Pod Security Admission and it’s stable since version 1.25.
Before we jump on the admission side we need to talk about Pod Security Standards. Those standards are isolation levels and we have three of them. “Privileged”: no isolation at all–no security, “baseline”: base security, and “restricted” which is the maximum security. Those are non-editable profiles–you cannot edit them. They are hardcoded in Kubernetes core. So now you can use the admission controller to enforce those standards. So how can we do that? You need a namespace and inside the namespace we’re going to create labels. Inside the labels we have modes. Three of the modes are “enforced”, “audit”, and “warning”. With “enforced” if you try to create a pod and you violate the security it’s not going to let you create it. With “warning” is just going to give the client which you’re using–let’s say that you’re using kubectl–just a warning. And the audit is just going to give you this message back that there is a problem and it is also going to put that in the audit log. We need levels and the levels are our Pod Security Standards. So you need to choose some of those three.
Here is an example of how things work. You try to create a pod and you hit the API server and you need to pass the authentication, authorization, and the admission control. So if you create your pod, whatever the configuration is, in the default namespace the pod is going to be created. But let’s say that you have a different namespace which is called core-services. In this namespace, as you can see, we’re enforcing the baseline. If you violate the baseline the pod is not going to be created but if everything is fine the pod is going to be created. We can create another namespace with different modes and different levels so that we can enforce the security that we need.
Let’s jump on a hands-on demo and see how we can do that. Here for our demo I created a single node Kubernetes cluster and the question is pod security admission enabled? The answer is: by default it is. And if you want to check that you can go to `kube-system` and you can find the API Server and you can exec a command inside the kube-apiserver pod. The command is actually the kube-apiserver binary and we’re going to use the --help. Inside the “help” I’m going to search for “admission” and inside the “admission” I’m going to search for “PodSecurity”. From that output I can see that we have enabled and disabled plugins. So here are disabled admission plugins–so everything that you want to disable can go here. But the enabled ones–and those are by default–the PodSecurity is inside that. So if you install your Kubernetes cluster by default the Port Security Admission is already enabled so you don’t need to do anything.
Next step is to examine those two files. The first file is the namespaces. So we’re going to create two namespaces; the first one is going to be called core-services and we’re going to enforce the baseline. For the audit and warning we’re going to keep the restricted. For the maximum security namespace we’re going to use a name `secured-zone` and we’re going to enforce the restricted.
So now let me apply the namespaces. Over here if we describe the namespace `core-services` we can see our labels are here and we are enforcing the baseline. This is the important part. Here we have a pod so let’s go inside our pod. This pod we’re going to create it inside the core-services namespace but before doing that I want to create that pod inside the default namespace and also I want to violate the baseline security option which is called privileged and I’m going to set it to true. We’re going to go look at the baseline properties very shortly–bear with me. So I’m going to save that. I’m going to cat the pod again and I’m going to apply it. This is going to create the pod in my default namespace and as you can see it’s running.
So now I’m just going to create that pod in the core-services–the same pod, right. so let’s run it again. Over here you can see the error. So now we are forbidden to create that pod and the pod violates the pod security baseline. If we check the pods inside the core-services namespace we can see there are no pods.
So what actually we violated is the Pod Security Standard: baseline. So if you go to the official Kubernetes documentation and scroll a little bit down you can see all the options. So what did we violate? We violated the “Privileged Containers”. So as you can see securityContext.privileged and the only allowed value is false. But our value is true so we violate this option over here. So let’s go back, edit the pod, change that to false, and see what is going to happen. I’m going to create the pod again. As you can see the pod is created. Now if we get the pods inside the core-services namespace you can see it’s running. But what is that? That is actually coming from the audit and warning restrictions. Now we can see that we violated not the baseline but we violated the “restricted”. But it just gives us a warning; it doesn’t forbid us to create the pod so the pod is created and we just get the warning. So this is how you actually can enforce Security in your Kubernetes cluster using the Pod Security Admission.
Thank you!