A container looks like a sealed box, but the walls are only as strong as the settings you give it. A pod with the wrong settings can reach out and touch the machine underneath.

Containers are not tiny computers

A container is a package that holds a program and everything it needs. Many people imagine a container as a small, sealed computer. In truth, containers on the same machine share one core piece of software, called the kernel, which is the part of the operating system that controls memory, files, and devices. The container’s walls are built by asking the kernel to hide things from the program inside.

This means that the strength of the walls depends on how the container is configured. A container started with normal settings sees only its own files and processes. A container started with special power can see the machine’s files, look at other programs, and even take control of the machine. Once an attacker controls the machine, every other pod on it is in danger, and often the whole cluster.

What can go wrong

Most break-ins do not start with clever tricks. They start with a small mistake, such as a program with a flaw that lets an attacker run their own commands inside the container. If that container has few powers, the attacker is stuck in a small box. If it has many powers, the attacker can escape the box. Typical dangerous settings include running as the all-powerful root user, running in privileged mode, sharing the machine’s network or process space, and mounting the machine’s own folders into the pod.

The problem of doing it by hand

Teams may write security rules in a document and hope every developer follows them. But hundreds of pods are created by many people, and mistakes will happen. What is needed is a gatekeeper built into Kubernetes that checks every new pod against agreed rules and refuses the ones that break them. Pod Security Standards define the rules, and Pod Security Admission is that gatekeeper.

There are two separate things to learn. The standards say what is allowed. The admission controller decides whether a pod that arrives follows them.

Pod Security Standards

Pod Security Standards, often shortened to PSS, are a set of three ready-made policies maintained by the Kubernetes project. Each policy is a list of things a pod may or may not do. The three policies are cumulative in strength, from wide open to tightly locked.

Pod Security Admission

An admission controller is a step inside the Kubernetes API server that looks at every request to create or change an object, after the person is identified and allowed, but before the object is saved. It can accept, change, or reject the request. Pod Security Admission, or PSA, is an admission controller built into Kubernetes that checks pods against the standards. You turn it on for a namespace by adding labels. A namespace is a named area inside the cluster that groups related things.

flowchart LR
    U["Person or program creates a pod"] --> API["API server"]
    API --> AUTH["Who are you, and may you do this?"]
    AUTH --> PSA["Pod Security Admission checks the namespace level"]
    PSA -->|"Follows the level"| SAVE["Pod saved and started"]
    PSA -->|"Breaks the level"| NO["Request refused with a clear reason"]
        

Read the figure from left to right. A request to create a pod reaches the API server. The server first checks who the caller is and whether they may do this. Then Pod Security Admission looks at the level chosen for that namespace. If the pod follows the level, it is saved and started. If not, the request is refused and the reason is shown.

What replaced what

Older clusters used a feature called PodSecurityPolicy for this purpose. It was powerful but confusing, and it was removed from Kubernetes in version 1.25. Pod Security Admission is its simpler replacement. It has fewer options, but it is easy to understand and comes built in, with no extra software to install.

A few ideas from Linux and Kubernetes appear everywhere in pod security. Learn them once and the rest becomes easy.

Pods, containers, and namespaces

A pod is the smallest thing Kubernetes runs. It holds one or more containers that share a network and storage. A Deployment is an object that keeps a chosen number of identical pods running. A namespace groups objects and lets you apply rules to the whole group. Pod Security Admission works at the namespace level: one namespace, one set of rules.

The root user

On Linux, every program runs as some user. The user called root is all-powerful: it can read any file, change any setting, and start or stop anything. Ordinary users have limited power. If a container runs as root, and an attacker takes control of the program inside, the attacker also acts as root inside that container, which makes escaping far easier. Running as a normal user is one of the simplest and most effective protections.

Capabilities

Linux splits the power of root into many small pieces called capabilities. One capability lets a program change the system clock. Another lets it open network ports below a certain number. Another lets it change file owners. A program can hold only the pieces it needs. Containers start with a modest default set, and pod security rules often say to drop all of them and add back only a few.

Privileged mode and host sharing

A privileged container is one that has nearly all the power of the machine itself. It can see the machine’s devices and change its settings. Separately, a pod can ask to share parts of the machine: its network, its process list, or its inter-process communication area. Each of these breaks a wall that is normally kept in place.

Seccomp, AppArmor, and SELinux

