Introduction

Preventing privileged containers is mainly an admission-control problem, not just an RBAC problem. RBAC decides who can create pods or workloads, but you also need policy that rejects manifests containing securityContext.privileged: true or other unsafe settings before they reach the cluster.

Understand What a Privileged Container Is

A privileged container gets elevated access to the host and kernel features that normal containers do not have. In practice, that greatly weakens container isolation and can make host compromise much easier.

A privileged pod spec typically looks like this:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: dangerous
5spec:
6  containers:
7    - name: shell
8      image: busybox
9      securityContext:
10        privileged: true
11      command: ["sh", "-c", "sleep 3600"]

If your cluster allows that manifest to be admitted freely, normal namespace boundaries may not protect the underlying nodes the way you expect.

Use Admission Policy to Block It

The right place to stop privileged containers is admission. In modern Kubernetes clusters, that usually means enforcing a restricted security policy at the namespace or cluster level, or using a policy engine that rejects privileged settings explicitly.

The security rule is conceptually simple:

• do not admit workloads with privileged: true
• also consider blocking related escalations such as dangerous capabilities, host namespaces, and unrestricted host path mounts

Preventing only one field can still leave other escape paths open.

RBAC Still Matters, But It Is Not Enough

RBAC can limit who is allowed to create pods, deployments, and daemonsets, and that is important. But if a user is allowed to create workloads at all, RBAC alone does not inspect the pod spec deeply enough to decide whether privileged: true is present.

So the practical defense is layered:

• RBAC limits who can submit workload objects
• admission policy validates what those workload objects are allowed to contain

You need both.

A Policy Engine Example

If you use a policy engine such as Gatekeeper or Kyverno, the idea is to deny any workload whose container security context asks for privileged mode. The exact policy syntax depends on the engine, but the intent is always the same: reject privileged containers before they are scheduled.

That is usually more maintainable than relying on human review of YAML or hoping namespace owners will avoid privileged settings voluntarily.

Cover All Workload Paths

Do not focus only on plain Pod objects. Users can create containers through many higher-level resources:

• Deployments
• StatefulSets
• Jobs
• CronJobs
• DaemonSets

Your policy has to cover the pod templates inside those workload types too. Otherwise users may be blocked when creating raw pods but still able to create privileged containers indirectly through a controller.

Audit and Test the Policy

Once the restriction exists, verify it with a realistic denied manifest and check the API response. Also review audit or admission logs so you can tell:

• who attempted the privileged workload
• which policy rejected it
• whether related unsafe settings are still slipping through

That feedback loop matters, because cluster security rules that are never tested tend to drift or develop blind spots.

Common Pitfalls

• Assuming RBAC alone can prevent privileged containers without an admission policy.
• Blocking raw Pod creation but forgetting workload controllers that embed pod templates.
• Denying only privileged: true while leaving other dangerous host-access settings uncontrolled.
• Applying a policy but never testing whether it actually rejects a real manifest.
• Treating privileged-container prevention as a one-time YAML task instead of part of ongoing cluster security posture.

Summary

• Preventing privileged containers is primarily an admission-control task.
• RBAC limits who can create workloads, but admission policy decides what those workloads are allowed to contain.
• Deny securityContext.privileged: true across pods and pod templates, not only one resource kind.
• Review related escape paths such as host access and dangerous capabilities too.
• Test the policy with real manifests so you know the cluster is actually enforcing the restriction.