ACR

acr

acr is the Azure Container Registry triage command for registry posture, exposure, and automation signals.

Use it when you need to know which registries look most exposed, permissive, or tightly coupled to downstream automation first.

What This Command Answers

• Which registries deserve review before repository or image-level detail?
• Which registry most changes software-supply or workload risk if compromised?
• Which registries combine public reachability, weak auth posture, or automation hooks in a way that matters now?

Run It

ho-azure acr --output table

For saved structured output:

ho-azure acr --output json

Example Table Output

registry	login server	auth	exposure	depth	posture
acr-public-legacy	acr-public-legacy.azurecr.io	admin=yes; anon-pull=yes	public=Enabled; default=Allow; pe=0	webhooks=2; enabled=1; wide-scopes=1	Standard; bypass=AzureServices; trust=disabled

When To Use It

• when container registries may be a stronger supply-path concern than general workload inventory
• when you need to rank registries before deeper repository or image review
• when registry automation, replication, or weak auth posture could change operational risk

What To Look For

• public or broad reachability
• admin_user_enabled=true or anonymous_pull_enabled=true
• webhook and replication context
• managed identity or weaker governance cues that make a registry more central

Why It Matters

A weak registry can affect both software supply and the workloads that depend on it.

Public reachability, admin-user enablement, anonymous pull, replication, and webhook automation can turn one registry into a much more consequential target than its peers. acr helps you surface that difference early.

What Should Stand Out First

• public or otherwise broad reachability
• admin-user or anonymous-pull posture
• active webhook, replication, or governance signals
• login server and network stance visible in the same row

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

• If you see admin_user_enabled=true or anonymous_pull_enabled=true, go next to Resource-Trusts because it shows whether that registry posture sits inside a broader public-resource trust pattern.
• If you see broad webhook scope, multiple replications, or a managed identity on a registry that matters, go next to Permissions because it helps identify the strongest Azure control paths around that automation-heavy registry.

What To Do Next

• Prioritize the registries that combine reachability, permissive auth, and automation cues.
• Treat supply-path and downstream workload consequence as part of the same story.
• Use the registry posture to decide whether the next question is about trust boundaries, identity control, or downstream deployment paths.

Loot Behavior

Loot currently keeps the top-ranked rows for this command. That ordering is useful, but it is not yet a shipped semantic high / medium / low analyst contract unless the command explicitly labels rows with a defended priority contract.

Boundary

acr is a registry posture command.

It should rank the registries that most deserve follow-up first. It is not repository enumeration, image analysis, or data-plane interaction.