How to create a Kubernetes security policy

If you’re looking to take your Kubernetes security to the next level, you’ll want to start working with pod security policies. Here’s a quick introduction to this feature.

kuberneteshero.jpg

Image: Jack Wallen

Kubernetes is an incredibly powerful container management tool. If you’ve worked with containers long enough, you know that security has to take a central role in the deployment of your apps and services. Without locking down those containers, havoc could be wreaked on your network. 

You certainly don’t want that.

So, what can you do? With Kubernetes you should consider establishing pod security policies.

SEE: 10 things companies are keeping in their own data centers (TechRepublic download)

What is a pod?

If you’re new to Kubernetes, you might not know what a pod is. Simply stated, a Kubernetes pod is a collection of processes that make up a container, such as:

In other words, a pod is a unit of deployment–either a single container or a number of containers working together.

Now that you understand what a pod is, let’s see what we can do about crafting a security policy.

What is a pod security policy?

The Kubernetes pod security policy is a resource that controls the security of a pod specification. Using the PodSecurityPolicy object definition, you can control things like:

  • The ability to run privileged containers

  • Privilege escalation

  • Access to volume types

  • Access to host file systems

  • Usage of host networking 

But how to define the policy? As with almost everything in Kubernetes, this is defined within a YAML file.

How to create a Kubernetes pod security policy

Let’s create a Kubernetes pod security policy that prevents the creation of privileged pods and controls access to volumes. First, we must create the YAML file. From a terminal window, issue the command:

nano psp.yaml

In that file, paste the following:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata: name: psp
spec: privileged: false seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny volumes: - '*'

In that file, we prevent privileged pods from being created with the line:

privileged: false

We also allow the following (via the RunAsAny rule):

  • SeLinux – allows any user to control SELinux within pods

  • Linux groups – supplemental Groups

  • runAsUser – allows users to run container entry points with a different username

  • fsGroup – volumes which support ownership management

Save and close the file.

Now we have to apply the policy. This is done with the command:

kubectl apply -f psp.yaml

The command will report back:

podsecurity.policy/psp created

At any time, you can modify the policy YAML file and run the same command to re-configure the policy. 

Check to make sure your policy is available by issuing the command:

kubectl get psp

The output will list the details for the policy (Figure A).

Figure A

pspf.jpgpspf.jpg

Our Kubernetes pod security policy has been created.

How to assign a Kubernetes pod security policy

Now that you’ve created your policy, how do you assign it? This is done using Role Based Access Control (RBAC). Create an RBAC configuration for the policy with the command:

nano rbac-psp.yaml

In that file, paste the following:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata: name: psp:psp
rules:
- apiGroups: - extensions resources: - podsecuritypolicies resourceNames: - psp verbs: - use
--- kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata: name: psp:psp
subjects:
- kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io
roleRef: kind: ClusterRole name: psp:psp apiGroup: rbac.authorization.k8s.io

The above file will create a cluster-wide role named psp that can use our new policy we named psp. This will also create a cluster-wide role binding which gives access to the psp:psp role to every authenticated user.

Save and close the file. Create this policy with the command:

kubectl apply -f rbac-psp.yaml

We’ve now created a policy and an RBAC control. Let’s find out if we’re now able to use this new policy. Issue the command:

kubectl auth can-i use psp/psp

The output should say “yes.”

Of course, it should say “yes,” as I am an admin user. But what if we test it with any user? Do that with the command:

kubectl auth can-i use psp/psp --as-group=system:authenticated --as=any-user

You should now see “no” in the response. 

You’ve just created a Kubernetes pod security policy, assigned it with RBAC, and tested it to make sure the policy actually works. You’re one step closer to gaining more security with your Kubernetes container deployments.

Also see

https://www.techrepublic.com/article/how-to-create-a-kubernetes-security-policy/#ftag=RSS56d97e7