Pod Security Standards: Practical Hardening for Kubernetes

Pod Security Standards (PSS) are a low‑friction way to harden clusters by default. With Pod Security Admission (PSA), you can enforce least‑privilege at the namespace level and prevent risky pods from ever being created. It’s simple, auditable, and fits cleanly into GitOps.

Improving your security posture

Implementing Pod Security Standards is crucial as it helps reduce the blast radius by blocking privilege escalation and host-level access. It allows teams to catch misconfigurations early during the admission phase rather than after deployments, ensuring issues are addressed promptly. Additionally, it provides a framework to apply consistent guardrails across various teams and environments, enhancing overall security posture.

Security levels at a glance

• Privileged: No restrictions. Only for trusted system workloads and debugging
• Baseline: Prevents most escalation; suitable for typical apps
• Restricted: Strict least‑privilege; recommended for production and multi‑tenant

Enable Restricted in a namespace using labels:

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

Applying Pod Security Standards to Thalassa Cloud Kubernetes Service

Thalassa Cloud Kubernetes Service provides the option to configure the default Pod Security Standards (PSS) at the cluster scope, ensuring a consistent security posture across all namespaces.

By default, the PSS is applied using the Kubernetes version of your Control Plane, and the security levels for enforce, warn, and audit are uniformly set to the same level. This cluster-wide configuration acts as a baseline, which can be overridden at the namespace level using the above mentioned labels, allowing for tailored security settings where necessary.

Layering with admission policies (CEL)

PSS/PSA gives you strong, opinionated defaults. For more granular controls (for example, blocking specific registries, enforcing label schemas, or disallowing certain volume types), combine PSA with CEL‑based ValidatingAdmissionPolicy. This lets you codify additional guardrails without writing webhooks.

See also the Kubernetes documentation for ValidatingAdmissionPolicy (CEL): https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/

Final notes

Want the full breakdown of levels, examples, and best practices? See the docs: Pod Security Standards and the official Kubernetes guide.