Workloads

workloads

workloads is the joined workload view for compute, ingress, and identity cues across service families.

Use it when you want to reason in workload units instead of isolated Azure service rows.

What This Command Answers

• Which combined workloads matter first?
• Which workload already looks reachable and identity-bearing at the same time?
• Which workload should change what you inspect next before you dive into service-specific detail?

Run It

azurefox workloads --output table

For saved structured output:

azurefox workloads --output json

Example Table Output

workload	kind	identity	endpoints	ingress
vm-web-01	VM	UserAssigned; ids=1	52.160.10.20	direct-vm-ip
app-empty-mi	AppService	SystemAssigned	app-empty-mi.azurewebsites.net	azurewebsites-default-hostname
app-public-api	AppService	SystemAssigned	app-public-api.azurewebsites.net	azurewebsites-default-hostname

When To Use It

• when you want a joined workload-first view instead of separate compute, endpoint, and identity tables
• when the interesting question is "what workload changes the path most?" rather than "what service exists?"
• when you need to narrow the next service-specific command faster

What To Look For

• workloads with visible endpoints
• workloads with managed identity or other strong Azure adjacency
• workload type context that makes the next command obvious
• summaries that explain why one workload deserves review before quieter peers

Why It Matters

Many meaningful Azure paths are workload-centric, not service-centric.

A reachable workload with identity can matter more immediately than a lot of raw service inventory. workloads helps you find the assets that are most likely to change the attack path before you spend time opening several separate command outputs.

What Should Stand Out First

• workloads with visible endpoints first
• identity-bearing workloads near the top inside that exposed group
• stable workload type grouping across VMs, App Services, Functions, and VMSS
• enough context to make the deeper follow-up command obvious

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

• If you see a workload with both endpoints and managed identity, go next to Managed-Identities because it shows the workload-to-identity path behind that exposed asset.
• If the workload is an App Service or Function App with public hostnames, go next to Env-Vars because it shows whether that same workload also exposes secret-bearing configuration.
• If the workload is a VM or VMSS with external reachability, go next to Network-Effective because it confirms how strong the visible network exposure really is.

What To Do Next

• Treat workloads as the joined shortlist, not the end of the investigation.
• Use the workload type to choose the deeper service command that will answer the next real question.
• Start with workloads that are both reachable and able to act in Azure.

Boundary

workloads is a routing and synthesis command.

It should join the workload story across supported service families. It is not a replacement for app-services, functions, vms, vmss, or other deeper service-specific views.