az containerapp registry set resets runtime configuration (breaks .NET data protection)

[srs-adamr]

Describe the bug

When using az containerapp registry set to add or update container registry credentials, the command unintentionally resets unrelated configuration properties in properties.configuration. Specifically, the runtime object (which contains .NET-specific settings like runtime.dotnet.autoConfigureDataProtection) is set to null after running the command.

This is a breaking side effect that disables critical .NET features like ASP.NET Core Data Protection for apps that scale to multiple replicas.

Command causing the issue

az containerapp registry set \
  --name <app-name> \
  --resource-group <resource-group> \
  --server ghcr.io \
  --username <username> \
  --password <token>

Steps to reproduce

1. Create or use an existing Container App with .NET runtime configuration enabled (the "Development stack" setting in Azure Portal set to ".NET")

2. Verify the runtime configuration exists before the change:

az containerapp show --name <app> --resource-group <rg> --query "properties.configuration.runtime" --output json

Output before: {} or {"dotnet": {"autoConfigureDataProtection": true}}

3. Run the registry set command:

az containerapp registry set \
  --name <app> \
  --resource-group <rg> \
  --server ghcr.io \
  --username MyUsername \
  --password MyNewToken

4. Check the runtime configuration again:

az containerapp show --name <app> --resource-group <rg> --query "properties.configuration.runtime" --output json

Output after: null (no output)

Expected behavior

az containerapp registry set should only modify registry-related properties (configuration.registries and the associated secret), preserving all other configuration properties like:

• runtime (including .NET data protection settings)
• ingress
• dapr
• Any other unrelated configuration

Actual behavior

The command appears to perform a JSON Merge Patch on the configuration object that only includes the registries array. Properties not explicitly included in the patch payload (like runtime) are reset to null.

Impact

This bug has significant production impact:

• ASP.NET Core Data Protection is silently disabled - Apps using features like anti-forgery tokens, authentication, SignalR, Blazor Server, or session state will break when scaled to multiple replicas
• No warning or indication - The command completes successfully with no indication that other settings were modified
• Silent data loss - Configuration is lost without any way to recover it from the command output

Environment

• Azure CLI version: 2.75.0
• OS: macOS (Darwin 24.6.0)
• Shell: zsh

$ az --version
azure-cli                         2.75.0
core                              2.75.0
telemetry                          1.1.0

Workaround

Instead of using az containerapp registry set, update only the secret value directly:

# Find the existing secret name referenced by the registry
az containerapp registry list --name <app> --resource-group <rg> --query "[].passwordSecretRef" --output tsv

# Update only the secret value (does not affect other configuration)
az containerapp secret set \
  --name <app> \
  --resource-group <rg> \
  --secrets "<existing-secret-name>=<new-token-value>"

This approach updates the credential without touching any other configuration.

Suggested fix

The az containerapp registry set command should either:

1. Read-modify-write pattern: Fetch the current configuration, merge only the registry changes, then write back the complete configuration
2. Use a more targeted API: If the ARM API supports updating just the registries array without affecting other properties, use that
3. Preserve existing properties: Ensure the PATCH payload includes all existing configuration properties, not just the ones being modified

Related

This affects the .NET on Azure Container Apps feature documented here:
https://learn.microsoft.com/en-us/azure/container-apps/dotnet-overview

The autoConfigureDataProtection setting is critical for .NET apps as described in the documentation:

"In .NET 8.0.4 and later, ASP.NET Core apps that use data protection are automatically configured to keep protected data accessible to all replicas as the application scales."

[azure-client-tools-bot-prd]

Hi @srs-adamr,

2.75.0 is not the latest Azure CLI(2.81.0).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

[yonzhan]

Thank you for opening this issue, we will look into it.

[github-actions]

This issue is related to security. Please pay attention.

Powered by issue-sentinel

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @howang-ms, @Greedygre.

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @howang-ms, @Greedygre.

[srs-adamr]

Update: Further Investigation Results

After upgrading to CLI 2.81.0 and conducting additional testing, we've encountered some inconsistent behavior that makes this harder to diagnose. It may not be purely a CLI issue.

Testing Environment

• Upgraded from Azure CLI 2.75.0 → 2.81.0
• macOS (Darwin 24.6.0)

Test Methodology

1. Initial observation: After running az containerapp registry set on multiple container apps with CLI 2.75.0, we noticed the runtime configuration was null on those apps.

2. Test with CLI 2.81.0: We tested on a container app that had runtime: {} (empty object):

   • Before az containerapp registry set: runtime: {}
   • After az containerapp registry set: runtime: {}
   • Result: The runtime config was preserved

3. Checked all affected apps:

   • Apps we modified with CLI 2.75.0: runtime: null
   • Apps we hadn't touched: runtime: {}
   • One app we modified with 2.75.0 still had runtime: {} (unclear why)

Inconsistencies Observed

1. Portal UI inconsistency: The Azure Portal "Development stack" setting displays inconsistently for the same underlying runtime: {} value - sometimes showing as "enabled/.NET", sometimes as "Unspecified". This happens without any CLI changes.

2. Cannot confirm causation: We cannot definitively confirm that CLI 2.75.0 caused the runtime: null state because:

   • We don't have records of what runtime was before we ran the commands
   • Some apps we modified still have runtime: {}
   • We cannot downgrade to 2.75.0 to reproduce

3. Revision suffix conflicts: When attempting to modify apps via Portal after CLI changes, we consistently hit revision suffix conflicts (revision with suffix X already exists). The Portal appears to cache/reuse revision suffixes from the template rather than auto-generating new ones.

4. Failed updates affecting display state: In one case, a Portal update that failed (due to revision suffix conflict) still appeared to change how the Portal displayed the runtime configuration.

Current Assessment

The issue may be more complex than originally thought:

• Could be CLI 2.75.0 specific (potentially fixed in 2.81.0)
• Could be Portal UI caching/display inconsistency
• Could be eventual consistency issues between Portal and ARM API
• Could be related to how runtime: null vs runtime: {} are handled differently

Workaround Confirmed

Using az containerapp secret set to update registry credentials works correctly and does not affect any other configuration:

# Get existing secret name from registry config
az containerapp registry list --name <app> -g <rg> --query "[].passwordSecretRef" -o tsv

# Update only the secret value
az containerapp secret set --name <app> -g <rg> --secrets "<secret-name>=<new-value>"

This approach updates credentials without touching configuration.registries or configuration.runtime.

Request

If you have any insight into:

1. Whether there were changes between 2.75.0 and 2.81.0 related to az containerapp registry set and configuration preservation
2. Why runtime: {} vs runtime: null might behave differently
3. Known Portal caching issues with the Development stack setting

That would help us understand what happened. We're unable to fully reproduce at this point but wanted to document our findings in case others encounter similar issues.