Programs ask the kernel to do things through a menu of requests called system calls. Seccomp is a filter that lets a container use only a safe part of that menu, blocking rare and dangerous requests. AppArmor and SELinux are two other systems that limit what a program may touch, based on rules. Together they act as extra locks on the container’s doors.

The security context

In Kubernetes, the settings that control these powers live in a part of the pod description called the security context. It can be set for the whole pod and also for each container. It says which user to run as, whether to allow gaining extra power, which capabilities to keep, and which seccomp filter to use. Pod Security Standards are, in effect, rules about what the security context and a few other fields may contain.

Each level has a clear purpose. Choosing the right one for each namespace is the most important decision in the whole subject.

Privileged: no fences

The Privileged level allows everything. It exists because some parts of a cluster genuinely need deep access. A network plugin must change the machine’s network. A storage driver must mount disks. A monitoring agent may need to read machine-level information. These are trusted components installed by administrators, and they typically live in system namespaces. Nothing else should use this level.

Baseline: stop the obvious dangers

The Baseline level blocks known ways for a pod to escalate its power, while allowing most applications to run with no changes. It forbids privileged containers, sharing the host’s network, process, or communication areas, mounting the machine’s folders, using host ports, and adding risky capabilities. It also blocks unsafe kernel settings and unconfined system-call filters, and restricts certain access-control settings. An application that runs as root can still pass Baseline, because the aim here is to be easy to adopt.

Restricted: current good practice

The Restricted level includes everything in Baseline and adds hardening. Containers must run as a non-root user, must not be able to gain extra power, must drop all capabilities, except that one for binding low network ports may be added, and must use a safe system-call filter. Only a limited list of volume types is allowed. Many modern applications can meet these rules with small changes, but some old ones cannot without work.

flowchart TD
    P["Privileged: everything allowed"] --> B["Baseline: blocks known escalations"]
    B --> R["Restricted: hardened good practice"]
    P -.->|"for trusted system parts"| S1["Network plugins, storage drivers"]
    B -.->|"for most ordinary applications"| S2["Typical web apps and services"]
    R -.->|"for sensitive or public-facing workloads"| S3["Payments, identity, internet-facing apps"]
        

Why only three

The Kubernetes project chose to keep the standards few and simple, because too many choices make security confusing and easy to get wrong. If you need finer control, such as allowing one specific capability for one specific application, you can add another policy tool alongside. We discuss those later.

The standards are made of individual controls. Here is what each one protects against, using everyday language.

Sharing the host

Normally, each pod sees only its own network, its own processes, and its own files. Sharing the host’s network means the pod can see all traffic on the machine and reach services that were meant to be private. Sharing the host’s process list means the pod can see, and sometimes interfere with, every program on the machine. These options exist for tools such as monitoring agents, but they should never be given to ordinary applications.

Mounting the machine’s folders

A hostPath volume connects a folder on the machine to the inside of a pod. It is convenient for tests, but it is dangerous. If the pod can write into the machine’s folders, it might replace important files or read secrets that belong to other pods. In one well-known trick, a pod mounts the machine’s root folder and then has full control of the machine.

Running as non-root, and gaining power

Two Restricted controls work as a pair. The first says the program must run as a normal user. The second says the program may not gain more power than it started with. Some programs use special files that grant extra power when run. Blocking this closes a door that attackers often try.

What the standards do not cover

Pod Security Standards do not scan images for known flaws, do not limit who can talk to whom on the network, do not control who may use the Kubernetes API, and do not watch programs while they run. Those jobs belong to other tools, and a strong setup uses several together. We look at this in the security chapter.

You choose a level for a namespace by adding labels. Each label picks a level and a mode, and the mode says what happens when a pod breaks the rules.

Three modes

How labels are named

Each mode has its own namespace label. The label names begin with pod-security.kubernetes.io followed by a slash and the mode, which is enforce, audit, or warn. The value of the label is the level: privileged, baseline, or restricted. For example, a namespace labelled with enforce set to baseline will refuse pods that break Baseline.

Each mode can also have a version label, which pins the rules to a particular Kubernetes version, or to the word latest. Pinning is useful, because the standards grow slowly over time. If you pin to a version, your rules stay exactly the same when the cluster is upgraded. If you use latest, the rules follow the newest definition.

Mixing modes

The three modes are independent, so you can set different levels for each. A very common pattern is to enforce Baseline, while auditing and warning at Restricted. That way, nothing dangerous gets in, and teams also learn early which of their workloads would fail the stricter level, without anything breaking.

