Docs
Kubernetes
Security
Pod Security Standards

Pod Security Standards in Kubernetes

Security is a critical aspect of running Kubernetes workloads, and ensuring Pods operate with the least privilege principle minimizes risks related to container breakout, privilege escalation, and compromised workloads. Thalassa Cloud enforces Kubernetes Pod Security Standards (PSS) to provide security controls based on three levels of security:

  • Privileged: No security restrictions, allowing full access to host resources.
  • Baseline: Basic security settings to prevent accidental privilege escalation.
  • Restricted: Strong security controls, enforcing least privilege and strict workload isolation.

By implementing the appropriate Pod Security Standards, teams can reduce attack surfaces, prevent misconfigurations, and comply with security best practices.

1. Understanding Pod Security Standards

Kubernetes defines Pod Security Standards (PSS) as guidelines for securing workloads within a cluster. These policies can be enforced using Pod Security Admission (PSA), which ensures compliance before a Pod is created.

Security LevelDescriptionUse Case
PrivilegedNo restrictions; allows host namespace sharing, privileged containers, and unrestricted volume access.Used only for trusted workloads, debugging, or infrastructure-related deployments.
BaselinePrevents most privilege escalation, requires non-root execution, and limits access to host namespaces.Suitable for most workloads that do not need host access.
RestrictedEnforces strict security policies, disallowing privilege escalation, root execution, and host networking access.Recommended for multi-tenant environments and sensitive workloads.

Thalassa Cloud follows the Baseline policy as a default and recommends using Restricted policies for production environments.

2. Implementing Pod Security Admission (PSA)

Kubernetes Pod Security Admission (PSA) enforces Pod Security Standards at the namespace level. Each namespace can have a security level set to enforce, audit, or warn.

Example: Enforcing Restricted Policies in a Namespace 

apiVersion: v1
kind: Namespace
metadata:
  name: secure-apps
  labels:
    pod-security.kubernetes.io/enforce: "restricted"
    pod-security.kubernetes.io/enforce-version: "latest"

This ensures that any Pod failing Restricted security requirements is denied from running in the secure-apps namespace.

3. Pod Security Best Practices

Running Containers as Non-Root

By default, containers should run as a non-root user to prevent privilege escalation.

securityContext:
  runAsNonRoot: true
  runAsUser: 1000

Dropping Unnecessary Capabilities

Linux capabilities should be restricted to the minimum required.

securityContext:
  capabilities:
    drop:
      - ALL

Restricting Host Access

Pods should not have access to host resources unless explicitly required.

securityContext:
  allowPrivilegeEscalation: false
  privileged: false

Enforcing Read-Only Root Filesystem

To prevent tampering with system files inside the container, enforce a read-only filesystem.

securityContext:
  readOnlyRootFilesystem: true

4. Summary

Ensuring Pod security in Thalassa Cloud requires enforcing the least privilege principle, restricting host access, and securing workload configurations.

Best Practices:

  • Use Pod Security Admission (PSA) to enforce security policies at the namespace level.
  • Run containers as non-root and drop unnecessary capabilities.
  • Restrict host access by disabling privilege escalation.
  • Enforce read-only root filesystems to prevent tampering.

By following these security best practices, workloads in Thalassa Cloud Kubernetes can remain secure, resilient, and compliant.

Additional Resources

Network PoliciesRBAC