Kubernetes pod security: implementing Pod Security Standards

Pod Security Standards: why pods get extra privileges

A typical picture in a cluster older than a year: manifests contain privileged: true or hostNetwork: true, the container runs as root, and hostPath mounts a node directory.

No one wrote this with malicious intent — the manifest was copied from someone else's example so it would "just work," and an extra kernel capability was added on advice from a forum. Then the file lives in the repository and is deployed on every release until someone notices it.

Why this isn't caught: by default nothing restricts it. The Kubernetes API server accepts any securityContext if admission controllers are not configured in the cluster, and the right to create pods in a namespace is granted to almost every service account.

Pod Security Standards exist as a set of profiles, but until they are enabled on a specific namespace, they remain a description of intent rather than a check at deployment time.

The cost of excessive container privileges is concrete. A privileged pod sees node devices and bypasses kernel isolation — compromising one container becomes compromising the entire node.

Running as root together with mounting a node directory or the container runtime socket opens a path to neighboring pods, and hostNetwork — to cloud network metadata. Medium-severity vulnerabilities turn into critical ones.

The flip side: strict profiles break legitimate workloads — metrics collectors, network agents, storage drivers.

So the question is not "prohibit everything" but "how to grant exactly the necessary rights without breaking releases." We break down how this is addressed.

What a managed pod security perimeter in a cluster provides

Before implementing policies, the share of privileged workloads is measured in single-digit percentages — and it is almost always exceptions that were forgotten.

After enabling Pod Security Standards in enforcement mode, such containers fail creation, and the share of privileged pods drops to zero without manually reviewing every manifest.

• Share of privileged pods — zero by default; an exception is documented explicitly and with a scope, not for the entire cluster.
• Privilege restriction: running as a non-privileged user, read-only root file system, no privilege escalation.
• Reduced attack surface: host paths, node network, and extra kernel capabilities leave the manifests — the most common path out of pod boundaries is closed.
• Time to validate a new deployment scenario — minutes: the policy denies at manifest apply, not a day later via a production incident.
• Manifest audit provides a log of violations and warnings: you can see which teams and services are not yet brought to the profile.
• Eliminated class of failures: container escape, reading secrets from a shared mount point, implicit node rights.

These measurements should not be taken once: the policy is tied to a namespace, manifests are checked before rollout, and exceptions live with a review date. Then the profile remains a working tool, not a document that is bypassed.

Comparison of Pod Security modes: baseline and restricted

Pod Security Standards has three policy levels, and choosing between them is choosing a workload class, not the principle "stricter means better." The privileged level imposes no restrictions: the pod gets access to host resources, so it is left only for system pods — network drivers, node monitoring agents.

baseline closes obviously dangerous things: host network namespaces and processes, running as root, extra capabilities. restricted adds requirements for the seccomp profile, read-only root file system, running as a non-privileged user, and explicitly dropping all capabilities.

Enabling levels immediately in enforcement mode is risky: warning mode returns a list of violations in the API server response and writes them to the audit log without blocking startup.

The team sees the real workload profile, fixes manifests, and only then moves the namespace to enforcement mode — first on new services, then on the rest.

How we implement policies: audit, design, validation, handover

Implementing Pod Security Standards is not a single label on a namespace. Policies expose what has accumulated in manifests over years: privileged containers, hostPath, hostNetwork, running as root, extra capabilities. So we go from inventory to soft mode and only then to blocking, with a rollback path at every step.

1. Cluster audit and manifest inventory. We collect workloads by namespace, including CronJob, DaemonSet, and operators, and record the user, privileges, and mounts for each. The result is a "workload → violated rules" table, not a generic stream of warnings.
2. Transition design. We classify workloads into three profiles — restricted, baseline, privileged — and decide which namespaces get blocking mode immediately and which go through soft mode.
3. Enabling in soft mode. We set audit and warning labels: the controller blocks nothing, but every violation goes into events and the log. A few days of this mode show the real volume of changes without risk to the production perimeter.
4. Configuration validation. We rewrite manifests for the required profile: remove extra capabilities, replace hostPath with volumes, set runAsNonRoot and seccomp. The changes go through review and a run in the test perimeter.
5. Workload transition. We enable blocking by namespace — from less critical to production, with monitoring for failures and a quick label rollback.
6. Handover of regulations. We hand over policies as code in the repository, rules for new services, a manifest review checklist, and the exception procedure.

Implementation artifacts: access policies, roles, and regulations

The customer's team receives not a set of one-off commands but a working kit that can be used for on-call duty and policy changes without us. Below is what specifically remains in the repository and the internal knowledge base after implementing Pod Security Standards.

• Cluster configurations: namespace manifests with pod-security.kubernetes.io/enforce, audit, and warn labels, selected baseline or restricted levels, and a separate exception list for system namespaces.
• Role matrix: a "namespace — policy level — who is allowed to move a workload out from under it" table, tied to access roles and separating the right to change policy from release rights.
• Workload placement designs: which workloads live in the strict profile and where privileges are needed — with the reason and owner indicated, not a "we'll figure it out later" note.
• Security regulations: the policy release procedure — first audit and warning modes on live traffic, then enabling enforcement mode according to a pre-agreed criterion based on the number of violations in the log.
• Instructions for the on-call shift: what to do when a pod is not created because of the policy — how to read the admission controller message, where to look for the exception, how to roll back the change without removing the entire mode.
• Documentation for developers: a reference manifest with required fields — running as non-root, seccomp profile, read-only root file system, dropped capabilities.

