In most workplaces, handing someone a “Reader” badge means: you may look, you may not touch, and you certainly may not carry anything out to your car. Microsoft’s Azure cloud has a different understanding of the word. Auditors from the security consultancy SCRT, conducting a configuration review of a client’s Azure workloads with nothing more than Reader access at the subscription level, found they could download the client’s container images from Azure Container Registry — the whole image, to take home and open offline.
Here is the twist: nothing was broken. This behaviour is, as SCRT’s write-up concedes, “in fact expected” — Microsoft’s own Azure Container Registry documentation says so. SCRT’s objection is that it shouldn’t be. The default permission bundled into the role, known as AcrPull, “reflects a lack of separation between the data plane and the control plane,” the firm argues, and that has consequences when companies treat container images as a convenient place to leave secrets.
A quick tour of the machinery. Azure Container Registry is Microsoft’s managed service for building, storing and managing container images and related artefacts, based on the open-source Docker Registry 2.0. It supports public and private configurations and hooks into things like Azure Kubernetes Service and Azure Container Apps. In plainer terms: it’s the warehouse where companies keep the boxed, ready-to-run software their cloud actually executes.
Access is governed by Azure’s role-based access control, with built-in roles including Owner, Contributor and Reader. All three, Microsoft’s documentation confirms, are automatically granted the “Pull image” permission. So anyone assigned even the humble Reader role at subscription level inherits the ability to connect to every registry in that subscription and extract its images.
To make sure this was real life and not a documentation misunderstanding, SCRT built it in a lab. They created a dedicated subscription, stood up a registry with an admin account holding the AcrPush and Global admin roles, and pushed a sample nginx image into it. Then they assigned a test user the Reader role on the subscription — nothing else.
The test user logged in with the Azure CLI, authenticated to the registry, listed its repositories, and ran docker pull. The image downloaded without complaint and turned up in the user’s local Docker inventory. Reader, it turns out, reads very thoroughly indeed.
Why this matters is what’s inside a container image. Anything stored unencrypted rides along: network and topology information, URIs to confidential cloud resources, business information, personal data, and — the one that makes security people sit up — keys and secrets to third-party systems, all of which developers have a way of baking into images for convenience. SCRT’s pointed observation: any organisation that ever granted auditors Reader access at subscription level may also have inadvertently handed them the full contents of every image hosted in the same subscription.
The awkward part is that Microsoft demonstrably knows how to do this properly, because it already does — one floor down, in Azure Key Vault. There, a subscription-level Reader can browse a vault’s metadata and inspect its configuration but, as SCRT notes, can never read the actual contents. Getting inside requires separate, dedicated roles Microsoft provides for Key Vault, such as Key Vault Contributor and Key Vault Reader. That granularity, the firm writes, “reinforces our initial oversight hypothesis”: the registry’s all-access Reader looks less like a philosophy and more like an oversight.
Until Microsoft agrees, SCRT’s advice is a checklist of hygiene. Limit subscription-level Owner, Contributor and Reader assignments to essential users; use ACR repository roles or custom roles for finer control. Never embed credentials or secrets in images — that is what Key Vault is for. Put the registry in its own dedicated subscription. Disable public network access or restrict it to selected IP addresses, and use private links. Configure Conditional Access policies. And switch on diagnostic settings, monitoring activity logs for unexpected authentications and image pulls.
SCRT’s recommendation to Microsoft is to rebuild ACR’s permissions on the Key Vault pattern, splitting control-plane and data-plane access into two layers. It is a reasonable request, and the only awkward thing about it is that it has to be made at all. The most quietly alarming sentence in the entire write-up remains the one where everyone agrees the system worked exactly as documented.