Working with Pod Security Standards in Thalassa Cloud Kubernetes

Pod Security Standards (PSS) are a set of security policies that define how pods should be configured to minimize security risks. By enforcing these standards, you can prevent privilege escalation, restrict host access, and ensure workloads run with the least privilege necessary. In Thalassa Cloud Kubernetes, you can configure default enforcement levels at the cluster level and apply additional policies at the namespace level. This guide explains how Pod Security Standards work, how to configure default enforcement in Thalassa Cloud Kubernetes Service, and how to apply security policies to your workloads.

Explaining Pod Security Standards

Pod Security Standards define three security levels that progressively restrict what pods can do:

• Privileged: No restrictions. Allows full access to host resources, privileged containers, and unrestricted volume access. This level should only be used for trusted workloads, debugging, or infrastructure-related deployments.
• Baseline: Basic security settings that prevent most privilege escalation. Requires non-root execution and limits access to host namespaces. Suitable for most workloads that don’t need host access.
• Restricted: Strong security controls that enforce least privilege and strict workload isolation. Disallows privilege escalation, root execution, and host networking access. Recommended for multi-tenant environments and sensitive workloads.

These standards are enforced using Pod Security Admission (PSA), which is built into Kubernetes and evaluates pods before they are created. PSA can operate in three modes:

• enforce: Rejects pods that violate the security policy
• audit: Allows pods but logs violations
• warn: Allows pods but warns users about violations

Configuring Default Enforcement in Thalassa Cloud Kubernetes

Thalassa Cloud Kubernetes Service allows you to configure the default Pod Security Standard enforcement level when creating or updating a cluster. This sets a cluster-wide default that applies to all namespaces unless overridden at the namespace level.

Setting Default Enforcement During Cluster Creation

When creating a new Kubernetes cluster in Thalassa Cloud, you can specify the default Pod Security Standard enforcement level. This can be configured through:

1. Thalassa Cloud Console: When creating a cluster, select the desired default enforcement level (Privileged, Baseline, or Restricted) in the cluster configuration options.

2. Thalassa Cloud API: Specify the podSecurityStandard field when creating a cluster:

{
  "name": "my-cluster",
  "podSecurityStandard": "baseline",
  ...
}

3. Thalassa Cloud CLI (tcloud): Use the --pod-security-standard flag:

tcloud kubernetes cluster create my-cluster \
  --pod-security-standard baseline \
  --region nl-01 \
  --node-pool ...

Updating Default Enforcement

You can update the default enforcement level for an existing cluster through the Thalassa Cloud Console, API, or CLI. This change affects all namespaces that don’t have explicit Pod Security Standard labels.

Available Enforcement Levels

Thalassa Cloud supports all three Pod Security Standard levels as default enforcement:

Applying Pod Security Standards at the Namespace Level

While the cluster default provides a baseline, you can override it for specific namespaces by applying Pod Security Standard labels. This allows you to have different security levels for different workloads.

Namespace Labels

Pod Security Admission uses labels on namespaces to determine the enforcement level. The labels follow this pattern:

• pod-security.kubernetes.io/enforce: <level> - Enforcement mode (rejects violating pods)
• pod-security.kubernetes.io/audit: <level> - Audit mode (logs violations)
• pod-security.kubernetes.io/warn: <level> - Warn mode (warns about violations)
• pod-security.kubernetes.io/enforce-version: <version> - Version of the standard to enforce
• pod-security.kubernetes.io/audit-version: <version> - Version for audit mode
• pod-security.kubernetes.io/warn-version: <version> - Version for warn mode

Example: Enforcing Restricted Policy

Create a namespace with Restricted enforcement:

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

This namespace enforces Restricted policies, meaning any pod that violates Restricted requirements will be rejected.

Applying Labels to Existing Namespaces

You can add Pod Security Standard labels to existing namespaces:

kubectl label namespace my-namespace \
  pod-security.kubernetes.io/enforce=restricted

Or using a patch:

kubectl patch namespace my-namespace -p '{"metadata":{"labels":{"pod-security.kubernetes.io/enforce":"restricted","pod-security.kubernetes.io/enforce-version":"latest"}}}'

Understanding Security Requirements by Level

Each Pod Security Standard level has specific requirements.

Common Errors

Error: pods “my-pod” is forbidden: violates PodSecurity “restricted:latest”

This indicates the pod violates Restricted policies. Common causes:

• Running as root (runAsUser: 0)
• Missing readOnlyRootFilesystem: true
• Capabilities not dropped
• allowPrivilegeEscalation: true

Error: pods “my-pod” is forbidden: violates PodSecurity “baseline:latest”

This indicates the pod violates Baseline policies. Common causes:

• Privileged container
• Host namespace sharing
• allowPrivilegeEscalation: true without dropping capabilities

Testing Pod Compliance

Test if a pod specification complies with a security level:

kubectl apply --dry-run=server -f pod.yaml

If the pod violates policies, you’ll see an error message indicating which policies were violated.

Further Reading

For more information about Pod Security Standards, see the official Kubernetes documentation and the Pod Security Admission documentation.