Workloads

workloads

workloads is the joined workload triage command in HarrierOps Kube.

Use it when you want one workload-first view that pulls together exposure, identity, and risky execution context instead of making you join three separate command outputs in your head.

What This Command Answers

• Which running workloads matter first?
• Which workloads are exposed, identity-bearing, or execution-risky?
• Which workload already changes the next move before deeper review?
• Which deeper command should follow the row that rose to the top?

Run It

harrierops-kube workloads --output table

If you want a saved structured artifact:

harrierops-kube workloads --output json --outdir ./harrierops-kube-demo

Example Table Output

priority	workload	identity	exposure	execution
high	storefront/web-5d4f6	runs as storefront/web (can change workloads)	Ingress app.example.com; LoadBalancer 34.120.0.15	no strong risky execution signal
high	default/fox-admin	runs as default/fox-admin (has cluster-wide admin-like access)	no visible exposure path	privileged; allows privilege escalation; mounts docker socket; mounts host paths; adds Linux capabilities; runs as root
medium	build/node-debug	runs as build/default	no visible exposure path	uses host namespaces; mounts host paths

When To Use It

• after inventory shows risky workloads or exposed paths
• after exposure when you want the workload consequence behind the edge
• when the investigation needs a workload-first priority queue

What To Look For

• exposed workloads first
• strong service-account linkage folded into the identity column
• privileged, host-touching, or host-namespace execution cues
• workloads that look operationally central enough to matter even without exposure

Why It Matters

Many important Kubernetes stories are workload stories, not object stories.

An exposed workload with a meaningful service account or risky execution context changes the next move faster than three separate rows spread across three commands. workloads brings that combined story together early.

What Should Stand Out First

• workloads with public-looking exposure paths
• workloads running as stronger service accounts
• privileged or host-touching execution
• controller-like or central workloads that would matter even if they are not public

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

• If identity is the most important part of the row, go next to Service Accounts because the next question is which identity path sits under the workload.
• If exposure is still the unclear part, go next to Exposure because the next question is how strong the outside-facing attribution really is.
• If the grant story still matters, go next to RBAC or Permissions depending on whether you need evidence or current-session meaning next.

What To Do Next

• Start with the workload that combines exposure, identity, and consequence most clearly.
• Use service-accounts when workload-linked identity matters more than runtime detail.
• Use exposure, rbac, permissions, or secrets based on which part of the row still needs proof.

Boundary

workloads is workload-first prioritization.

It is not a full manifest dump, a config browser, a secret review, or a replacement for deeper identity and exposure commands.