Cluster-wide defaults and exemptions

Besides namespace labels, an administrator can set defaults for the whole cluster, through the configuration of the admission controller. They can also list exemptions: users, runtime classes, or namespaces that the controller should skip entirely. Exemptions are sometimes needed for system components, but every one weakens the protection, so keep the list very short and review it often.

To use Pod Security Admission well, it helps to know exactly where it stands in the path of a request and what pieces are involved.

The path of a request

Everything in Kubernetes goes through the API server, the front door of the cluster. When someone asks to create an object, the request passes through several stages in a fixed order. First comes authentication, which asks who the caller is. Then authorization, which asks whether this caller may do this action. Then admission, which is a series of checkpoints that may change or refuse the request. Finally, the object is saved.

Admission has two kinds of checkpoints. Mutating ones may change the request, such as adding default settings. Validating ones only accept or refuse. Pod Security Admission is a validating checkpoint. It never changes a pod. It only says yes or no, and it sees the pod after any mutating checkpoints have made their changes.

flowchart TD
    REQ["Request to create a pod"] --> AN["Authentication: who is this?"]
    AN --> AZ["Authorization: is this person allowed?"]
    AZ --> MUT["Mutating admission: defaults and changes"]
    MUT --> VAL["Validating admission"]
    VAL --> PSA["Pod Security Admission"]
    VAL --> OTHER["Other policy checks"]
    PSA --> DEC{"All checks pass?"}
    OTHER --> DEC
    DEC -->|"Yes"| STORE["Saved in the cluster store"]
    DEC -->|"No"| REJ["Refused with reason"]
        

In the figure, notice that Pod Security Admission is one of several validating checks. Other policy tools sit at the same stage. If any of them says no, the pod is refused. This is why you can safely combine PSA with other tools.

The pieces involved

Built in, so no extra install

Pod Security Admission is part of the API server, turned on by default in current versions of Kubernetes. That is a great advantage: no extra programs to run, no extra network calls, and very little added delay. The trade-off is that it offers only the three fixed levels. It cannot express custom rules.

Let us follow a real deployment and see when the check happens, and why sometimes you see a warning but no refusal.

Checking pods, not Deployments

Most people do not create pods directly. They create a Deployment, which then creates a ReplicaSet, which then creates pods. The important detail is that enforcement happens when the pod itself is created, not when the Deployment is created. So a Deployment with a risky template is accepted and saved. Only when its controller tries to make the pods does the gatekeeper refuse them.

That could confuse a team: the Deployment exists, but no pods appear. To help, audit and warn modes also check the pod template inside Deployments and similar objects at the time they are created. So the developer sees a warning when applying the Deployment, even though enforcement, if enabled, will still happen later at the pod stage.

sequenceDiagram
    participant D as Developer
    participant API as API server
    participant PSA as Pod Security Admission
    participant RS as ReplicaSet controller
    D->>API: Create Deployment
    API->>PSA: Check pod template in warn and audit modes
    PSA-->>API: Warning: template breaks Restricted
    API-->>D: Deployment saved, warning shown
    RS->>API: Create pod from template
    API->>PSA: Check pod in enforce mode
    PSA-->>API: Refuse: pod runs as root
    API-->>RS: Pod rejected
    RS->>API: Record failure event on ReplicaSet
        

Read the figure from top to bottom. The developer creates a Deployment and instantly gets a warning. The Deployment is saved. Later, the ReplicaSet controller tries to create a pod, and the enforce check refuses it. The reason is recorded as an event on the ReplicaSet, not on the Deployment. Looking at the events on the ReplicaSet is the place to find why no pods are running.

How the decision is made

For each pod, the plugin reads the namespace labels and works out the level and version for each mode. It then evaluates the pod against each control in that level. If any control is broken, the pod fails for that mode. The checks are done against every container, including init containers, which run before the main ones, and ephemeral containers, which are temporary ones added for debugging.

The plugin also has a cache and a set of shortcuts. If the level is privileged, no checks are needed. Exempt users and namespaces are skipped. Certain updates to a running pod are ignored, so that changing a harmless field on a pod that already exists does not suddenly cause a refusal.

What the messages look like

