Pod Security
Kubernetes controls that restrict what Pods can do at the OS level — capabilities, root access, host namespaces, and file system permissions.
What is Pod Security?
Pod Security encompasses the configuration controls that determine how much access a container's processes have to the underlying host OS and kernel. The key settings live in the Pod's securityContext (Pod-level) and each container's securityContext (container-level). Critical fields include: runAsNonRoot (prevents running as UID 0), runAsUser/runAsGroup (sets the UID/GID for all processes), readOnlyRootFilesystem (prevents writing to the container filesystem), allowPrivilegeEscalation (prevents setuid binaries), and capabilities (drops or adds Linux capabilities like NET_ADMIN or SYS_PTRACE).
Kubernetes 1.25 deprecated PodSecurityPolicy (PSP) and replaced it with Pod Security Admission (PSA), a built-in admission controller with three policy levels: Privileged (no restrictions), Baseline (prevents known privilege escalation paths), and Restricted (heavily restricted, suitable for security-sensitive workloads). PSA is enforced per-namespace via labels: pod-security.kubernetes.io/enforce: restricted.
HostPID, hostNetwork, and hostIPC are Pod-level settings that share the host's process namespace, network stack, or IPC namespace with containers — these are very powerful capabilities that should almost never be enabled for application workloads. DaemonSets for system agents sometimes legitimately need hostNetwork, but application Deployments with hostNetwork: true represent a serious misconfiguration.
Example
# Enforce restricted pod security on a namespace
kubectl label namespace production \
pod-security.kubernetes.io/enforce=restricted \
pod-security.kubernetes.io/warn=restricted
# A container spec with security hardening
containers:
- name: api
securityContext:
runAsNonRoot: true
runAsUser: 1000
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]Cost & Waste Implications
Containers running as root with privileged access and host namespace sharing can escape container isolation entirely, giving attackers full node access. A compromised privileged container on a node can access all Secrets on that node, schedule arbitrary workloads by modifying the kubelet config, mine cryptocurrency using the node's CPU and GPU, or pivot to other nodes and the control plane — all of which generate billable cloud costs and potentially exfiltration egress charges.
How KorPro Helps
KorPro scans Pod specs across all namespaces for privileged containers, root-running workloads, and hostNetwork/hostPID usage, surfacing security misconfigurations alongside cost and waste findings in a unified view.
Scan Your Cluster FreeRelated Terms
RBAC(RBAC)
SecurityRole-Based Access Control — Kubernetes's authorization mechanism that grants permissions through role bindings.
Read definitionServiceAccount
SecurityAn identity for Pods to authenticate to the Kubernetes API and cloud provider services, with tokens automatically mounted.
Read definitionNetworkPolicy
NetworkingA namespaced resource that defines firewall rules controlling which Pods can send and receive traffic.
Read definitionPod
Core ConceptsThe smallest deployable unit in Kubernetes — one or more containers that share a network namespace and storage volumes.
Read definitionStop Wasting Money on Orphaned Kubernetes Resources
KorPro connects to your clusters across GCP, AWS, and Azure — no agents, no installation — and surfaces every orphaned resource with its monthly cost estimate.