Pod Security Standards

What are Pod Security Standards (PSS)?

Pod Security Standards (PSS) is a framework that enables engineers to share and restrict privileges for different kinds of pods and users. These allow or disallow access to users and resources in the clusters, thus securing the Kubernetes clusters and the complete environment efficiently. 

There are three types of policies that range between highly permissive and highly restrictive. Engineers can implement a policy type based on pod security requirements. These include:

• Privileged: The policy purposely offers unrestricted access and targets trusted users who manage system-level and infrastructure-level workloads. The mechanism is synonymous with allow-by-default and is the opposite of deny-by-default. With this, all restrictions can be disabled.

• Baseline: With baseline policies, operators and developers can easily manage common containerized workloads without access to privileged sections of the Kubernetes environment. These are for users who work on non-critical applications.

• Restricted: The restricted policies harden Kubernetes by limiting access and privileges. This comes at the cost of compatibility and ease of communication between resources but makes the environment highly secure. It is for users, operators, and developers working on security-critical applications and low-trust users. 

Overall, Pod Security Standards outline security controls for Kubernetes resources and ensure cluster operations, workload behaviors, and environmental integrity are well maintained.

What is Pod Security Policy (PSP) and why was it deprecated?

Before the establishment of PSS, security used to be controlled using Pod Security Policy (PSP). One of its key limitations was that a pod must run a set of pre-defined conditions mentioned in the PSP to be recognized by the Kubernetes environment as a valid resource. Without the specifications, the pod would not be accepted into the system. 

Since Kubernetes v1.21, PSP was deprecated due to its limitations and complex nature. According to feedback from Kubernetes developers, PSPs were confusing, and engineers found it difficult to determine which PSPs to apply in a given scenario. As a result, unintentional configuration and specification errors would often occur, compromising the Kubernetes environment’s security. The admission controller has now been replaced by Pod Security Admission (PSA), which enforces the policies outlined by the Pod Security Standards.

Functionalities of Pod Security Standard

The Privileged policy functions like the mechanism of allow-by-default for various resources. However, Baseline and Restricted policies can control the following components with the corresponding policies:

Baseline

Restricted

Restricted comprises everything that comes under Baseline Policy. Furthermore, it also includes the following:

Benefits of Pod Security Standards

• With Pod Security Standards, securing Kubernetes clusters becomes simpler, more straightforward, and more efficient. The framework enhances the security posture of the clusters.

• The policies prevent unauthorized actions from low-trust users and other resources, thus preventing potential vulnerabilities that can be exploited.

• With Restricted and Baseline policies, pod security is hardened by leveraging the least privilege principles. As a result, the attack surface is reduced, and the impact of a potential malicious attack is minimized.

• Pod Security Standards also allow engineers to configure the Kubernetes resources and environments that align with industry security standards and regulatory frameworks, which help with cluster security.

Working with Pod Security Standards

Pod Security Admission is the admission controller to enforce Pod Security Standard policies. This occurs via the following three modes:

• Enforce: With this, policy violations in a pod will result in its rejection.
• Audit: Pods with policy violations will be allowed, but the event in the audit log will be annotated with “audit.”
• Warn: Pods with policy violations will be allowed, but the users will receive a warning. 

Example of Namespace Configuration using PSS and PSA

In the below example, the namespace is configured with a cluster-wide setting, and the configuration occurs by default. The labels are commented, but by uncommenting, the PSS can the PSA can implement policies for the namespace.

apiVersion: v1
kind: Namespace
metadata:
  name: psa-pss-test-ns
  labels:    
    # pod-security.kubernetes.io/enforce: privileged
    # pod-security.kubernetes.io/audit: privileged
    # pod-security.kubernetes.io/warn: privileged
    
    # pod-security.kubernetes.io/enforce: baseline
    # pod-security.kubernetes.io/audit: baseline
    # pod-security.kubernetes.io/warn: baseline
    
    # pod-security.kubernetes.io/enforce: restricted
    # pod-security.kubernetes.io/audit: restricted
    # pod-security.kubernetes.io/warn: restricted

Limitations and considerations

• Although Pod Security Standards are less complex than its predecessor PSP (Pod Security Policies), adopting and maintaining the specifications is challenging due to the dynamic nature of the environment and resource usage.
• The hardening of pod security causes compatibility issues and impacts the seamless functionality of applications.
• While using Pod Security Standards and Pod Security Admission, it is important to understand how the application performances will be impacted and to what extent the security can be prioritized over the performance. Overall, it must be about creating a balance between the two factors.