Kubernetes Storage Hardening Is Not a Security Context
A read-only root filesystem is often treated as sufficient container hardening. Writable volumes can still permit executable content, unsafe device files, or overly broad access between containers in the same Pod.
Storage hardening is therefore a layered platform contract. Kubernetes 1.37 adds alpha controls for bind mount options and emptyDir permissions, but fields alone do not create a dependable security boundary.
What matters
- Explicit threat models: Decide which writable paths need
noexec,nosuid,nodev, or restricted directory modes. - Layered semantics: Distinguish filesystem mount options, container bind mount flags, ownership, and Pod security settings.
- Standard workload profiles: Provide reviewed defaults for temporary space, shared workspaces, and persistent application data.
- Runtime compatibility: Verify feature gates, node capabilities, and container runtime support before allowing workloads to depend on new controls.
- Policy and evidence: Enforce approved combinations at admission and test the effective mount behavior on representative nodes.
Recommendation
Treat writable storage as part of the workload security model, not as an implementation detail hidden behind a volume declaration. Platform teams should own supported profiles and compatibility guarantees; application teams should select the profile that matches their data flow.
Adopt alpha controls deliberately and keep existing safeguards until their behavior is proven across the fleet. Consistent enforcement matters more than exposing every new field immediately.