Pod Security Standards at the Namespace

Introduction

A privileged pod in Kubernetes is a pod that is granted elevated permissions and capabilities that go beyond the default security restrictions, and as Kubernetes continues to dominate the world of container orchestration, securing your clusters has never been more crucial. Implementing Pod Security Standards (PSS) at the namespace level is a powerful strategy to ensure your applications run securely. In this guide, we’ll explore how to implement and manage these standards to enhance your Kubernetes security posture, all shared through the expert lens of IntoDevOps.com.

What Are Pod Security Standards?

Pod Security Standards are a set of guidelines designed to enforce secure configurations for Kubernetes pods. They help mitigate risks by ensuring that pods adhere to best security practices, thereby reducing vulnerabilities.

The Three Primary Security Standards in Kubernetes:

Simplified

• Restricted: Enforces strict security practices for high-security applications.
• Privileged: No restrictions, which is the same as having no Pod Security Standards.
• Baseline: Suitable for most applications, balancing security and usability.

Details

• Privileged: The Privileged policy is purposely-open, and entirely unrestricted.
• To check what are the exact restrictions that we have in Baseline and Restricted check Kubernetes-website.

Why Implement Namespace-Level Security?

Namespaces in Kubernetes provide a way to logically separate and manage resources. Applying security policies at the namespace level has several advantages.

Deep Dive into Kubernetes Pod Security StandardsPrivileged Pods

• Use Cases: System-level operations like logging and monitoring.
• Risks: Full access to host resources, which could be exploited if compromised.
• Examples: Pods needing to manage network settings or directly access hardware devices.

Baseline Pods

• Use Cases: General-purpose applications.
• Advantages: Balances security with functionality, restricting risky configurations while supporting common use cases.
• Examples: Standard web applications and APIs.

Restricted Pods

• Use Cases: High-security applications handling sensitive data.
• Security Benefits: Minimizes the attack surface with stringent controls.
• Examples: Financial services, healthcare applications.

Implementing Pod Security Standards at the Namespace Level

Apply settings

• Let’s add a restricted policy to the example namespace and see what would be the behavior of it.

# Create namespace
kubectl create ns example
# Apply restriction to example namespace
kubectl label --overwrite ns example \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/warn-version=latest \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/audit-version=latest

Check if the namespace is being restricted:

kubectl run nginx --image nginx -n example

You should see something like this:

Error from server (Forbidden): pods "nginx" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

Resources

• https://kubernetes.io/docs/tutorials/security/ns-level-pss/