Kubernetes Security Context Audit

Kubernetes Security Context Audit: Five Flags Worth Checking

Secrets are not the only dangerous thing in a manifest. Five configuration flags decide how much damage a compromised container can do, and every one of them is easy to set carelessly and hard to notice in review. The Cloud Config Sanitizer audits them alongside its secret detection: privileged: true, hostNetwork: true, and hostPID: true are flagged wherever they appear, and a securityContext that omits readOnlyRootFilesystem or runAsNonRoot draws an absent marker. Each of these findings arrives at info severity, deliberately below the credential findings, because the right response is a deliberate decision rather than automatic redaction. Kubernetes documents the same concerns in its Pod Security Standards, where the baseline and restricted profiles exist precisely to rule these settings out by default.¹

A reviewer skimming a pull request rarely spots a missing field, yet a missing field is exactly what turns an ordinary container escape into full node compromise.²

The three escape hatches: privileged, hostNetwork, hostPID

Privileged mode is the bluntest of the three. A container with privileged: true runs with essentially the node's full capabilities, able to mount host filesystems, load kernel modules, and step outside its namespace, while hostPID: true lets processes in the container see and signal every process on the node, turning process inspection into an attack surface.³ hostNetwork: true shares the node's network namespace, exposing localhost-bound node services to the pod and letting it bind node ports directly.² The baseline profile of the Pod Security Standards forbids all three outright.¹

When these flags need a documented reason

None of the three is inherently wrong to set; the failure mode is setting one without anyone being able to say why. Consequently, any of these flags in a manifest should map to a documented reason, typically a CNI plugin, node agent, or monitoring daemon; a web application with one of them set is a finding worth escalating past info in your own review.

Combining two of the three flags on the same pod, which some copied examples do without needing to, compounds the blast radius well beyond what either flag grants alone. Reviewing manifests for that pattern specifically, rather than treating each flag as an isolated checkbox, catches the riskiest combinations before they ship.

The two hardening defaults: read-only root and non-root user

Absence is the finding here. When a securityContext block exists but readOnlyRootFilesystem is unset or false, an attacker with code execution inside the container can write to the container filesystem, drop tools, and modify binaries; setting it true forces all writes through explicit volume mounts you chose. Similarly, an unset or false runAsNonRoot leaves the container free to run as root, so a container-runtime vulnerability escalates further than it needed to.⁴ The sanitizer flags both conditions with an absent marker at the exact path where the field belongs.

An empty findings list is not a clean bill of health

That distinction trips up more reviews than the flags themselves do, since a quiet audit output reads as reassuring when it is really just uninformative. One honest subtlety: the absent checks run on securityContext blocks the manifest actually contains, so a pod with no securityContext at all yields no such findings.

Reading zero flags as a clean audit is therefore wrong; it may mean nothing was declared. Adding an explicit securityContext block, even a minimal one, is the precondition for either hardening check to ever fire in the first place. Treat a clean scan as a prompt to check the manifest's structure rather than proof the workload is already hardened.

Running the audit and acting on info findings

Paste any manifest in, and the findings table surfaces privileged, hostNetwork, and hostPID wherever they appear, the same way it lets you check for privileged mode in a borrowed Helm chart; it also catches a securityContext block that never set readOnlyRootFilesystem, flagged at the exact path where the field belongs.

Info severity means the sanitized output leaves these values unchanged; a boolean cannot be redacted into a placeholder without changing behavior, so the tool surfaces rather than rewrites. Work the list in two passes: first confirm each escape-hatch flag has a justification, then add the missing hardening fields with explicit true values. Building on this, namespaces enforcing the restricted profile will reject regressions at admission time instead of relying on the next manual audit to catch them.⁵ Pairing the scan with admission enforcement turns a one-time cleanup into a standing guarantee that new manifests cannot quietly regress past it.

Two passes, run in a fixed order

Working the list in two passes keeps the audit from turning into an unfocused scroll through findings: confirm each escape-hatch flag against a real justification first, then add the missing hardening fields with explicit true values afterward. Treating both passes as separate steps keeps a legitimate hostNetwork daemon from being lumped in with a securityContext block that just needs two more lines.

Pod Security Admission is what turns this from a one-time audit into a standing guarantee, since a namespace enforcing the restricted profile rejects a regression at admission time rather than waiting for the next manual pass to catch it.⁵ Pairing the scan here with that enforcement is what keeps a hardened manifest hardened.

When to use this

Run this audit before promoting a manifest to a shared or production namespace, when reviewing third-party charts and examples copied from documentation, and during periodic hardening passes over existing workloads. It pairs naturally with secret scanning on the same paste, so one check covers both what the manifest leaks and what it permits. Teams introducing Pod Security Admission for the first time can also use it to preview which existing manifests would fail the restricted profile before enforcement is switched on.

Examples

securityContext:
  fsGroup: 2000

securityContext:
  fsGroup: 2000
  runAsNonRoot: true
  readOnlyRootFilesystem: true