Kubernetes Pod Security Standards Checklist

Overview

If you run Kubernetes long enough, pod security becomes less of a one-time policy decision and more of an operating habit. New workloads arrive, old charts linger, cluster versions change, admission settings tighten, and teams inherit manifests they did not write. A durable kubernetes pod security standards review process helps prevent that drift.

At a practical level, Pod Security Standards are usually discussed in three tiers: Privileged, Baseline, and Restricted. For most teams, the real day-to-day work is deciding whether a namespace should meet kubernetes baseline policy controls or the stricter kubernetes restricted policy controls, then making sure manifests, Helm values, generated jobs, and sidecars actually comply.

This article is intentionally written as a working pod security checklist, not a theory piece. Use it before shipping a new service, before enabling stricter pod security admission settings, during migration from older admission approaches, and during periodic compliance reviews.

A useful mindset is to treat Baseline as the minimum for general-purpose application workloads and Restricted as the target for workloads that do not have a strong reason to be more permissive. If you need exceptions, document them explicitly and make them visible. Quiet exceptions are usually where security posture weakens over time.

Before you start the checklist, clarify four things:

• Scope: Which namespaces and workload types are in scope: Deployments, Jobs, CronJobs, StatefulSets, DaemonSets, or all of them?
• Enforcement model: Are you validating, warning, auditing, or enforcing?
• Ownership: Who fixes noncompliant manifests: the app team, the platform team, or chart owners?
• Exception process: How are exceptions approved, tracked, and retired?

That foundation matters because the same manifest can be acceptable in a temporary migration namespace and unacceptable in a shared production namespace.

Checklist by scenario

Use this section as a scenario-based review before rollout. The goal is to move from broad policy intent to concrete fields in workload specs.

Scenario 1: Any new workload entering a Baseline namespace

This is the minimum pass for most teams. Before deployment, check the following:

• Do not run privileged containers unless there is a documented, reviewed exception.
• Avoid host namespace sharing such as host networking, host PID, or host IPC unless there is a specific operational need.
• Do not mount sensitive host paths casually. HostPath volumes are often a shortcut with a long-term security cost.
• Review Linux capabilities. Avoid adding capabilities unless the application has a clear requirement.
• Confirm seccomp is set appropriately where your cluster policy expects it.
• Do not allow broad privilege escalation settings by default.
• Inspect init containers and sidecars separately. Teams often validate only the main application container and miss generated or injected containers.
• Check Jobs and CronJobs in the same namespace. One compliant Deployment does not mean supporting automation is compliant too.

Baseline is often where legacy charts begin to fail review. Common causes include permissive defaults, unnecessary host mounts for logs or sockets, and copied examples that include elevated settings with no present-day need.

Scenario 2: A workload entering a Restricted namespace

Restricted review should be more deliberate. It is not just “Baseline plus one more setting.” It usually requires clean, explicit runtime configuration.

• Run as non-root and verify the image supports it in practice, not only in configuration.
• Set a non-root user or otherwise enforce non-root execution according to your standards.
• Set allowPrivilegeEscalation to false where expected.
• Drop unnecessary capabilities and keep the capability set minimal.
• Use a default seccomp profile or the profile required by your environment.
• Use read-only root filesystem if your application can support it, especially for stateless services.
• Restrict volume types to those allowed by your policy.
• Review writable paths and temporary storage needs so teams do not quietly reintroduce unsafe filesystem patterns.

Restricted is where image quality and application assumptions become visible. Older images often assume root access, package installation at startup, or write access to broad filesystem locations. Treat those failures as useful feedback about application hardening, not only as policy friction.

Scenario 3: Existing workloads during policy tightening

Many teams do not start with enforcement. They begin with audit or warn modes to measure blast radius. If that is your stage, review these items:

• Inventory noncompliant namespaces and sort by production criticality.
• Group failures by root cause such as root user, privilege escalation, hostPath, capabilities, or seccomp gaps.
• Separate platform-owned violations from app-owned violations. This avoids security reviews turning into routing confusion.
• Find generated manifests from CI/CD, operators, or Helm templates that bypass normal review habits.
• Test admission changes in a staging cluster with representative workloads.
• Communicate cutover dates so teams know when warnings become enforcement.

If your organization is also standardizing workflows, it can help to align this review with broader platform engineering practices and clear ownership boundaries. The same discipline that improves pod security often improves deployment reliability too.

Scenario 4: Third-party software, vendors, and operators

Third-party workloads are often the hardest part of a kubernetes security checklist because you do not fully control their manifests.

• Review vendor installation manifests line by line before applying them to shared clusters.
• Check whether operators spawn secondary pods with different security settings than the controller itself.
• Ask whether the vendor supports Restricted-compatible deployment or only Baseline-compatible deployment.
• Document namespace-specific exceptions instead of lowering policy globally.
• Revalidate after upgrades because vendor defaults can change without matching your internal standards.

If a third-party component truly needs elevated access, isolate it operationally and make that risk explicit. A hidden exception in a broad application namespace is harder to reason about than a well-documented isolated pattern.