Each item has been tested on the customer's stand and tied to a specific namespace, so a new engineer gets up to speed from the document, not from a colleague's memory.

Case study: how privileged pods were removed without service downtime

Starting point

A cluster for several dozen teams: 46 namespaces, 11 of them with privileged pods — a network agent, log collection, node drivers. The Kubernetes audit showed that 88% of containers ran without a seccomp profile, and six out of ten workloads had allowPrivilegeEscalation: true.

There was no common policy: each namespace lived by its own rules, and any service could get a node directory mount.

Transition procedure

We started with warn and audit modes on all namespaces — within a week we collected a violation report and split them into three groups: manifest fixes, image replacements, system exceptions.

Then we enabled enforce in waves: first stateless services, then stateful sets with persistent volumes, and last the agents on every node, which cannot be interrupted without losing the node itself.

System workloads were moved to separate namespaces with the baseline level and a narrow allowlist by name. There was no downtime: the update went through gradual replica replacement with readiness checks, not a restart of the entire set.

Result

The practical outcome after two release cycles: zero privileged pods in production namespaces, and the share of containers without seccomp fell from 88% to 4%. Admission failures during rollout — zero after the first two weeks, once the teams got used to the new requirements.

Running as root and mounting node directories are closed, and a new service by default gets the restricted profile and does not require separate security approvals.

What to do if privileged pods are already deployed in the cluster?

Pod security policy was designed for a clean cluster, where manifests are written for a strict profile from the start. On a cluster with inherited workloads — old operators, vendor agents, metrics collectors — directly enabling a strict profile knocks out running services.

So the first step is not a ban but check modes without blocking: the controller lets everything through but records which pods diverge from the policy and by which rules.

Within a few days, such a run gives an exact list of violators and their owners — without a single incident. Then the policy is enabled not everywhere at once but by namespace: the label with the required profile is set on those whose manifests are already ready.

Exceptions are documented as exceptions within the policy itself, not as disabling the profile entirely.

An exception describes specific rules — mounting host directories, privilege escalation, additional kernel capabilities — and is tied to one namespace. Each entry gets a reason, owner, and review date.

In parallel, manifests are fixed: running as a non-privileged user, read-only root file system, dropping extra capabilities.

Workloads that cannot be fixed — a vendor image requiring privileges or device access — are moved to a separate namespace with a relaxed profile and kept there until the component is replaced. This is a visible, managed retreat zone, not a hole in the policy for the entire cluster.

The lifetime of a retreat is key. An exception without a review date becomes permanent, and six months later the strict policy exists only on paper.

We maintain an exception register and at each cycle show how many there are, which have expired, and what prevents closing the rest. Then the strict profile remains the default rule, and exceptions are targeted and visible.

Technical concerns of engineering teams: risks and compatibility

Before enabling, almost every team asks the same set of questions: will production go down, what to do with system components, and is there a way back. Below are the answers we give at the start and the procedure that removes the main implementation risks.

What about system components of the cluster?

Network and storage plugins, log collection, monitoring, and ingress controllers require privileges or node access.

For their namespaces we set explicit exceptions and a separate level instead of disabling the policy entirely — the rest of the cluster remains under the strict profile.

What most often fails validation in applications?

Privileged containers, mounting node directories, running as root, writing to the root file system, extra kernel capabilities. Some of it is closed by editing the security context in the manifest, and some by rebuilding the image for a non-privileged user.

Is it possible to roll back changes?

Yes: the level is set by a label on the namespace, and removing the label restores the previous behavior in seconds, without rebuilding the cluster.

The caveat is that rollback does not restore pods rejected by enforcement, so we move namespaces one at a time, with monitoring at every step.

Let's discuss the task: choose a mode and transition plan

To choose a Pod Security Standards mode and assemble an implementation design, an introductory snapshot of the cluster is enough: the number of namespaces, already applied labels, and the presence of privileged workloads. This is enough to provide a stage-by-stage estimate rather than estimating blindly.

What we need from you:

• a list of namespaces with owners and rollout order;
• a snapshot of current manifests or read-only access to the configuration;
• a list of workloads that need privileges, host ports, or volumes — with justification;
• a window when audit can be enabled and warnings reviewed without affecting production;
• an on-call engineer contact during the transition and information about the test perimeter.

What we provide in return:

• an implementation design: which policy level we set on which namespace and where we allow exceptions;
• a transition plan — first audit, then warnings, then enforcement, with a rollback point at every step;
• a stage-by-stage estimate of work with a note on what runs in parallel and what requires a window;
• exceptions as separate roles with scope and lifetime restrictions;
• a procedure for triaging alerts and a memo for development teams.

Describe the task in free form — we will discuss it and come back with an estimate and a transition plan tied to your maintenance windows.