Secure image transfer into Tier 0

Why an agent image is Tier 0

Picture a Tier 0 deployment pipeline. A job starts, the platform hands it a service connection token, and the job runs az, terraform or kubectl against the identity control plane. Every one of those steps executes inside a container image or on an agent image. Whoever controls that image controls what the job does with the token.

Microsoft calls this the clean source principle: every security dependency must be as trustworthy as the object it secures. An image that runs Tier 0 jobs is such a dependency. That settles the most common question in one line: agent and tooling images are built inside Tier 0 from pinned, verified inputs, and never promoted from Tier 2. No promotion gate can make a Tier 2 build system trustworthy after the fact.

Application images are different. They run on Tier 0 infrastructure but do not hold pipeline tokens, so Tier 2 can build them as long as Tier 0 decides what gets in. The rest of this article follows those two routes and the controls on each.

Four eyes and a PAW do different jobs

Teams with a strict two-person rule sometimes ask whether they still need PAWs. They do, because the two controls answer different questions. Four eyes asks: does a second person agree with this change? The PAW asks: is this session really that person, on a clean device?

Four eyes only guards the pipeline path. A Tier 0 administrator’s activated roles also work directly in the portal, the CLI and Graph, where no pipeline approval applies. And if an approver’s session is stolen from a daily-driver laptop, the attacker becomes the second pair of eyes.

There is a corollary for the PAW itself: do not build images or install packages on it. Package installs run third-party code at install time. The Shai-Hulud npm worm ran from postinstall and preinstall scripts and harvested cloud credentials, including the Azure CLI profile. On a PAW, that code would run next to activated Tier 0 tokens. The PAW authors code and approves runs; builds move to fresh, network-isolated Tier 0 agents, and everyday development stays on the normal workstation with a non-privileged account.

Decide the route first

Before choosing tools, classify the image. The test is simple: is it referenced by a container step on a Tier 0 job, is it the image of a Tier 0 agent pool, or do Tier 0 pipeline steps call tools inside it? Then it runs Tier 0 jobs. If it only runs on the Tier 0 cluster as an application, it is a workload image, unless that application can obtain Tier 0 credentials.

When in doubt, treat it as Tier 0. Rebuilding inside Tier 0 is always safe; promoting is safe only for workloads.

The target state, step by step

Here is the whole path from a pull request on the PAW to a signed image running on Tier 0 AKS. Press Play flow to walk the nine steps, select any box to see what it does, or select a dark tag (C1 to C14) to see the control behind it and how to verify it.

Three ideas carry most of the weight. First, jobs run only on stateless Managed DevOps Pools: each job gets a fresh VM that is discarded afterwards, and no managed identity is attached to any pool, so a job cannot pick up credentials from the VM. Second, internet egress and write credentials never share a job: acquire can reach pinned vendor endpoints but only writes the catalog, build has neither internet nor write access, and publish holds the push token but no internet. Third, the only identity that can push is reached through workload identity federation, so there is no secret to steal and only runs that pass the checks can use it.

Promoting application images from Tier 2

Only application images take this route, and the direction matters: Tier 0 pulls, Tier 2 never pushes.

1. Tier 2 builds the application image, signs it with the Tier 2 Notation key, attaches the SBOM and provenance, and pushes it to a staging registry with public access off.
2. The staging registry gets a second private endpoint in the Tier 0 registry endpoint subnet. Tier 2 and Tier 0 are never peered. The Tier 0 promote identity has pull-only rights on staging.
3. The promote job verifies the Tier 2 signature and the provenance (repository, branch, pipeline) against a Notation trust policy.
4. It scans the image against an internally mirrored vulnerability database.
5. It copies the image by digest into the Tier 0 registry, including referrers such as the signature and SBOM.
6. It signs the same digest with the Tier 0 key held in Key Vault.
7. Tier 0 AKS admits only digests signed by the Tier 0 key.

Why not az acr import? Import needs the Container Registry Data Importer and Data Reader role on both registries, and every network-restricted registry involved must allow trusted services to bypass its network rules. That reopens exactly the paths the design closes. With export disabled on the Tier 0 registry, import out of it is blocked, which is intended.

One DNS detail is easy to miss. If privatelink.azurecr.io is a shared, central zone, the staging registry’s second endpoint registers a record that collides with its Tier 2 record. Give Tier 0 its own zone and resolver path.

A registry no human can push to

Only two managed identities hold data-plane roles: AcrPush for the orchestration identity through workload identity federation, and AcrPull for the AKS kubelet identity. No human has a role assignment and the admin user is off. On the network side, public access is off and the registry is reachable only through its private endpoint.

Governance closes the last gap. Anyone who can grant roles at the registry’s scope, such as Owner or User Access Administrator, can grant themselves AcrPush. Those roles are therefore Tier 0 too: held through PIM, used from PAWs, and every role assignment change on the registry raises an alert. Built-in Azure Policy definitions can deny the common regressions at the Tier 0 management group, such as re-enabling export, the local admin account or anonymous pull.

Microsoft’s documentation differs on whether Defender for Cloud needs the trusted-services bypass to scan a private registry. Keep the bypass off and confirm that scan results still appear before relaxing anything.

If agents stay in containers

Managed DevOps Pools remove the agent image, the registration secret and Docker-in-Docker in one step, which is why they are the recommended route. Some teams still run Azure DevOps agents as pods on AKS. Microsoft’s own Docker sample is a reasonable starting point for a lab, but it downloads the agent at start, keeps its registration token on disk and, on AKS, mounts the node’s Docker socket. All four of the fixes below are needed before it runs Tier 0 jobs.

For daemonless builds, run BuildKit on the Managed DevOps Pool VM rather than inside agent pods. Kaniko’s original repository was archived in June 2025, so do not plan new work around it.

The control set

Fourteen controls make up the target state, plus the four agent fixes above if containerized agents stay. Each is tagged C for a documented Microsoft capability or L for a design recommendation inferred from documented behaviour, and each carries a check you can run to prove it is in place.

Sources and further reading

Claims above are based on Microsoft’s published documentation, checked on October 13, 2026. Review the linked guidance for current product behaviour before you rely on it.