az containerapp create --yaml: wipes our Service Connector Environment Variables

[ricohomewood]

Describe the bug

We are using Terraform with the AzApi resource to configure a boiler plate container app with SQL Service Connector ( to manage connection strings securely via user assigned identity). This all works fine and dynamically creates an Environment variable for you as per its design.

However, when we deploy our application, with some other Env vars defined for the container using the yml schema: az containerapp update --resource-group some_rg --name some_container_name --yaml somefile.yml. It wipes out the dynamically created connection string environment variable created by the container app service connector.

The steps involved here are to

1. Create a boilerplate container app via terraform using the azapi_resource with the latest version of the Azure API Microsoft.App/containerApps@2025-02-02-preview
2. Create a Service Connector to Azure SQL DB using the azapi_resource with the latest version of the ServiceLinker Azure API Microsoft.ServiceLinker/linkers@2024-04-01, for example:

resource "azapi_resource" "sql_connection" {
  type      = "Microsoft.ServiceLinker/linkers@2024-04-01"
  name      = azurerm_mssql_database.identity.name
  parent_id = module.container_app.app.id
  body = {
    properties = {
      scope = "main"
      targetService = {
        type = "AzureResource"
        id   = azurerm_mssql_database.identity.id
      }
      authInfo = {
        authType       = "userAssignedIdentity"
        clientId       = module.container_app.identity.client_id
        subscriptionId = (provider::azurerm::parse_resource_id(module.container_app.identity.id))["subscription_id"]
      }
      configurationInfo = {
        deleteOrUpdateBehavior = "ForcedCleanup"
        additionalConnectionStringProperties = {
          "Data Source" = "${azurerm_mssql_failover_group.identity.name}.database.windows.net,1433"
        }
        customizedKeys = {
          AZURE_SQL_CONNECTIONSTRING = "ConnectionStrings__identityDb"
        }
      }
      clientType = "dotnet"
    }
  }
}

This all works fine and as expected and creates the connection string environment variable for the container app.
3. Deploy the application using az containerapp update --resource-group some_rg --name some_container_name --yaml somefile.yml with the following example yml:

# yaml-language-server: $schema=https://www.schemastore.org/azure-containerapp-template.json
---
properties:
  environmentId: '${CONTAINER_APP_ENVIRONMENT_ID}'
  workloadProfileName: Consumption
  configuration:
    activeRevisionsMode: Single
    registries:
      - server: ${CONTAINER_REGISTRY}
        identity: ${CONTAINER_REGISTRY_IDENTITY_ID}
    runtime:
      dotnet:
        autoConfigureDataProtection: true
    ingress:
      targetPort: 8080
  template:
    revisionSuffix: ${REVISION_SUFFIX}
    scale:
      minReplicas: ${MIN_REPLICAS}
    containers:
      - image: ${CONTAINER_REGISTRY}/docker/${IMAGE_NAME}:${IMAGE_TAG}
        name: main
        env:
          - name: ASPNETCORE_ENVIRONMENT
            value: ${ASPNETCORE_ENVIRONMENT}
          - name: AZURE_CLIENT_ID
            value: ${CONTAINER_APP_CLIENT_ID}
        probes:
          - type: Liveness
            httpGet:
              path: /alive
              port: 8080
              scheme: HTTP
            failureThreshold: 3
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1
          - type: Readiness
            httpGet:
              path: /health
              port: 8080
              scheme: HTTP
            failureThreshold: 3
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 1

And the app deploy wiping out the connection string environment variable, thus breaking the container app.

Related command

az containerapp update --resource-group some_rg --name some_container_name --yaml somefile.yml

Errors

No errors, just wipes out existing Service Connector Environment variables, breaking the application

Issue script & Debug output

See description for issue flow

debug.log

Expected behavior

Container app is deployed and existing Service Connector Environment variables respected and untouched when deploying via --yaml

Environment Summary

azure-cli 2.76.0

core 2.76.0
telemetry 1.1.0

Extensions:
azure-devops 1.0.2

Dependencies:
msal 1.33.0b1
azure-mgmt-resource 23.3.0

Python location '/opt/az/bin/python3'
Config directory '/home/runner/.azure'
Extensions directory '/opt/az/azcliextensions'

Python (Linux) 3.12.10 (main, Jul 29 2025, 09:28:48) [GCC 13.3.0]

Additional context

No response

[yonzhan]

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

[microsoft-github-policy-service]

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