When a pod is refused, the message names the level, the control that was broken, and the container. For example, it may say that a container must not run as root, or that the system-call filter must be set. A message can list several problems at once. Reading these messages carefully is the fastest way to fix a workload, because they tell you exactly what to change.

Turning on strict rules all at once can break running applications. A careful, step-by-step approach avoids nasty surprises.

The gentle path

The safest way is to learn first, then fix, then enforce. Start with the warn and audit modes, which never refuse anything. Collect the results, repair the workloads that would fail, and only then switch on enforcement. At each step, tell the teams what is coming, and give them time.

flowchart LR
    A["1. List namespaces and their owners"] --> B["2. Turn on warn and audit at target level"]
    B --> C["3. Review warnings and audit notes"]
    C --> D["4. Fix workloads or choose a lower level"]
    D --> E["5. Dry-run the enforce label"]
    E --> F["6. Turn on enforce"]
    F --> G["7. Keep audit and warn on for the next level"]
        

The dry run

Kubernetes lets you preview the effect of an enforce label. When you apply the label with a server-side dry-run option, the system checks every running pod in the namespace against the new level and reports warnings for those that would not pass, without changing anything. This is the single most useful tool before turning on enforcement, because it tells you exactly what would break.

From the moment someone applies a label to the day a pod is refused or recorded, here is the whole life of one policy.

What happens during upgrades

When Kubernetes is upgraded, the definitions of the standards may be refined. If a namespace label uses latest, the new definition applies at once, and pods that used to pass might start to fail. If the label pins a version, the old definition keeps applying. Pinning gives control, but you must remember to update the pin from time to time, or you will fall behind current good practice.

What happens to a pod that changes

Most updates to a running pod are not related to security, such as changing a label or an annotation. The plugin knows this, and does not re-check them, so that unrelated changes are not blocked. Updates to fields that matter for security, such as the image or the security context, are checked again.

Most applications can meet the Restricted level with a handful of changes. Here is what those changes are, in plain words.

The usual list of fixes

Ports below 1024

Many old programs listen on port 80 or 443. Ports below 1024 were traditionally reserved for root. Under the Restricted level, the simplest solution is to have the program listen on a higher port, such as 8080, and let the Kubernetes Service map the familiar port to it. Only if that is not possible should the low-port capability be added.

Init containers and sidecars

The rules apply to every container in the pod, not only the main one. Init containers that run first, and helper sidecars, must follow the same rules. A common surprise is a helper injected by a service mesh or a security tool, which may itself need special power. Such tools often offer a safer mode, which should be used, or they need to live in a namespace with a lower level.

Third-party charts and vendor software

Software from vendors and public packages may not be written for Restricted. Before installing it into a hardened namespace, look at its settings. Many packages have options to run as non-root and to drop capabilities. If they do not, ask the vendor, or run them in a separate namespace with Baseline, and record the reason.

Pod Security Standards are strong, but only when the ways around them are also closed. Here are the questions of who may change the rules, and what else must be layered on.

Who can change the labels

The labels that control pod security live on the namespace. Anyone who is allowed to edit a namespace can weaken its rules by changing the labels. This is a common gap. Use role-based access control, or RBAC, the Kubernetes system that decides who can do what, so that only cluster administrators can change namespaces and their labels. Ordinary developers should be able to create pods in their namespace, but not edit the namespace itself.

Layers of defence

No single control stops every attack. A strong setup layers several, so that a failure of one does not lead to a disaster. Pod Security Standards handle what pods may ask for. Other layers handle images, network paths, permissions, secrets, and what happens at run time.

Service accounts and tokens

A service account is an identity that a pod uses to talk to the Kubernetes API. If a pod does not need to talk to the API, do not mount its token. If it does, give it a role with only the permissions it needs. A hardened pod with an all-powerful token is still dangerous, because an attacker inside can use the token to control the cluster from within.

Extra locks: read-only file systems and more

Some good practices go beyond the standards. A read-only root file system stops attackers from writing new programs into the container. Resource limits stop one pod from starving others. Avoiding automatic mounting of tokens reduces exposure. These are not required by the Restricted level, but they fit well beside it.

Pod Security Admission is deliberately simple. That simplicity is both its greatest strength and its main limit.

Comparing with the alternatives

How the two are often combined

A common approach is to use Pod Security Admission as the baseline for every namespace, since it is free and always on. Then a policy engine adds rules for things the standards do not cover, such as requiring resource limits, allowing only images from your own registry, or requiring certain labels. The two work side by side at the same admission stage.

