9.4 Azure Container Instances, Container Apps & Registry Access Control
Key Takeaways
- Disable the Azure Container Registry admin user — it is a single shared credential with push and pull rights that defeats per-identity auditing.
- AcrPull, AcrPush, AcrDelete, and AcrImageSigner are the least-privilege registry roles; Owner and Contributor are over-broad for pipelines.
- Repository-scoped tokens with scope maps limit a credential to named repositories and actions, and are a Premium registry feature.
- Container Instances support managed identities, secure environment variables, secret volumes, and deployment into a delegated virtual network subnet with no public IP.
- Container Apps restrict exposure with internal-only ingress, ingress IP restrictions, Key Vault–backed secrets, and built-in Microsoft Entra ID authentication.
Azure Container Registry Access Management
The registry is where a supply-chain compromise starts. Whoever can push an image can execute code in every cluster that pulls it, so registry access control is a first-class security objective, not a DevOps convenience.
Authentication options, ranked
| Method | Identity model | Verdict |
|---|---|---|
Microsoft Entra identity (az acr login, managed identity, service principal) | Per-identity, auditable, supports Conditional Access on the Entra token | Preferred |
| Repository-scoped token with a scope map | Registry-local token limited to named repositories and actions | Good for partners and constrained CI |
| Admin user | One shared username/password with full push and pull | Disable it |
| Anonymous pull | No identity at all | Only for genuinely public images |
The admin user account (az acr update --admin-enabled false) is enabled on many registries "just to get the pipeline working". It is a single shared credential that cannot be attributed to a person, cannot be scoped, and is not covered by Conditional Access. Its presence is a standing audit finding.
Least-privilege registry roles
| Role | Grants |
|---|---|
| AcrPull | Pull images only — the correct role for AKS, ACI, and Container Apps |
| AcrPush | Pull and push — build agents only |
| AcrDelete | Delete images and manifests — cleanup automation only |
| AcrImageSigner | Sign images for trusted content |
| Owner / Contributor | Full control including the admin credential — never assign to a pipeline |
The canonical pattern for AKS is az aks update --attach-acr, which grants the cluster's kubelet managed identity AcrPull on the registry. No image pull secret is stored in Kubernetes at all.
Repository-scoped tokens (Premium tier) create a registry-local token bound to a scope map — for example, content/read on repositories/partner-app/* and nothing else. Each token gets two passwords so you can rotate without downtime, and tokens can be disabled instantly.
Access-adjacent registry controls
Three controls sit next to authentication and are commonly tested alongside it:
- Quarantine mode makes a newly pushed image unpullable until it passes scanning, so a compromised build cannot be consumed before review.
- Soft delete makes an accidental or malicious manifest deletion recoverable within the retention window.
- Repository-scoped token rotation — each token carries two passwords so a credential can be rotated with no downtime, and a token can be disabled instantly without touching any role assignment.
The registry's network hardening, image signing, and vulnerability scanning are covered with the wider container platform in the Kubernetes and container security section; the point here is that none of those help if the admin credential is still enabled.
Azure Container Instances Security
Azure Container Instances (ACI) run containers without any orchestrator, which means the security controls are on the container group itself:
- Managed identity — system-assigned or user-assigned, so the container pulls from ACR and reads Key Vault with no stored credential.
- Secure environment variables (
secureValue) are write-only: they are not returned byaz container showor the portal. Plain environment variables are, which is how secrets end up in support tickets. - Secret volumes mount sensitive files into the container from an in-memory volume.
- Virtual network deployment — a container group can be placed into a subnet delegated to
Microsoft.ContainerInstance/containerGroups, giving it a private IP with no public exposure and access to private endpoints. - Confidential container groups run on hardware with AMD SEV-SNP so memory is encrypted and attestable, for workloads processing regulated data.
- Restart policy and image source — always pull from your own registry with a digest or immutable tag;
latestfrom a public registry is an unpinned supply-chain dependency.
Monitoring: container groups send stdout/stderr and events to a Log Analytics workspace through the container group's diagnostics settings, and metrics flow to Azure Monitor. Defender for Cloud surfaces posture recommendations for the resource. Because there is no agent inside an ACI container, log shipping plus registry-side image scanning is the practical monitoring model.
Azure Container Apps Security
Container Apps add a managed serverless platform on top of Kubernetes without exposing the cluster:
| Control | What it does |
|---|---|
| Ingress: internal only | The app receives a private, environment-internal FQDN and is unreachable from the internet |
| Ingress IP restrictions | Allow/deny lists on the built-in ingress controller |
| VNet-integrated environment | The environment is deployed into your subnet, enabling private endpoints, NSGs, and egress control through a firewall |
| Managed identity | Registry pulls, Key Vault reads, and backend calls without secrets |
| Secrets with Key Vault references | Secret values resolve from Key Vault at runtime using the app's managed identity |
| Built-in authentication ("Easy Auth") | Microsoft Entra ID sign-in enforced by the platform before the request reaches your code |
| Diagnostic settings | Console logs, system logs, and metrics to Log Analytics or Azure Monitor for detection engineering |
The exam-relevant judgement call: ACI is for single, short-lived, or burst container groups with no scaling requirement; Container Apps is for HTTP services and event-driven microservices that need scale-to-zero, revisions, and platform authentication; AKS is for teams that need full Kubernetes control. Choosing ACI when the scenario asks for autoscaling behind an internal ingress with platform authentication is a common wrong answer.
A build pipeline needs to push images to Azure Container Registry, and an AKS cluster needs to pull them. Which assignment follows least privilege?
A container group in Azure Container Instances must receive a database password without that value being readable from the Azure portal or the az container show output. What should be configured?
An internal microservice deployed to Azure Container Apps must not be reachable from the internet but must still be callable by other apps in the same environment. What is the correct configuration?