Privileged profile — when and how to allow full access

The privileged profile is the most permissive PSS profile — no restrictions. It allows every dangerous field (privileged: true, hostNetwork: true, hostPath, etc.) and is appropriate only for system workloads, operators that need kernel access, and debug sessions. Production workloads must not use it.

When privileged is appropriate

Three legitimate use cases:

1. System workloads. kube-proxy, CNI agents (Calico, Cilium), and storage drivers (CSI) need kernel access to do their jobs. They run in kube-system with enforce: privileged.
2. Privileged operators. Operators that manage the node (a node-level CSI driver, a GPU operator) need elevated capabilities. They run in dedicated namespaces with enforce: privileged.
3. Debug sessions. A one-off kubectl debug node/<node> session that needs to access the host filesystem. The session is short-lived and documented.

flowchart LR
    A[System workloads] --> B[enforce: privileged]
    C[Privileged operators] --> B
    D[Debug sessions] --> B
    E[Production workloads] --> F[enforce: restricted]
    G[Multi-tenant] --> H[enforce: baseline]

The namespace label

The privileged profile is enforced via the pod-security.kubernetes.io/enforce label:

apiVersion: v1
kind: Namespace
metadata:
  name: privileged-system
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/warn: privileged

A Pod in this namespace can use any field; the PodSecurity controller does not reject anything.

For comparison, a namespace with restricted:

apiVersion: v1
kind: Namespace
metadata:
  name: prod
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

A Pod with privileged: true in prod is rejected.

A privileged manifest

A Pod that requires privileged:

apiVersion: v1
kind: Pod
metadata:
  name: cni-agent
  namespace: kube-system  # privileged namespace
  labels:
    app: cni-agent
spec:
  hostNetwork: true          # privileged: allowed
  hostPID: true              # privileged: allowed
  containers:
  - name: cni
    image: cni:v1.0
    securityContext:
      privileged: true        # privileged: allowed
      capabilities:
        add: ["NET_ADMIN", "SYS_ADMIN"]  # privileged: allowed
    volumeMounts:
    - name: host-fs
      mountPath: /host
    - name: cni-config
      mountPath: /etc/cni
  volumes:
  - name: host-fs
    hostPath:
      path: /                  # privileged: allowed
  - name: cni-config
    configMap:
      name: cni-config

The Pod uses hostNetwork, hostPID, privileged, host capabilities, and hostPath. In a privileged namespace, the Pod is admitted. In a restricted namespace, it is rejected.

Operational discipline

The discipline of containing privileged workloads:

1. Document every privileged namespace. The team maintains a list of namespaces with enforce: privileged and the reason for each.
2. Restrict who can create in those namespaces. RBAC for kube-system is restricted to cluster-admin; production operators do not have write access.
3. Restrict who can change the namespace label. RBAC for the namespace update is restricted to cluster-admin.
4. Audit the namespace labels quarterly. A namespace that was restricted and is now privileged is a Critical finding.
5. Run kube-bench and PSS audits. The CIS Benchmark requires enforce: restricted on every user-facing namespace.

# Audit every namespace's PSS label
kubectl get ns -o json | \
  jq '.items[] | {name: .metadata.name, enforce: .metadata.labels["pod-security.kubernetes.io/enforce"]}'

A namespace without a PSS label is implicitly privileged (the absence of enforcement means no restrictions). The audit catches missing labels.

Production failure modes

1. A production namespace with enforce: privileged. A team added enforce: privileged to a production namespace to allow a legacy workload. The fix is to fix the workload and switch back to restricted.
2. A namespace with no PSS label. The namespace is implicitly privileged. The fix is to add the enforce: restricted label.
3. A privileged workload in a non-privileged namespace. A developer added privileged: true to a workload in prod; the workload is rejected. The fix is to remove the field, not to relax the namespace’s PSS.
4. The namespace label is changed in production. A misclick in the dashboard changes restricted to privileged. The fix is RBAC to restrict namespace updates to cluster-admin.

Cross-course references

• The Observability course covers the audit log entries for namespace label changes.
• The Linux course covers the kernel features (capabilities, namespaces) that privileged workloads bypass.

Quiz

Production discipline

The privileged profile is a controlled exception, not a default. A defensible PSS programme documents every namespace that uses privileged, restricts RBAC for namespace updates, audits the labels quarterly, and migrates privileged workloads to restricted as soon as possible. A cluster whose production namespaces are all restricted has a workload security programme that is auditable; a cluster whose namespaces are mostly privileged has a programme that is not.