Workload Identity Pivot

workload-identity-pivot

workload-identity-pivot is the first runnable chains family in HarrierOps Kube.

Use it when the important question is whether the current foothold can likely influence a workload or workload-linked service account that already carries stronger downstream Kubernetes control.

What This Family Gives You

• a ranked queue of the strongest workload-linked identity paths
• one joined row instead of scattered workload, service-account, secret, and permission clues
• the stronger Kubernetes control sitting behind the workload-linked identity
• the next command to open when the path matters and the proof edge is still weak

Run It

harrierops-kube chains workload-identity-pivot --output table

If you want a saved structured artifact:

harrierops-kube chains workload-identity-pivot --output json --outdir ./harrierops-kube-demo

Example Table Output

priority	workload	subversion point	path type	kubernetes control	visibility	next review
high	default/fox-admin	review visible workload-linked token path	direct control not confirmed	attached service account has cluster-wide admin-like access	medium	workloads

When To Use It

• after workloads or service-accounts shows a stronger-than-expected service account path
• after secrets shows a workload-linked token or trust path worth joining back to identity
• when privesc suggests a workload-backed path and you want the bounded joined story next
• when the next question is "which workload-linked identity path should I pressure first?" rather than "which clue do I have somewhere in the cluster?"

What To Look For

• the workload named in the row, because that is the pressure point
• the subversion point wording, because that tells you what is actually visible now
• the path type, because that is the confidence and action shape in one field
• the stronger Kubernetes control behind the attached identity
• the next-review column, because that is where the family tells you how to close the weakest edge

The top rows should already read like the clearest and highest-consequence workload-linked identity paths in the current slice. If a row looks scary but still reads weak, the family should make that boundary obvious instead of burying it.

Path Type Guide

• direct control visible: current access likely lets you change or enter the workload, and the attached service account already changes the next move
• workload pivot: the workload-linked service account path is meaningful, but the stronger control story still depends on deeper workload-side validation
• direct control not confirmed: the stronger identity is visible, but current scope does not yet prove the workload-side action that would make the path immediate
• visibility blocked: a real workload-linked clue survives, but current scope does not confirm enough of the stronger path to raise it more strongly

Backing Commands

• workloads
• service-accounts
• permissions
• privesc
• secrets

Why It Matters

This is where HarrierOps Kube stops treating workload, service-account, secret, and escalation signals as separate screens.

workload-identity-pivot matters because it keeps the path evidence-bounded while still showing which workload-linked identity story could actually change the next move.

The hard part is usually not noticing that a workload looks interesting. The hard part is deciding whether the attached identity story is strong enough to spend time on, which workload-side lever is actually visible, and which follow-up command will prove or kill the path fastest.

That is what this family is for. It should turn a loose cluster of clues into a smaller operator queue without pretending the path is already confirmed just because the service account looks powerful.

What Should Stand Out First

• rows where the workload and stronger identity path are both clear
• direct-looking paths before merely interesting posture
• visible token or secret linkage when it keeps the identity path closer to direct use
• blocked or weaker rows below clearer workload-linked pivots
• next-review guidance that tells you where to verify the path without hesitation

This page should read like a pressure queue, not a flat list of suspicious workloads.

If You See..., Go Next To...

• If you see path type = direct control visible, go next to Permissions because the next question is what the current foothold can already do against that workload path.
• If you see path type = workload pivot, go next to Workloads because the next question is which workload-side validation step sharpens the path.
• If you see path type = direct control not confirmed, go next to Service Accounts because the stronger identity is clear but the action edge is still weak.
• If you see visibility blocked, go next to the shortest flat command behind the missing edge instead of reading the row as stronger than current scope supports.

What To Do Next

• Follow the next review column instead of reopening every supporting command equally.
• Treat stronger identity language as a bounded lead until the workload-side action edge is proven.
• Use workloads, service-accounts, or permissions based on which part of the path is still weakest.

Boundary

workload-identity-pivot can claim that visible workload, service-account, permission, privesc, and secret evidence suggests a credible workload-linked identity pivot.

It should not claim successful execution, token use, stronger control, or sidecar insertion unless the explicit control edge and confirmation basis are visible.