Image Security in Azure Container Apps¶

Image security in Azure Container Apps is a combination of registry authentication, revision behavior, and external governance controls. This page explains what Azure Container Apps does natively during image pulls and where you need Azure Container Registry, Azure Policy, or Defender for Cloud to complete the control set.

How Container Apps pulls images¶

Container Apps stores registry settings with the app configuration and uses them when deploying a revision.

Microsoft Learn documents three practical pull patterns:

Public registry: no private registry credentials required.
Private registry with username/password: registry credentials are stored and used during deployment.
Private Azure Container Registry with managed identity: the app uses a system-assigned or user-assigned managed identity instead of registry credentials.

Managed identity for Azure Container Registry¶

For ACR, the recommended security posture is managed identity.

Requirements documented by Microsoft Learn:

Enable the managed identity on the container app.
Assign the identity the AcrPull role on the registry.
Do not configure a username and password when using managed identity.

Managed identity is the preferred ACR authentication path

Managed identity removes long-lived registry credentials from app configuration and gives you auditable RBAC-based access to the registry.

Username and password for private registries¶

Container Apps also supports private registry authorization through username and password. This is functional, but it shifts the security burden to secret storage and credential rotation.

For ACR specifically, that usually means using either:

An admin user credential, or
A service principal credential.

Both are weaker production defaults than managed identity.

Image pull and revision activation flow¶

Container Apps treats image changes as revision-scope configuration. That means a new or changed image reference creates a new revision, and the platform uses the configured registry authentication method to pull the image for that revision.

flowchart TD
    A[Revision-scope image change] --> B[New revision created]
    B --> C[Container Apps checks registry config]
    C --> D{Authentication method}
    D --> E[Public registry pull]
    D --> F[Private registry username and password]
    D --> G[ACR managed identity + AcrPull]
    E --> H[Image manifest and layers pulled]
    F --> H
    G --> H
    H --> I[Revision activates]

Security implications:

A mutable tag can cause a new revision to pick up a different image than you expect.
Broken registry auth blocks revision startup.
Revision health validation should be part of image promotion, not an afterthought.

Public vs private registries¶

Registry type	Authentication model	Security posture	Typical guidance
Public registry	Usually anonymous pull	Lowest control	Acceptable for experimentation, not ideal for production
Private registry with username/password	Stored credential	Medium to low	Use only when managed identity is not available
Azure Container Registry with managed identity	RBAC + managed identity	Strongest documented ACA-native option	Preferred production default

Trusted or allowed registries¶

This is a common architecture review question: does Azure Container Apps natively enforce an allow-list of registries?

Conservative answer¶

Container Apps documentation describes how to configure registries for an app, but it does not document an ACA-native feature called allowed registries or trusted registries that enforces image source allow-listing by itself.

Use these controls instead:

Azure Policy for governance over approved resource configurations.
Azure Container Registry policy and network controls for the registry surface.
Platform review standards that require ACR or other approved registries in CI/CD.

Do not describe allowed registries as an ACA-native enforcement feature

Microsoft Learn documents registry configuration and governance options around Azure resources, but not a built-in Container Apps-only allow-list switch for image sources. Treat allow-listing as a policy and supply-chain governance control.

Vulnerability scanning and image assessment¶

Container Apps does not document a built-in native image vulnerability scanner on the app resource itself. The documented vulnerability management path is registry-centric.

Defender for Containers and ACR¶

Microsoft Learn documents Defender for Containers as providing vulnerability assessment for container images in Azure Container Registry.

That means the security control is primarily:

Registry-side: scan the image in ACR.
Governance-side: review or gate promotion based on findings.
ACA-side: deploy only approved image references.

What lives on ACA vs ACR¶

Control	ACA-native surface	ACR / governance surface
Registry authentication	Yes	N/A
Managed identity for ACR pull	Yes	Requires AcrPull on ACR
Vulnerability scanning	No documented native ACA scanner	Yes, via Defender for Containers on ACR
Source allow-listing	No documented ACA-native allow-list feature	Policy / governance pattern
Private network path to registry	Indirectly, through environment networking	ACR private endpoints and DNS