Kubernetes Pod Security Policies
This article takes a look at some of the Kubernetes pod security policies and some of the use cases for securing your cluster.
Join the DZone community and get the full member experience.Join For Free
Kubernetes was not famous for its security features when it was first introduced as a container orchestration system, but the platform has evolved a lot over the years. Aside from being portable and infrastructure-agnostic, Kubernetes also offers a wide range of security features and tools that can help you harden the security of your apps and services.
Pod security is one of the ways you can safeguard your entire cloud ecosystem. Kubernetes Pod Security Policies are basically a series of policies that govern how Pods interact with the host operating system and other resources within the cluster. It defines the conditions under which Pods are allowed to run and use cluster resources.
Kubernetes Pod Security Policies will act as the controller that allows the creation and update and Pods within the cluster. You start by defining a set of rules for the pods and then activate the controller so that new and updated Pods are checked against those rules.
Privileges and Control Aspects
Before we get to how Pod Security Policies can be configured, let’s take a second to appreciate the extensive set of privileges and control aspects that are now offered with Kubernetes. Keep in mind that Kubernetes Pod Security Policies require Kubernetes 1.13 or newer to work, but the control aspects we are discussing in this article are the ones available in the latest 1.18 version.
Those control aspects are:
- Usage of host namespaces
- Usage of host networking and ports
- Usage of volume types
- Usage of host filesystem
- Running of privileged containers
- Linux capabilities
- SELinux context of the container
- Allowed Proc Mount types
- AppArmor profile used by containers
- Seccomp profile used by containers
- Sysctl profile used by containers
- Allocation of FSGroup that owns the volumes used by Pods
- Setting a read-only root file system as a requirement
- User and group IDs of container
- Limiting escalation to root privileges
Other control aspects are already in the pipeline, so expect new aspects and privilege control elements to be added in the future versions of Kubernetes. With the existing control aspects alone, there are so many things that can be configured for a better, more secure cluster.
That actually brings us to the next part of this article.
Enabling Pod Security Policies
By default, Pod Security Policies is an optional admission controller. You have to actively enable this controller for it to work. Before you choose to enable it, however, make sure you create the policies first. Enabling PSP without a policy in place will stop the creation of containers entirely.
Authorizing policies is easy. You can do it via RBAC or use native tools provided by your cloud infrastructure provider to complete this task. Amazon EKS, for instance, lets you define eks.privileged to configure policies. Run kubectl describe psp eks.privileged to check the policy details of your EKS instance.
The default Pod Security Policies from Amazon EKS is a good starting point, but that doesn’t mean you cannot customize it further or use a customized YAML file to configure your security policies. Create privileged-podsecuritypolicy.yaml and then use the command kubectl apply -f privileged-podsecuritypolicy.yaml to apply the preconfigured security policies to your instance.
Use Cases and Securing Your Cluster
Activating and assigning a security policy are the easy parts. The real challenge is configuring your Pod Security Policies to achieve that balance between maximum security and seamless integration of CI/CD pipeline. After all, your pipeline needs to be able to create and update Pods in order to remain effective.
There are several things you can define in the Pod Security Policies to achieve that balance, including:
- Setting the root filesystem to read-only. This is done by adding readOnlyRootFilesystem: true to the first line of the policy.
- You can add privileged: false to make sure that no privileged Pods get created or updated. This will practically set the baseline for cluster security.
- At the same time, you also need to prevent privilege escalations, and that is automatically done when you the root filesystem to read-only.
- Continue by setting non-root users as a must. Root users should not be used to spool up new pods since they have access to sensitive system functions. Simply add runAsUser: rule: ‘MustRunAsNonRoot’ and you are all set.
- To supplement the previous step, make sure fsGroup and supplementalGroups are not root, and that the allowed range is defined properly.
- Configure the pod to only use specified folumes using these parameters: configMap, emptyDir and secret for your volumes policy.
- As for annotations, define your seccomp profile so that it gets adjusted before deployment. At this point, your Pods will be secure enough for most use cases.
Should you stop there? The answer to this question depends on the kind of applications you run in your cluster. Some applications require Pods with higher privileges. Others are less sensitive and will still run properly even without the privileges defined in the previous PSP configuration.
After changing security policies, make sure you delete the previous one and apply a new one. Every security policy implementation requires this step, plus the usual kubectl get pod,deploy,rs to make sure that changes get implemented immediately.
Flexibility and Extra Features
Pod Security Policies is a feature that offers additional flexibilities for development teams and infrastructure administrators. Support for multiple PSPs is one of the handiest features to utilize in many cases. By setting multiple Pod Security Policies, you provide default values to different Pods depending on certain conditions.
Basically, Kubernetes will select the first Pod Security Policies that allow for the pod to be created, and then pull default values from that PSP. It will cycle through security policies by name and stop when the previous condition is met. A good way to gain granular control over this process is by naming your PSPs using numbers as starting characters.
The Kubernetes API documentation has a detailed list of parameters and fields that can be used to define your Pod Security Policies. If you want to learn more about how you can flexibly configure Pod security, check the PodSecurityPolicySpec v1beta1 policy section of the API documentation.
Published at DZone with permission of JP La Torre. See the original article here.
Opinions expressed by DZone contributors are their own.