Patterns are arrangements that teams have found to work. Anti-patterns are habits that look convenient but cause trouble.

Helpful patterns

Anti-patterns to avoid

A short list of habits that make the standards work in practice, and the mistakes that most often trip teams up.

Best practices

Common mistakes

A gentle start plan

In week one, list the namespaces and set a cluster default of Baseline in warn and audit modes. In week two, review the warnings and fix the easy ones. In week three, dry-run enforce for Baseline on application namespaces, and turn it on. In the following weeks, move the most sensitive namespaces to warn and audit at Restricted, fix what appears, and then enforce. Keep going until the system namespaces are the only exceptions.

A rule you cannot see working is a rule you cannot trust. Here is how to watch pod security and how to fix the usual problems.

Where the signals appear

What to track

Alerts worth having

Alert when a pod security label on a namespace is changed or removed. Alert when a new namespace appears with no level set. Alert when refusals rise suddenly in a production namespace. Alert when a workload is created in a privileged namespace by someone who is not an administrator. These alerts catch both accidents and attempts to weaken the protection.

Troubleshooting the usual problems

Emergency path

If enforcement blocks something urgent, the quickest safe action is to change the mode on that one namespace from enforce to warn, fix the workload, and turn enforce back on. Record that you did it and why. Do not remove protections across the whole cluster to fix a single workload.

Three short stories show the ideas in action. The details are typical rather than taken from any one company.

Example 1: The friendly first step

Example 2: The stubborn old application

Example 3: The monitoring agent that needed power

What the stories share

Each team learned first, using warnings and audit notes. Each fixed workloads instead of lowering the rules. And each placed the few workloads that truly needed deep access into a small, well-guarded place. Security improved without stopping the business.

Short answers to questions that beginners often ask.

The standards are the rules: three levels called Privileged, Baseline, and Restricted. The admission controller is the built-in gatekeeper that checks pods against those rules, according to labels on the namespace.

It was deprecated and then removed in Kubernetes version 1.25. Pod Security Admission is its built-in, simpler replacement. Teams needing more custom rules use policy engines or validating admission policies alongside it.

Use Privileged only for trusted system components. Use Baseline as a sensible default for ordinary applications. Use Restricted for sensitive or public-facing workloads, and aim to move more namespaces there over time.

Enforcement happens at pod creation. The Deployment is saved, but its pods are refused. Look at the events on the ReplicaSet to find the reason.

No. Existing pods keep running. The new level only affects pods that are created or updated later. Restart workloads to bring them under the new rules.

Use warn and audit modes first, then apply the enforce label with a server-side dry run, which reports which existing pods would fail without changing anything.

Pinning gives predictable behaviour across upgrades but needs occasional updating. Latest keeps up with the newest definition but may change results after an upgrade. Many teams pin in production and use latest in test.

No. It offers only the three fixed levels. For custom rules, use validating admission policies or a policy engine, which can run alongside it.

It greatly reduces one kind of risk, but it does not cover image flaws, network paths, permissions, secrets, or run-time attacks. Use it as one layer among several.

They often need Privileged access. Keep them in dedicated system namespaces at the Privileged level, managed only by administrators, and keep ordinary applications elsewhere.

Only cluster administrators. Use RBAC to prevent developers from editing namespaces, keep labels in version control, and alert on changes.

Set warn and audit at Baseline for all application namespaces, review the results, fix the workloads, then enforce Baseline. After that, repeat the process for Restricted on your most sensitive namespaces.

A last look at the whole picture, in plain words.

A Kubernetes cluster is a shared building, and pods are its tenants. Because containers share the machine’s kernel, a pod with too much power can harm every other tenant. Pod Security Standards are the house rules that say how much power a pod may have, and they come in three levels: Privileged for trusted system parts, Baseline for ordinary applications, and Restricted for hardened workloads.

Pod Security Admission is the built-in gatekeeper that checks pods against those levels. You choose a level and a mode for each namespace using labels. Enforce refuses, audit records, and warn tells the person straight away. A gentle rollout uses audit and warn first, fixes workloads, tests with a dry run, and only then enforces.

The standards are simple and strong, but they are not everything. Guard the labels with RBAC, keep exemptions few, and combine the standards with image scanning, network rules, careful permissions, and run-time monitoring. Watch the warnings and audit notes, and keep raising the bar step by step.