Scenario 5: CI/CD and pre-deployment validation

A checklist is most useful when it runs before admission rejects a release. Add these controls to delivery workflows:

• Lint manifests in pull requests against your Baseline or Restricted expectations.
• Test rendered Helm output, not only chart source values.
• Validate Kustomize overlays for environment-specific differences.
• Block merges for known high-risk settings such as privileged mode or hostPath use in standard application namespaces.
• Store policy exceptions in version control so reviewers can see why they exist.

For teams already refining automation, it is often worth pairing pod security checks with your broader delivery reviews. For example, if GitHub Actions is part of your path to cluster changes, see GitHub Actions Pricing and Usage Limits Explained to keep policy validation practical within CI usage constraints.

What to double-check

This is the short list of issues that repeatedly cause confusion even when teams think they are compliant.

Container-level versus pod-level settings

Some controls live at the pod level, some at the container level, and some need consistency across all containers. Review every container block: main containers, init containers, and injected sidecars.

Namespace labels and enforcement mode

Make sure the namespace is labeled the way you think it is. A common operational mistake is testing in a namespace with warn or audit behavior, then assuming production will behave the same under enforcement.

Image behavior, not just manifest intent

A manifest may declare non-root execution, but the image may still fail at runtime because files are owned incorrectly or the process expects privileged ports or writable system paths. Validate running behavior, not only YAML fields.

Helm chart defaults

Many charts expose security settings but leave them permissive by default. Confirm your values files actually override those defaults across all environments.

Cluster version and policy behavior

Admission and security-related behavior can evolve across Kubernetes releases. Reconfirm assumptions during cluster upgrades, and keep compatibility in mind. For planning around upgrades, Kubernetes Version Skew Policy and Upgrade Matrix is a useful companion read.

Managed Kubernetes differences

If you operate across EKS, GKE, and AKS, validate whether your implementation details, policy tooling, and operational defaults differ enough to require platform-specific guidance. See AWS EKS vs GKE vs AKS: Managed Kubernetes Comparison by Use Case if your teams support multiple managed Kubernetes environments.

Related controls outside pod security

Pod Security Standards reduce risky pod configuration, but they do not replace identity, network, secret management, or cloud IAM review. For adjacent access risks, Cloud IAM Misconfigurations Checklist for AWS, Azure, and GCP is worth pairing with this checklist.

Common mistakes

The fastest way to improve adoption is to remove predictable friction. These are the mistakes that most often slow teams down.

• Treating Baseline as complete security. Baseline reduces obvious risk, but it does not mean a workload is hardened enough for every environment.
• Applying Restricted everywhere in one step. That can work for greenfield platforms, but established clusters usually need staged remediation.
• Reviewing only application Deployments. Jobs, CronJobs, init containers, and operator-managed pods often cause the real failures.
• Ignoring exceptions until release day. Security exceptions should be reviewed before rollout windows, not during incidents or deployment freezes.
• Relying on tribal knowledge. If policy rules live only in one engineer’s memory, they will drift.
• Forgetting platform-owned components. Service meshes, log agents, backup tools, and node-level agents may need separate treatment.
• Failing to align policy with developer workflow. If the first time a team learns about Restricted is when admission blocks production, the rollout process needs work.

In regulated or higher-assurance environments, these mistakes can also become governance issues because exceptions and ownership boundaries are not visible enough. If that is a concern, articles such as One Team: Cross-functional Frameworks for DevOps in Highly Regulated Organizations and Balancing Speed and Safety: A Roadmap for Cloud Adoption in Pharma and Biotech can help frame the operating model around the technical controls.

When to revisit

This checklist is most valuable when reused at predictable moments. Revisit it when any of the following happens:

• Before seasonal planning cycles when platform teams are setting upgrade, compliance, or reliability priorities.
• When workflows or tools change, especially new Helm charts, operators, CI/CD templates, or internal developer platform abstractions.
• Before enabling stricter admission settings in shared or production namespaces.
• After a cluster upgrade or when reviewing version support and policy behavior.
• When onboarding a vendor product or expanding use of a third-party operator.
• After incidents or near misses involving excessive privileges, unexpected host access, or runtime hardening gaps.
• During platform standardization work when teams are building reusable service templates.

To make this practical, turn the checklist into a recurring operating routine:

1. Pick a default target per namespace class. For example: shared app namespaces aim for Restricted unless an exception is approved.
2. Publish a short internal standard. Include allowed defaults, common exceptions, and example manifests that pass review.
3. Add policy checks to pull requests and release workflows. Catch issues before they become blocked deployments.
4. Track exceptions with expiry dates. An exception without a review date tends to become permanent.
5. Review drift quarterly. Compare live workload settings against your intended baseline.

That final step matters most. The best pod security admission program is not the one with the strictest language; it is the one teams can sustain across upgrades, handoffs, and changing application portfolios. Use Baseline and Restricted as living guardrails, keep exceptions visible, and come back to this checklist whenever your platform changes shape.