Files
infospace-bench/infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-pod-security-baseline-restricted.md

45 lines
1.3 KiB
Markdown

# 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.