Remove need for a password when deploying container image from Azure Container Registry

[jpd1]

Is your feature request related to a problem? Please describe.

When creating a new deployment, or updating a deployment, for a container image hosted within Azure Container Registry into Azure Spring Apps, a registry username and password must be passed in the az cli command line with the following parameters: --registry-username and --registry-password.

Reference: https://learn.microsoft.com/en-us/cli/azure/spring/app/deployment?view=azure-cli-latest#az-spring-app-deployment-create

We would like to avoid needing to use a password.

Describe the solution you'd like

Allow the use of a managed identity to connect to the container registry, or allow an access token to be passed similar to the ACR login command documented here - https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli#az-acr-login-with---expose-token

Describe alternatives you've considered

There does not appear to be any other alternatives when running from the command line.

When running within a DevOps pipelines, store the password into Key Vault and setup the pipeline variables to read from Key Vault.

Though, this requires somebody to generate a password and put it into Key Vault.

Describe the Customer Impact

Would like to avoid the need for any password.

Additional context

It seems the password is required due to the Spring Apps API requiring it to be set within the imageregistrycredential as documented here - https://learn.microsoft.com/en-us/rest/api/azurespringapps/deployments/update?tabs=HTTP#imageregistrycredential

Can we contact you for additional details?

Yes.

[allxiao]

We are tracking this in our backlog.

Add some thought about this:

• direct access token is not a good fit, because of the valid time associated to the token may prevent the access in future when the container is rescheduled
• KeyVault, as mentioned, is not a good choice because we need to prepare the secrets in the KeyVault manually
• Managed identity might be a choice, but we need to work out how we can inject the token request process in the Kubernetes image pulling process, probably via the credential provider
• Another possible solution is to provide some service level credentials, which can be shared by all the deployments.