Which isolation controls are supported for Azure Container Apps Jobs on a Consumption workload profile?

On a Consumption profile in a workload-profiles environment, Jobs expose identity lifecycle and volume configuration, while Linux capability sets, root-filesystem read-only mode, per-Job DNS policy, and per-Job egress policy are not customer-configurable through the documented Microsoft.App/jobs API.

1. Capabilities, filesystems, and scratch storage

For Microsoft.App/jobs@2026-07-01, the documented Container and InitContainer schemas contain image, command, arguments, environment variables, resources, probes, and volume mounts. They do not expose Kubernetes securityContext, capabilities, readOnlyRootFilesystem, seccomp, AppArmor, or mount-propagation fields. Therefore:

These conclusions follow directly from the complete Jobs resource schema ^1^. Container Apps also explicitly disallows privileged containers ^2^.

EmptyDir provides replica-scoped temporary storage, while the container filesystem provides container-scoped temporary storage. The documented combined allowance is 1, 2, 4, or 8 GiB depending on allocated vCPU; there is no documented per-volume quota or hardened mount-options contract ^3^.

2. Registry-pull identity with lifecycle: None

For Jobs, identitySettings.lifecycle accepts All, Init, Main, or None. None means that the selected identity is not made available during either the main-container or init-container lifecycle ^1^.

The registry configuration separately names the identity used to authenticate an image pull. Managed-identity image pulls are platform operations and support user-assigned identities ^4^. Consequently, the supported configuration is:

configuration: {
  registries: [{
    server: registryServer
    identity: registryIdentityId
  }]
  identitySettings: [{
    identity: registryIdentityId
    lifecycle: 'None'
  }]
}

This allows the platform to use the identity for image retrieval without making it available to main or init containers.

The documentation does not guarantee that identity-related endpoint or header environment-variable names are absent when access is disabled. Their presence alone therefore is not evidence that the identity is usable.

There is also no documented token-free runtime attestation API for this restriction. Verification should remain configuration-based:

1. Read the deployed Job resource.
2. Confirm the registry entry references the intended identity.
3. Confirm that the matching identitySettings entry has lifecycle: None.
4. Confirm the job starts successfully from the private image.

Avoid requesting a token merely to prove denial. Also tightly restrict Microsoft.App/jobs/start/action: callers with that action can override execution images, commands, and environment variables and can use identities configured as available to containers ^5^.

identitySettings was added to Jobs in 2024-08-02-preview; it is present in stable 2025-01-01, 2026-01-01, and 2026-07-01 ^6^.

3. Egress denial

Egress controls are not container- or Job-scoped. Jobs and apps share their Container Apps environment’s networking and logging capabilities ^5^. Enforcement is performed at the environment subnet/network path:

1. Use a workload-profiles environment integrated with a VNet.
2. Associate a 0.0.0.0/0 UDR with the environment subnet.
3. Route it to Azure Firewall or another network virtual appliance.
4. Default-deny there and allow only required platform destinations.

Full UDR/firewall egress control is supported in workload-profiles environments, including when the Job uses the Consumption profile; it is not equivalent to legacy Consumption-only environment networking ^7^.

Required exceptions depend on enabled features, but include platform artifact endpoints; ACR requires its registry endpoints plus Azure Active Directory, and Azure Monitor must be allowed when using that log destination ^8^.

A complete DNS denial is not supported for the Consumption profile. It must retain access to AzurePlatformDNS, including [IP Address]; blocking it can prevent the environment from functioning. Dedicated workload profiles can instead block Azure DNS and route DNS entirely through custom resolvers ^9^.

Thus, subnet-level egress filtering is supported, but strict “deny every packet including platform DNS” is incompatible with a Consumption profile.

4. Resolver search domains and options

The Jobs API has no dnsPolicy, dnsConfig, nameserver, search-domain, or resolver-options fields ^1^. Resolver behavior cannot be configured per container, execution, or Job.

Supported DNS controls are environment/VNet scoped:

• Configure DNS servers on the environment’s VNet.
• If using custom DNS, forward unresolved queries to [IP Address].
• Preserve the required Container Apps and underlying platform names.
• Treat changes as shared infrastructure changes affecting other apps and Jobs using that environment/network, not as a Job-local setting ^9^.

A custom environment DNS suffix changes application domain naming for the whole environment; it does not provide per-Job control of /etc/resolv.conf search/domain/options ^10^.

No regional exception to these controls is documented. Region-specific firewall FQDNs and service tags still need to be selected for the deployment region.

References

1. Microsoft.App jobs 2026-07-01
2. Containers in Azure Container Apps
3. Use storage mounts in Azure Container Apps (azure-resource-manager)
4. Azure Container Apps image pull with managed identity (portal)
5. Jobs in Azure Container Apps
6. API version change log for deployment of Microsoft.App/jobs
7. Control outbound traffic in Azure Container Apps with user defined routes
8. Azure Container Apps environment integration with Azure Firewall
9. Private endpoints and DNS for virtual networks in Azure Container Apps environments
10. Custom environment DNS Suffix in Azure Container Apps