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

Why Container Storage Security Has Been a Persistent Blind Spot

Kubernetes v1.37 storage security gets a meaningful upgrade with two Alpha features that close a long-standing gap in container hardening: configurable bind mount options and emptyDir permission modes. If you've ever audited a Kubernetes cluster and winced at writable volumes managed security services{rel="nofollow noopener"} with no execution controls, or struggled to explain to a compliance team why your /tmp directories don't enforce the sticky bit — this release is for you.

These aren't cosmetic changes. They address real CVE-adjacent findings, including a specific call-out in the Kubernetes 1.24 security audit (NCC-E003660-7HM), and they give security engineers a native, declarative way to enforce storage controls that previously required init container workarounds or external admission controllers.

Let me walk you through the Linux fundamentals, the security motivation, and exactly how to implement these controls in production workloads. (Read also: Reduce PDF File Size in Linux: Tools and Methods)

For a production-ready setup, check out VPS Server's cloud hosting plans. (Read also: The Complete Guide to Cloud Migration in 2026)

Linux Storage Primitives You Need to Understand First

Before we look at the Kubernetes API surface, it's worth grounding ourselves in the underlying OS mechanisms these features expose.

VFS Bind Mount Flags

When the container runtime bind-mounts a volume into a container, the Linux Virtual File System (VFS) layer accepts flags that constrain what's permitted on that mount point:

• noexec: Blocks direct execution of any binary on the mounted filesystem. Even if an attacker writes a malicious script and chmod +x's it, the kernel refuses to execute it.
• nosuid: Prevents setuid/setgid bits from taking effect. Critical for stopping privilege escalation via SUID binaries dropped onto writable volumes.
• nodev: Prevents interpretation of character or block device files on the filesystem. Limits a class of device-based escape techniques.

Prior to v1.37, Kubernetes provided no mechanism to set these flags on the bind mount the container runtime creates. PersistentVolumes have a mountOptions field, but those flags are applied at the storage layer by the CSI driver — they don't reliably propagate to the bind mount inside the container namespace. That distinction matters enormously.

Unix Permissions and the Sticky Bit

Standard Unix permission modes (0755, 0750, 0777) control read, write, and execute access across owner, group, and others. The sticky bit — represented as 01777 — adds a critical constraint to shared directories: only the file's owner or root can delete or rename files within that directory, regardless of the directory's write permissions.

This is why /tmp on every Linux system runs with mode 01777. Without it, any process with write access to the directory can delete any file in it, regardless of who owns that file. In multi-container pods sharing an emptyDir, this is a real threat model.

The Security Gaps These Features Close

Here's the uncomfortable truth: until v1.37, a container with readOnlyRootFilesystem: true was not as hardened as most teams assumed. A compromised process could:

1. Write a malicious binary to any writable emptyDir volume
2. Execute chmod +x on it
3. Run it — because the bind mount had no noexec enforcement

The read-only root filesystem provides no protection against execution from mounted volumes. This gap was formally documented in Issue #48912 and later elevated to a finding in the official Kubernetes security audit.

The emptyDir permission problem is equally concrete. By default, emptyDir volumes are created with mode 0777 — world-readable, world-writable, world-executable. In a multi-container pod, every sidecar has full access to every other container's files in that shared volume. There's no native way to restrict this without an init container running chmod, which adds operational complexity and is difficult to enforce consistently at scale.

For teams running workloads subject to CIS Kubernetes Benchmarks, NIST 800-190, or internal zero-trust policies, these gaps represent real compliance failures — not theoretical risks.

Implementing Bind Mount Options in Kubernetes v1.37

Feature Gate Requirements

Both features are Alpha in v1.37 and require explicit opt-in. Enable these feature gates on your API server and kubelet:

• VolumeBindMountOptions — for bind mount flag support
• EmptyDirVolumeMode — for emptyDir permission mode control

Your container runtime must also support the CRI mount_options field and advertise it via runtimeFeatures. The scheduler uses node-declared capabilities to avoid placing pods on incompatible nodes. If a pod lands on an incompatible node, the kubelet rejects it — there's no silent degradation, which is the correct behavior for security controls.

Hardening a Writable Volume with noexec and nosuid

The following manifest mounts an emptyDir at /tmp with execution and SUID protections enforced at the bind mount level. Note the pinned image version — never use latest in production, especially when hardening workloads.

apiVersion: v1
kind: Pod
metadata:
  name: hardened-bindmount-pod
  namespace: default
  labels:
    security-tier: hardened
spec:
  os:
    name: linux
  # Explicit security context at pod level
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000
  containers:
    - name: hardened-app
      # Pin to a specific digest in production
      image: alpine:3.19
      command: ["sleep", "3600"]
      securityContext:
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          memory: "128Mi"
          cpu: "250m"
        requests:
          memory: "64Mi"
          cpu: "100m"
      volumeMounts:
        - name: temp-storage
          mountPath: /tmp
          # These flags are enforced at the Linux VFS bind mount layer
          # noexec: blocks binary execution even after chmod +x
          # nosuid: prevents SUID/SGID privilege escalation
          bindMountOptions:
            - noexec
            - nosuid
            - nodev
  volumes:
    - name: temp-storage
      emptyDir: {}

I've added nodev to the example above — the original Kubernetes documentation omits it, but for a /tmp volume there's no legitimate reason to allow device file interpretation.

Verifying noexec Enforcement

## Exec into the running pod
kubectl exec -it hardened-bindmount-pod -- sh

## Attempt to write and execute a script
cd /tmp
printf '#!/bin/sh\necho "Executing untrusted payload"\n' > test.sh
chmod +x test.sh
./test.sh
## Expected: sh: ./test.sh: Permission denied

