Kubernetes v1.37 storage hardening: bind mount options and emptyDir permissions

Kubernetes v1.37 storage hardening: bind mount options and emptyDir permissions

Kubernetes storage is one of the quietest attack paths in production clusters. It is also one of the least governed. Kubernetes v1.37 adds two controls that change that: emptyDir permission modes and bind mount options. The Kubernetes project shipped them in the v1.37 release blog on 2026-09-16, and they land right in the gap between “we set runAsNonRoot” and “we can stop a compromised pod from writing a runnable payload to a shared volume.”

The thesis for CTOs is simple. If you run multi-tenant clusters, or you run mixed-trust workloads, these features let you push storage policy down into the platform layer. That reduces the number of app teams who need to be security experts.

Kubernetes v1.37 storage hardening features: what changed

The Kubernetes v1.37 blog post describes two new primitives aimed at volume abuse and cross-container interference: emptyDir permission modes and bind mount options (Kubernetes Blog, 2026-09-16).

At a high level, Kubernetes.**

• This shared directory must not let one container delete another container’s files.
• This mount must behave like a hardened Linux mount, not a default bind mount.

That matters because most “pod security” programs focus on process controls, not storage controls. Attackers love storage because it persists across process restarts and it crosses container boundaries.

What these features are trying to prevent (as framed by the Kubernetes release post):

• Cross-container deletion and tampering on shared writable volumes.
• Execution of arbitrary binaries from writable volumes.
• Policy workarounds that force teams into sidecars, init containers, or custom admission logic.

The framing statement: Kubernetes.”

Why storage is the soft underbelly in Kubernetes

Shared volumes create cross-container trust you did not mean to grant

A pod is a trust boundary only if you treat it like one. Many teams do not.

Common pattern: a pod has two containers.

• Container A is the app.
• Container B is a helper, like a log shipper or a sidecar proxy.
• They share an emptyDir for logs, temp files, or generated config.

If either container gets popped, the attacker gets a writable path that the other container reads. That is a clean path to:

• Config injection (write a config file the app reloads).
• Data poisoning (write a cache entry the app trusts).
• Binary drop and exec (write a tool, then run it).

The Kubernetes blog calls out “prohibiting deletion of files across containers” and “execution of arbitrary binaries from writable volumes” as explicit goals (Kubernetes Blog, 2026-09-16). That is exactly the sidecar problem.

Most clusters still treat mount flags as an implementation detail

Teams set readOnlyRootFilesystem: true and feel good. Then they mount a writable volume at /tmp or /var/run and forget that Linux mount flags decide what can happen there.

If you do not set mount options, you often get:

• exec allowed on a writable mount
• device nodes allowed in some cases
• setuid semantics depending on the environment

Even if your container image is clean, a writable exec mount gives an attacker a place to stage tools.

How emptyDir permission modes change pod hardening

What emptyDir is used for in real systems

emptyDir is the default “scratch disk” for Kubernetes. Teams use it for:

• build artifacts in CI runners
• temp files for image processing
• shared sockets between containers
• log buffers
• downloaded model files or feature flags

It is also the volume type that shows up in the most places because it is easy and it does not need a storage class.

The security problem: permissions drift and cross-container file operations

In a multi-container pod, emptyDir becomes a shared filesystem. Linux permissions and ownership decide who can read, write, and delete.

The Kubernetes blog positions v1.37’s emptyDir permission modes as a way to implement stricter policies without “complicated circumvention” (Kubernetes Blog, 2026-09-16). That line matters. It signals that the project expects teams were doing hacks to get this behavior.

For CTOs, the key shift is governance. You can standardize how shared scratch space behaves across hundreds of workloads.

What to do with it as a platform team

Use emptyDir permission modes to make a few patterns safe by default:

• Sidecar log shipping: prevent the sidecar from deleting app logs.
• Init container staging: allow init to write, but stop runtime containers from mutating.
• Shared Unix socket directories: allow socket creation without turning the directory into a general purpose write target.

