Pod Security Standards (PSS): All You Need to Know

Among administrators and developers, Kubernetes is the most popular platform. Containerization has made it easier than ever to quickly create and deploy Kubernetes application environments. When it comes to container adoption, however, security is the most prominent cause of worry.

To enhance Kubernetes security, you must regulate and limit the number of pods that may be generated and deployed in your environment. Kubernetes has given a beta feature called Pod Security Policy (PSP) for this purpose, which will shortly be deprecated and replaced with a standard called Pod Security Standards (PSS).

In this blog, we are going to learn about the alternatives to the traditional Pod Security Policy, i.e. Pod Security Standards (PSS) and Pod Security Admission (PSA).

In this blog post we will learn:

1. Pod Security Policy & its depreciation
2. Moving to a new pod security solution
3. Pod Security Standards (PSS) and Pod Security Admission (PSA)
4. Conclusion

Pod Security Policy & its depreciation

The PSP functionality has been present since Kubernetes’ early days and is intended to prevent misconfigured pods from being produced on a particular cluster. PSP has 16 controls that check various Pod parameters such as:

• Running of privileged containers
• Usage of host namespaces
• Usage of host networking and ports

The primary disadvantages of the PSP are its lack of support for additional resource types and its restricted set of controls, which does not include some container runtime-specific characteristics. PSP is scheduled to be phased out in 2021, and a better solution exists to meet the same demand. The real deprecation date has recently been pushed out from February 1st, 2021 to May 3rd, 2021 to give providers that utilize PSP, like as Azure, time to prepare. PSP is scheduled to be deprecated in Kubernetes 1.21 and removed in version 1.25. According to the Kubernetes deprecation policy, older versions will no longer get support nine months after the functionality is deprecated.

Moving to a new pod security solution

Because PSPs are being phased out and are no longer being actively developed, cluster administrators and operators must replace those security measures. This need can be met by two options:

• Policy-as-code (PAC) solutions from the Kubernetes ecosystem.
• Kubernetes Pod Security Standards (PSS) & Pod Security Admission (PSA).

There are a number of open source PAC solutions for Kubernetes. These solutions are not part of the Kubernetes project; instead, they are obtained through the Kubernetes ecosystem. The following are some PAC solutions:

• OPA/Gatekeeper
• Open Policy Agent (OPA)
• Kyverno
• Kubewarden
• jsPolicy

Both the PAC and PSS systems may survive with PSP; they can be used in clusters prior to the removal of PSP. This facilitates migration from PSP. In this blog, we will learn about Pod Security Standards (PSS) and Pod Security Admission (PSA).

Learn more about Top security tools in k8s.

Pod Security Standards & Pod Security Admission

The Kubernetes Auth Special Interest Group produced the Pod Security Standards (PSS) and Pod Security Admission (PSA) in response to the PSP deprecation and the continued requirement to govern pod security out-of-the-box, using a built-in Kubernetes solution (PSA). The PSA effort includes a webhook project for admission controllers that implements the controls described in the PSS. This admission controller method is similar to that utilized in PAC systems.

PSS establishes three distinct policies to cover the whole security spectrum These regulations are cumulative, ranging from liberal to restrictive. These policies are defined as:

Privileged: An unrestricted (unsecured) policy that grants the greatest permissible level of access. This policy allows for well-documented privilege escalation. It’s the lack of a policy. This is useful for logging agents, CNIs, storage drivers, and other system-wide programs that require privileged access.

Baseline: A policy that is as restrictive as possible while preventing known privilege escalation. Allows for the use of the default (minimally stated) Pod configuration. The baseline policy forbids the usage of hostNetwork, hostPID, hostIPC, hostPath, and hostPort, as well as the ability to add Linux capabilities, among other things.

Restricted: Strict policy that adheres to current Pod hardening best practices. This policy builds on the baseline and adds additional constraints, such as the inability to operate as a root or a root-group. Restricted policies can have an effect on an application’s capacity to function. They are particularly intended for the execution of security-critical applications.

These policies specify pod execution profiles, which are divided into three tiers of privileged vs. limited access.

PSA runs in three modes to apply the controls set by the PSS:

• enforce: Policy breaches will result in the pod’s rejection.
• audit: Policy breaches will result in the inclusion of an audit annotation to the event recorded in the audit log, but they are otherwise permissible.
• warn: Policy infractions will result in a user-facing warning, although they are otherwise permitted.

PSA uses Exemptions to avoid enforcing infractions against pods that would otherwise be implemented. These exceptions are detailed below.

• Usernames: requests from users with an exempt authenticated (or impersonated) username are ignored.
• RuntimeClassNames: Exempt runtime class names are disregarded in pods and workload resources.
• Namespaces: In an exempt namespace, pods and workload resources are disregarded.

As part of the API server setup, these exemptions are applied statically in the PSA admission controller configuration. Exemptions in the Validating Webhook implementation can be set in a Kubernetes ConfigMap resource, which is mounted as a volume in the pod-security-webhook container.

Learn how to configure Pod Security Standards (PSS).

Conclusion

As we’ve seen, Kubernetes pod security policies provide a handy way to enforce strong security settings across a cluster in an automatic fashion. But unfortunately, it is not going to be a part of k8s, so we have marvelous alternatives for that. We will make use of the alternatives as a way to keep Kubernetes and the containers running in it securely.

Frequently Asked Questions

Related/References

• Visit our YouTube channel “K21Academy”
• Certified Kubernetes Administrator (CKA) Certification Exam
• (CKA) Certification: Step By Step Activity Guides/Hands-On Lab Exercise & Learning Path
• Certified Kubernetes Application Developer (CKAD) Certification Exam
• (CKAD) Certification: Step By Step Activity Guides/Hands-On Lab Exercise & Learning Path
• Create AKS Cluster: A Complete Step-by-Step Guide
• Container (Docker) vs Virtual Machines (VM): What Is The Difference?
• How To Setup A Three Node Kubernetes Cluster For CKA: Step By Step

Join FREE Masterclass of Kubernetes

Discover the Power of Kubernetes, Docker & DevOps – Join Our Free Masterclass. Unlock the secrets of Kubernetes, Docker, and DevOps in our exclusive, no-cost masterclass. Take the first step towards building highly sought-after skills and securing lucrative job opportunities. Click on the below image to Register Our FREE Masterclass Now!