In label-keyed segmentation, what does an attacker who can write a workload's label gain over one who can only send packets?
answer
- they satisfy the control instead of defeating it
- no forged packet, therefore no wire artefact
- the write is control-plane, the traffic is not
- tag-write permission was handed out as metadata
- granting a label equals granting reachability
basics
~20 sThey stop attacking the boundary and become an allowed party. Policy grants reachability to the label, so a successful tag write buys permitted, ordinary-looking flows with no packet crafting. The tagging API is now the segmentation boundary.
solid answer
~50 sAn attacker restricted to packets has to work through whatever path policy already allows, and anything they forge at the wire — a spoofed source, a mismatched interface — is exactly what the fabric and its sensors are built to catch. An attacker who can write a label does not attack the boundary at all: they change what the boundary believes about them. Set `tier=web` on a workload and the dataplane grants every flow that `tier=web` is entitled to. There is nothing anomalous to detect, because the traffic genuinely is permitted. That moves the whole control: permission to set a security-significant label is permission to be reached, so the tagging API deserves the same authorisation, change review and audit as a firewall rule change — and the evidence of abuse lives in control-plane audit records of the write, not in flow records, which carry a five-tuple and byte counts and no payload at all.
go deeper
Know that in attribute-keyed policy the label is what grants access, so being able to set a label is being able to grant yourself access. Say why nothing looks wrong on the wire afterwards.
Explain the mechanics: the dataplane resolves the label at evaluation time, so a written label produces genuinely permitted traffic, and the only artefact is a control-plane record of the write.
Demonstrate the design response — a restricted set of policy-relevant labels, no self-assignment by a workload's own credential, change review on label changes, and alerting on writes outside the deployment path.
Be ready to argue that permission to tag is permission to reach, and to say who must give that permission up, what it slows down, and how you review it at the same cadence as firewall changes.
## Two attackers, two different jobs Start by separating the capabilities. The **packet-level attacker** has reachability and can send whatever they like. Their job is to find a path policy already permits, or to make the fabric believe a packet came from somewhere it did not. Both are hard in a modern virtual network: source spoofing is filtered at the edge and at the hypervisor's vNIC, the enforcement point sees the real origin regardless of what the header claims, and unusual pairings show up as new conversations in flow telemetry. The **label-writing attacker** does not need any of that. Attribute-keyed policy says `tier=web may reach tier=db on 5432` and the dataplane resolves `tier=web` to whatever carries the label at evaluation time. Writing the label onto a workload you control makes you one of those things. You have not defeated the control; you have satisfied it. ## Why this is worse than it sounds Three properties compound: 1. **There is no wire artefact.** The resulting flows are permitted flows between the addresses that a permitted pair currently occupies. A passive observer sees a normal conversation. Flow records (NetFlow or IPFIX) carry the five-tuple, byte and packet counts and timestamps, and carry no payload at all, so they can show that two workloads started talking and never show why the policy said yes. 2. **The action is control-plane, not data-plane.** The abuse happened in an API call, in a different log, on a different retention schedule, watched by different people — often nobody. Teams that instrument segmentation heavily on the network side frequently have no alert on tag writes at all. 3. **The permission is usually already widely held.** Tag-write is treated as metadata: cost centres, owners, environments. It is handed to deployment pipelines, platform tooling and most engineers, because it looks administrative. The moment policy keys on those attributes, that permission silently became reachability-granting, and nobody re-reviewed who holds it. The direction of the claim matters here in the same way it does everywhere in defence: a permitted flow proves the *policy evaluated to allow*, never that the workload is what it claims. An engineer who says "the flow was allowed, so it was legitimate" has encoded the whole vulnerability in one sentence. ## The consequence for the design The tagging API becomes a segmentation boundary. Practically: - **Split the label namespace.** Security-significant labels — the ones policy keys on — are a small, restricted set, distinct from free-form descriptive tags. Everyone can set `owner`; almost nobody can set `tier` or `env=prod`. - **Deny self-assignment.** A workload's own runtime credential should not be able to set its own security-significant labels. That single rule removes the cheapest version of this attack: compromise a workload, promote it. - **Review label changes like rule changes.** A change that grants `tier=web` reachability to a new workload class is a firewall change. If your firewall changes need a ticket and a reviewer, so does this. - **Audit and alert on the write.** Log every write of a security-significant label with the principal that made it, and alert on writes that did not come from the deployment path. This is the only place the attack is visible. ## What an interviewer is probing The wrong answer a competent engineer gives is "the platform would spoof-check it" or "our sensors would flag the new traffic". Anti-spoofing validates addresses, not assertions about workload identity; and the traffic is not anomalous, it is authorised. The second wrong answer is treating tag-write as metadata management — it is the answer that explains why this permission was granted so broadly in the first place. The strong answer names the shift in where the boundary sits. Before, the boundary was in the path: a filter between two zones, and an attacker had to get through it. After, the boundary is in the issuance path: an API call, and an attacker has to be allowed to make it. Both are real boundaries; only one of them is where the network team is looking. ## Investigating it If you suspect a forged label, the sequence is: pull control-plane audit records for writes to security-significant labels over the window, identify the principal and whether it was the deployment path, then correlate the write timestamp against first-seen flows between the newly labelled workload and the segment it reached. Flow data can establish that the conversation began minutes after the tag write; it cannot, on its own, establish that anything was wrong, and a candidate who claims the flow data alone proves the abuse has misread what a flow record contains.
- If the flow records look completely normal, where do you look for evidence?In the control-plane audit of label writes: which principal set which security-significant label on which workload, and when. Then correlate that timestamp with the first-seen flow between that workload and the segment it reached. Flow records carry the five-tuple, counts and timestamps and no payload, so they can date the new conversation but can never show that the label behind it was forged.
- Who typically holds tag-write permission, and why is that a problem?Deployment pipelines, platform tooling and most engineers, because tags started life as cost and ownership metadata and were scoped accordingly. Once policy keys on them, that same permission grants network reachability, and it was never reviewed as such. The fix is to carve the policy-relevant labels into a restricted set with a different, much shorter, list of writers.
- Would anti-spoofing at the fabric detect this?No. Source filtering and uRPF-style checks validate that a packet's source address belongs where it claims; they say nothing about attributes. The attacker is not lying about their address — they are using their real address, with a label that entitles it. Address-level anti-spoofing and label issuance defend against different attacks and neither substitutes for the other.
A packet attacker picks the lock on the door. A label attacker gets their name added to the guest list, walks in past the guard, and is greeted politely.
saying these in an interview costs you the question
- Says the fabric's anti-spoofing would catch it
- Treats a tag write as metadata rather than a policy change
- Assumes network sensors would flag the resulting traffic as anomalous
- Concludes a permitted flow was therefore legitimate
- Leaves workloads able to set their own security-significant labels