Kubernetes Pod Security Policies to know!

Filed Under: Random
Kubernetes Pod Security Policies

Hello, readers! This article talks about the Kubernetes Pod Security Policies and their implementation, in detail.

So, let us begin!!


What is a Pod Security Policy?

A Kubernetes Pod Security Policy is a set of rules that the pod must exhibit to be accepted by the security system within the cluster. It is a cluster-level resource that inspects and controls the security side of the pod’s specification.

It monitors the security aspects of the pod in terms of the data that is a part of its specification. Pod Security policy acts as an admission controller which enables us to validate the specification of the pod against the requirements of the scenario.


Why is Pod Security essential?

Imagine a scenario that we have hosted our application over the containers. Containers reside within a pod, so the pod takes care of all the communication to the external world and specifications with respect to an application.

As pod is the essential shell of communication, it is very important for us to secure the pod. That is security in terms of all the networks and the necessity of the application specification. Thus Pod security filters and secures in terms of access and actions that would happen within the pod.


Defining a Pod Security policy within a pod

Having understood the necessity of pod security, let us now have a look at the process of inculcating it into the pod YAML.

Pod security.YAML

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: demo
spec:
  privileged: false  # Don't allow privileged pods!
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

In the above generic YAML, we have denied privileged pods to have access or any special upper hand. Also, we have defined various specifications such as:

  1. runAsUser
  2. fsGroup
  3. volume, etc.

Authorizing Security Polices

The creation of a pod security policy does not mean that we can use it in our namespaces or applications. To have a security policy integrated with our application, we would need to have a custom Role binding being i.e. access on it.

To achieve the same, we create a service account in the desired namespace using the below command-

kubectl create sa service_acc_name -n namespace_name

Post which, we create a custom ClusterRole to grant access to use the security policies within the workloads.

Example: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterrole-name
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
  - <list of policies to authorize>

Having created a cluster role, it is now the time to bind it to a set of users through cluster role binding.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <role-binding name>
roleRef:
  kind: ClusterRole
  name: <cluster-role name>
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts:<namespace>

It is usually a best practice to do the cluster role binding of all the service accounts in the authorized namespaces to the custom cluster role.

This will allow all the pods of a particular namespace to have the custom cluster role which enables them to use the pod security policies.

By this, the namespaces or deployments with other configurations stay unexposed to the pod security policy.

Post which, we define a pod security policy (shown in the above section) and then apply it for the specific deployments/workloads or pods who have the necessary privileges or access to conduct and carry the pod security policy.


Conclusion

By this, we have reached the end of this topic. Feel free to comment below, in case you come across any questions.

For more such posts related to Kubernetes, Stay tuned with us.

Till then, Keep Learning and Happy Analyzing!!

Leave a Reply

Your email address will not be published. Required fields are marked *

close
Generic selectors
Exact matches only
Search in title
Search in content