## Verify the mount flags are active
cat /proc/mounts | grep /tmp
## Look for 'noexec,nosuid,nodev' in the mount options

The kernel enforces MS_NOEXEC at the mount level — this cannot be bypassed by the process running inside the container.

Configuring emptyDir Volume Permissions

Sticky Bit for Shared Scratch Space

This pattern is essential for CI/CD pipeline pods where multiple containers share a workspace. The sticky bit ensures containers can't interfere with each other's files:

apiVersion: v1
kind: Pod
metadata:
  name: hardened-emptydir-pod
  namespace: default
spec:
  os:
    name: linux
  securityContext:
    runAsNonRoot: true
  containers:
    - name: builder
      image: alpine:3.19
      command: ["sleep", "3600"]
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
      volumeMounts:
        - name: shared-workspace
          mountPath: /workspace
  volumes:
    - name: shared-workspace
      emptyDir:
        # 01777 = rwxrwxrwt — world-writable with sticky bit
        # Each container can write, but only the owner can delete their files
        # Works with disk-backed, Memory (tmpfs), and HugePages medium types
        mode: 01777

Restricted Mode for Sensitive Application Data

For database pods or applications handling sensitive temporary data, lock down access to owner and group only:

volumes:
  - name: db-scratch
    emptyDir:
      # 0750 = rwxr-x--- — owner full access, group read/execute, others blocked
      # Pair with fsGroup in pod securityContext to control group assignment
      # Note: fsGroup will override this mode if set — plan accordingly
      mode: 0750

Verifying Sticky Bit Enforcement

kubectl exec -it hardened-emptydir-pod -- sh

## Confirm sticky bit is set
ls -ld /workspace
## Expected: drwxrwxrwt — note the 't' at the end

## Create a file as one user, attempt deletion as another
touch /workspace/builder-artifact.tar.gz

## Simulate deletion attempt from a different UID process
## In a real multi-container scenario, the other container runs as a different UID
su -s /bin/sh nobody -c "rm /workspace/builder-artifact.tar.gz"
## Expected: rm: can't remove '/workspace/builder-artifact.tar.gz': Operation not permitted

Operational Considerations and Known Interactions

What to Watch Out For

fsGroup interaction: If you set fsGroup in your pod's security context, it will override the mode you specify on the emptyDir. This is consistent with how defaultMode works on Secret and ConfigMap volumes, but it can surprise teams who set both. Audit your pod security contexts before relying on emptyDir mode for compliance controls.

Runtime compatibility: The bindMountOptions feature requires runtime support. Before rolling this out cluster-wide, verify your container runtime version advertises the mount_options CRI capability. containerd 1.7+ and CRI-O 1.28+ have this support — check your specific versions.

Windows nodes: Both features are Linux-only. bindMountOptions has no effect on Windows nodes, and emptyDir mode is skipped on Windows since it doesn't support Unix-style permissions. If you run mixed-OS clusters, your manifests need appropriate node selectors.

PV mountOptions are not the same: Don't conflate PersistentVolume mountOptions with bindMountOptions. PV mount options are applied at the storage layer by the CSI driver. bindMountOptions controls the bind mount the runtime creates inside the container namespace. They operate at different layers and can coexist.

Combining Both Features for Maximum Hardening

For the strongest posture, combine both features on the same volume:

volumes:
  - name: secure-tmp
    emptyDir:
      mode: 01777  # Sticky bit for multi-container safety
## In the volumeMount:
volumeMounts:
  - name: secure-tmp
    mountPath: /tmp
    bindMountOptions:
      - noexec
      - nosuid
      - nodev

This gives you both the permission isolation of the sticky bit and the execution prevention of noexec — the combination that most closely mirrors a properly hardened Linux /tmp mount.

Production Readiness Checklist

Before enabling these features in production:

• Confirm VolumeBindMountOptions and EmptyDirVolumeMode feature gates are enabled on API server and kubelet
• Verify container runtime version supports CRI mount_options field
• Audit existing emptyDir volumes for applications that legitimately need execution (e.g., JVM class loading from tmpfs — rare but real)
• Check for fsGroup usage in pod security contexts that could override emptyDir mode settings
• Add OPA/Gatekeeper or Kyverno policies to enforce bindMountOptions on sensitive namespaces
• Test in staging with your specific runtime before cluster-wide rollout
• Document exceptions where noexec cannot be applied, with compensating controls

For teams managing Kubernetes infrastructure at scale, pairing these controls with a solid VPS hosting foundation and proper node hardening creates defense in depth that actually holds up under audit.

Conclusion

Kubernetes v1.37 storage security improvements are a genuine step forward for teams serious about zero-trust workload isolation. The ability to enforce noexec, nosuid, and nodev at the bind mount level closes the execution bypass that made readOnlyRootFilesystem an incomplete control. Configurable emptyDir permissions eliminate the need for init container workarounds and give platform engineers a declarative, auditable way to enforce least-privilege storage access.

These features are Alpha — they require feature gate opt-in and runtime support — but the underlying security controls are production-grade Linux kernel mechanisms. Start testing them now, build your Gatekeeper or Kyverno policies around them, and you'll be ahead of the curve when they graduate to stable.

If you're working through a broader Kubernetes security hardening initiative and need help with cloud infrastructure strategy or managed security controls, the team at NinjaIT specializes in exactly this kind of cloud security architecture. For more deep-dives on container security and DevOps hardening patterns, check out the resources at Data Mammoth.

For related coverage, see our guides on Read more about this topic and Read more about this topic. (Read also: VPS vs VDS vs Dedicated Servers: The Ultimate Comparison Guide)