update volumeattachments/status
A VolumeAttachment's status is what the external-attacher CSI sidecar trusts to decide whether a volume is still attached, so flipping status.attached can trigger a spurious detach mid-use, with I/O errors and data corruption on stateful workloads.
Only reachable through the status subresource, since the same write aimed at the main resource is silently dropped.
- API Group
- storage.k8s.io
- Scope
- cluster
- Audit Level
- RequestResponse
Escalation Paths
The external-attacher CSI sidecar reconciles VolumeAttachment objects and reads status.attached to decide whether a volume is still attached to a node
Write status.attached false through the volumeattachments/status subresource.
The same write aimed at the main resource returns success and is silently dropped
The attacher acts on the reported state and can detach a volume that a running pod still has mounted, so in-flight writes fail with I/O errors
spec is immutable after creation, so an attachment cannot be retargeted to another node or volume.
Only the reported state can be corrupted
Inert without a registered CSI driver running an external-attacher sidecar.
On a cluster with no such driver, the object is reconciled by nothing
Additional rights needed:
Note:
The subresource write is the only path that lands.
A status patch through the main resource is dropped without error.
Whether a detach follows depends on the CSI driver and its attacher, which is why the impact is storage disruption rather than a privilege boundary.