Managed Identities

managed-identities

managed-identities ties Azure principals back to the workloads that can act through them.

Use it when the important question is not just "which identity exists?" but "which workload can use that identity in practice?"

What This Command Answers

• Which workloads have managed identities?
• Which of those identities are most worth checking first?
• Which workload-linked identity could matter most if the workload were compromised?

Run It

azurefox managed-identities --output table

For structured review:

azurefox managed-identities --output json

Example Table Output

identity	type	attached to	operator signal	next review
ua-app	userAssigned	vm-web-01	Public VM workload pivot; direct control visible.	Check permissions, then vms.

When To Use It

• when service principals and managed identities look more important than user accounts
• after Principals shows strong workload-linked identity presence
• when you need to connect Azure access back to the compute or service surface that can mint tokens

What To Look For

• workloads tied to broad or central managed identities
• reuse patterns that suggest the same identity matters across multiple places
• application or compute surfaces that would become Azure pivots if compromised
• identities that look more important once you consider the workload relationship, not just the object ID

Why It Matters

Managed identities often create a cleaner and quieter path than a human credential.

If a workload can act as an Azure principal, compromise of that workload may be enough to pivot into Azure access. managed-identities makes that workload-to-identity relationship obvious so you can focus on the paths that matter operationally.

What Should Stand Out First

• the managed identities tied to the most interesting workloads
• reuse patterns that suggest the same identity matters in multiple places
• visible privilege cues when available
• workload-linked identities that would matter most if the workload were compromised

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

• If you see a managed identity attached to a public or otherwise exposed workload, go next to Permissions because it confirms whether compromising that workload changes Azure control.
• If you see a managed identity attached to an App Service or Function App, go next to Env-Vars because it shows whether that same workload also exposes secret-bearing configuration.
• If you see a managed identity attached to a VM or VMSS, go next to vms or vmss because those commands show the host or fleet context behind the token path.

What To Do Next

• Use Permissions to see whether the managed identity is also highly privileged.
• Use Privesc if the workload-linked identity creates a credible escalation path.
• Pivot into the relevant workload command once you know which application or compute surface is the real way into the identity.

Boundary

managed-identities should expose workload-linked identity paths clearly.

It is not a raw token workflow, a credential dump, or a complete replacement for workload-specific review.