The catch is rollout. If you flip defaults too aggressively, you break workloads that relied on sloppy permissions.

How bind mount options reduce “writable and executable” volume risk

Bind mounts are everywhere, even when you do not call them that

Kubernetes mounts volumes into containers. Under the hood, that is a mount operation. The mount flags decide whether the filesystem allows execution, device nodes, and setuid behavior.

The Kubernetes blog calls out bind mount options as a new feature in v1.37 (Kubernetes Blog, 2026-09-16). The practical CTO angle is that you can now express “this mount must be noexec” as a platform policy, not as tribal knowledge.

The threat model: dropper tools and living-off-the-land

Attackers do not need to ship a full toolkit in the image. They can:

• write a binary into a writable mount
• chmod +x
• execute it

If you block exec on writable mounts, you force the attacker back into memory-only techniques. That raises the bar and improves detection.

This is also a supply chain story. A compromised dependency that writes an unexpected executable into /tmp becomes less useful.

Enterprise implications for CTOs

1. Multi-tenant clusters get a real storage policy layer. If you run shared clusters across teams, storage is a lateral movement path. v1.37 gives you controls that reduce tenant-to-tenant blast radius without rewriting apps.

2. Platform teams can standardize pod hardening beyond Pod Security. Pod Security Admission focuses on privilege and host access. Storage hardening fills a gap. It is a clean addition to your baseline workload profile.

3. Security teams can write fewer exceptions. The Kubernetes blog explicitly calls out avoiding “complicated circumvention” (Kubernetes Blog, 2026-09-16). That is a polite way of saying “people were doing weird stuff.” Fewer weird workarounds means fewer one-off risks.

4. Regulated environments get better evidence. Auditors ask how you prevent unauthorized code execution and tampering. “We mount writable volumes with noexec and restrict shared scratch permissions” is a crisp control statement.

CTO recommendations: how to roll this out without breaking production

Immediate actions

1. Inventory writable mounts. List every workload that mounts emptyDir, hostPath, or writable PVCs into common paths like /tmp, /var/tmp, /var/run, and app plugin directories.

2. Find shared-volume pods. Flag pods with 2+ containers that share a writable volume. Those pods have implicit trust links.

3. Pick one high-risk class to pilot. CI runners and build pods are good candidates. They write lots of files and often run untrusted code.

4. Add a canary policy. Apply the new settings to 5 to 10 services first. Measure crash loops, permission errors, and rollout time.

Policy framework

1. Baseline mount policy. Set a default rule: writable mounts are noexec unless a team proves they need exec. Treat “needs exec” like a security exception with an owner and an expiry date.

2. Shared volume policy. Set a default rule: shared writable volumes must block cross-container deletion unless the pod is a single trust unit.

3. Exception process. Require a short written reason, a ticket, and a review by platform security. Keep it lightweight, but real.

If you need a way to keep these decisions visible, the Security vs Velocity Tradeoff Framework is a good forcing function. It turns “this is annoying” into a risk tier and a conscious choice.

Architecture principles

1. Prefer single-container pods for mixed-trust components. If a sidecar is not the same trust level as the app, split it. Use a service boundary, not a shared filesystem.

2. Treat writable volumes as an attack surface. Design apps so they do not need to execute from writable paths. Put plugins in images, not in downloads.

3. Make storage controls part of your platform contract. Document what the platform guarantees. Then app teams stop guessing.

If you are already building an internal platform, this fits naturally with the idea that governance is part of the product. Our piece on Agentic AI governance becoming a control plane makes the same point in a different domain. Controls win when they are built into the runtime.

Bigger picture: Kubernetes.” That is the right direction. Admission can stop bad YAML. It cannot stop a compromised process from abusing a permissive mount.

World events push this trend too. Cross-border regulation keeps tightening around breach reporting and operational resilience, and boards now ask for controls that reduce blast radius, not just controls that look good in a policy doc. Storage hardening is a blast radius control.

The question is simple. If an attacker lands in one container, can they write something that changes what another container does?

Sources

1. Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions