Forward workload identity to volume drivers at mount time

[Viktor-Velkov]

Proposed Change

As a volume driver developer
I want the workload identity (process GUID for LRPs, task GUID for Tasks) available to the driver at mount time
So that I can validate a mount against the workload's service bindings without reconstructing that identity out-of-band.

Why this is necessary

When Rep mounts a volume it calls volumeManager.Mount(logger, driver, volumeId, containerId, config) in storenode.go. The config map carries only broker-supplied options — it does not carry the workload's process_guid / task_guid. The Docker Volume Plugin protocol volman speaks to drivers passes only Name on Mount, so no per-container context reaches the driver at mount time through the standard contract either.

Rep already holds the authoritative identity when it calls Mount — it is in the container's Tags (process-guid, lifecycle) and Guid — but it is never forwarded. A driver that needs to verify "is this volume actually bound to this workload?" therefore has to reconstruct the identity itself, e.g. a cell-wide cfdot actual-lrps --cell-id <cell> scan (~1–2s typical, seconds under load, requiring sudo + shell tooling) followed by a DesiredLRP fetch to read VCAP_SERVICES.

Proposed change

Rep enriches the mount config map with the identity it already holds, before calling Mount:

• _workload_guid — process_guid (LRP) / task_guid (Task)
• _workload_type — "lrp" / "task"

Additive, no protocol change: the keys ride the existing config map, which the Docker plugin's Create call already forwards to the driver.

Alternatives considered (in order of preference)

1. Enrich the config map (this proposal) — zero protocol change, implemented and validated.
2. Typed workloadGuid / workloadType params on the volman Mount interface and driver contract — explicit, but ripples across all drivers and fakes.
3. Extend the Docker Volume Plugin MountRequest with Opts — most general, but deviates from the Docker plugin spec and needs coordinated dockerdriver + volumedriver changes.

Prior work

Implementation: #1191

Acceptance criteria

Scenario: LRP volume mount exposes workload identity
Given an LRP with a volume mount scheduled on a cell
When Rep calls the volume driver to mount the volume
Then the mount config contains _workload_guid set to the LRP's process_guid
And _workload_type set to "lrp"

Scenario: Task volume mount exposes workload identity
Given a Task with a volume mount scheduled on a cell
When Rep calls the volume driver to mount the volume
Then the mount config contains _workload_guid set to the task_guid
And _workload_type set to "task"

Scenario: backward compatibility for containers without a lifecycle tag
Given a container that has no lifecycle tag
When Rep mounts its volume
Then the mount config is passed through unchanged (no identity keys added)

Scenario: existing drivers unaffected
Given a volume driver that does not read the new keys
When it receives a mount config enriched with _workload_guid / _workload_type
Then it ignores the unknown keys and mounts as before

Related links

• Forward workload identity to volume drivers via mount config #1191 for the implementation
• code.cloudfoundry.org/executor for the Mount call site in depot/containerstore/storenode.go