[Greedygre]

Hi @ricohomewood

And the app deploy wiping out the connection string environment variable, thus breaking the container app.

Do you mean in step 2 you creates the connection string environment variable for the container app successfully.
Then in step 3, with following env vars, which didn't contains connection string environment variable, it wiping out the Containerapp's existing connection string environment variable.

Right?

env:
          - name: ASPNETCORE_ENVIRONMENT
            value: ${ASPNETCORE_ENVIRONMENT}
          - name: AZURE_CLIENT_ID
            value: ${CONTAINER_APP_CLIENT_ID}

When using az containerapp update --yaml, the env: in the yaml file type is a list, and it will override all existing env vars.
So the existing connection string environment variable wipe out.

Can you try to include the connection string environment variable in the yaml file?

Thanks

[ricohomewood]

Hi @Greedygre

Do you mean in step 2 you creates the connection string environment variable for the container app successfully.

In step 2 we create the Service Connector (this automagically creates an environment variable created and managed by the Service Connector) we don't create the env var itself because it creates a dynamic secretRef with a random ID.

Then in step 3, with following env vars, which didn't contains connection string environment variable, it wiping out the
Containerapp's existing connection string environment variable.

Right?

env:
          - name: ASPNETCORE_ENVIRONMENT
            value: ${ASPNETCORE_ENVIRONMENT}
          - name: AZURE_CLIENT_ID
            value: ${CONTAINER_APP_CLIENT_ID}

Correct.

When using az containerapp update --yaml, the env: in the yaml file type is a list, and it will override all existing env vars. So the existing connection string environment variable wipe out.

That's not quite true, it doesn't wipe out the dynamically created DOTNET_ReadOnlyDataProtectionKeyDirectory env var when setting the ASP .NET Data Protection Key option in the development stack of the container app:

Which sets this:

Can you try to include the connection string environment variable in the yaml file?

We can't, its dynamically created by the Service Connector? Much like the DOTNET_ReadOnlyDataProtectionKeyDirectory which is created automatically by the data protection key setting. Which suggests the design somewhere has created an incompatible deployment scenario? There needs to be a way in the yml / schema to Update only like you can do if not using yml deploy OR figure out how the DOTNET_ReadOnlyDataProtectionKeyDirectory is not getting deleted by the app deploy (maybe some magic under the hood in the API?)

Thank you

[Greedygre]

Hi @ricohomewood
Sorry for the inconvenience.

• About DOTNET_ReadOnlyDataProtectionKeyDirectory:
  Yes this is relate to your setting in containerapp:

 runtime:
      dotnet:
        autoConfigureDataProtection: true

The env var DOTNET_ReadOnlyDataProtectionKeyDirectory is auto created or updated in the backend. So it will not be impacted by the input with Env:.

• About a way in the yml / schema to Update only:
  The az containerapp update --yaml support only update the specify property in the yaml file.
  But due to the type of property Env var is a List, so when it override the list value, the other item in the list is wipe out. I know you have understand this.

For workaround, can you separate with 2 commands?:

• when use az containerapp update --yaml {}, remove this containers.env.
• use az containerapp update --set-env-vars {} to update the env vars

 --set-env-vars                                                           : Add or update
                                                                               environment
                                                                               variable(s) in
                                                                               container. Existing
                                                                               environment variables
                                                                               are not modified.
                                                                               Space-separated
                                                                               values in 'key=value'
                                                                               format. If stored as
                                                                               a secret, value must
                                                                               start with
                                                                               'secretref:' followed
                                                                               by the secret name.

Thank you

[ricohomewood]

Hi @Greedygre

Thanks for the update.

The env var DOTNET_ReadOnlyDataProtectionKeyDirectory is auto created or updated in the backend. So it will not be impacted by the input with Env:.

This is the problem i'm trying to identify / convey. When you create a Service Connector it ALSO creates and updates the env var in the backend, same as the env var DOTNET_ReadOnlyDataProtectionKeyDirectory so the yml update should not be touching it.

Looks like others are having the same issue: microsoft/azure-container-apps#427.

I wonder if this is because service connections are extension resources of an app and not first class resources (or child resources of the app environment)? Looking here: https://learn.microsoft.com/en-gb/azure/service-connector/concept-service-connector-internals

Thanks

[ricohomewood]

Hi @Greedygre

The ACA team have now decided to retire this product as per this announcement: microsoft/azure-container-apps#1566

So feel free to close this