# Pattern: Pod Security Baseline/Restricted

Status: seed
Readiness target: RL3 production
Primary owners: Railiance platform, product repos
Genesis family: Kubernetes and platform

## Problem

Workloads can gain host, network, filesystem, or privilege escalation
capabilities that are unnecessary and dangerous in production.

## Context

Use this pattern for Kubernetes workloads, tenant namespaces, platform
services, controllers, and admission policies.

## Forces

- Some platform components need elevated privileges.
- Most product workloads should run with restricted settings.
- Exceptions must not become broad namespace bypasses.
- Developers need clear guidance for safe pod specs.

## Solution

Apply Kubernetes Pod Security baseline or restricted profiles with
admission enforcement, explicit exceptions, and tests for privileged
features such as host networking, hostPath, root users, and privilege
escalation.

## Verification

- Non-exempt workloads run as non-root and cannot escalate privileges.
- hostPath, host networking, and privileged mode are rejected by default.
- Exceptions are scoped, owned, and time bounded.
- Policy tests cover representative manifests.

## Related Patterns

- Secure Cluster Baseline.
- Policy-as-Code Admission Control.
- Namespace-per-Tenant.
- Network Default Deny.