OpsCanary
kubernetesstoragePractitioner

Hardening Kubernetes Storage: Bind Mount Options and EmptyDir Permissions

5 min read Kubernetes BlogSep 16, 2026Reviewed for accuracy
Share
PractitionerHands-on experience recommended

In a world where security breaches are increasingly common, hardening your Kubernetes workloads is essential. The introduction of bind mount options and enhanced permissions for EmptyDir volumes in Kubernetes v1.37 addresses this need by allowing you to enforce stricter security policies on your storage. These features help prevent unauthorized code execution and misuse of special device files, which can lead to vulnerabilities in your applications.

The bind mount options include 'noexec', which prevents the execution of binaries on the mounted filesystem, 'nosuid', which disallows set-user-identifier or set-group-identifier bits, and 'nodev', which ensures that character or block special devices are not interpreted. By default, Kubernetes does not apply these flags, leaving your volumes exposed. To enable these features, you need to activate the VolumeBindMountOptions and EmptyDirVolumeMode feature gates on both the API server and kubelet. This setup allows you to define secure volume mounts in your pod specifications, ensuring that your applications run in a more controlled environment.

When deploying these features, keep in mind that they are currently in Alpha. This means you should test them thoroughly in your staging environments before rolling them out to production. The added security comes with the responsibility of ensuring compatibility with your existing workloads. Be aware of the potential for misconfiguration, especially if your applications rely on executing binaries from mounted volumes. Always validate your configurations and monitor your applications closely after implementing these changes.

Key takeaways

  • Implement 'noexec' to prevent execution of binaries on mounted filesystems.
  • Use 'nosuid' to block set-user-identifier or set-group-identifier bits.
  • Enable VolumeBindMountOptions and EmptyDirVolumeMode feature gates for enhanced security.
  • Apply the sticky bit on EmptyDir volumes to restrict file deletion to owners.
  • Test these features in staging before deploying to production.

Why it matters

By hardening your container storage, you significantly reduce the risk of security vulnerabilities that can lead to data breaches or system compromises. This proactive approach is essential in maintaining a secure Kubernetes environment.

Code examples

YAML
1apiVersion: v1
2kind: Pod
3metadata:
4  name: hardened-bindmount-pod
5  namespace: default
6spec:
7  os:
8    name: linux
9  containers:
10  - name: hardened-app
11    image: alpine:latest
12    command:
13    - "sleep"
14    - "3600"
15    securityContext:
16      readOnlyRootFilesystem: true
17    volumeMounts:
18    - name: temp-storage
19      mountPath: /tmp
20      bindMountOptions:
21      - noexec
22      - nosuid
23  volumes:
24  - name: temp-storage
25    emptyDir: {}
YAML
1apiVersion: v1
2kind: Pod
3metadata:
4  name: hardened-emptydir-pod
5  namespace: default
6spec:
7  os:
8    name: linux
9  containers:
10  - name: app-container
11    image: alpine:latest
12    command:
13    - "sleep"
14    - "3600"
15    volumeMounts:
16    - name: shared-tmp
17      mountPath: /tmp
18  volumes:
19  - name: shared-tmp
20    emptyDir:
21      mode: 01777

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →
Linux Foundation🔥 SEPTEMBER PROMOSponsor

35% off certifications and e-learning with code SEPT26BTS35, or 40% off bundles and instructor-led training with SEPT26BTS40. New this month: the MCPA (Model Context Protocol Associate) certification.

Claim the discount →

Get the daily digest

One email. 5 articles. Every morning.

No spam. Unsubscribe anytime.