az containerapp create not respecting existing user-managed identity and unnecessarily erroring trying to assign permissions

[stephlocke]

Describe the bug

I'm trying to deploy an Azure Functions app to Azure Container Apps using the CLI with the ACA app pulling from ACR using a user managed identity. The create works under my account, but not the GitHub Action OIDC as the credential does not have permissions granting roles.

The docs say (bold for my emphasis)

--registry-identity
A Managed Identity to authenticate with the registry server instead of username/password. Use a resource ID or 'system' for user-defined and system-defined identities, respectively. The registry must be an ACR. If possible, an 'acrpull' role assignemnt will be created for the identity automatically.

Giving it a resource ID for user-defined is prompting it to try creating an acrpull role assignment and fail the command entirely because of the lack of permissions but it should be optional to assign permissions.

Related command

az containerapp create

ghaction.yml

Errors

azure.cli.core.azclierror.UnauthorizedError: Role assignment failed with error message: "(AuthorizationFailed) 
The client 'guidA' with object id 'guidA' does not have authorization to perform action 'Microsoft.Authorization/roleAssignments/write' over scope '/subscriptions/***/resourceGroups/***/providers/Microsoft.ContainerRegistry/registries/***acr4s45c/providers/Microsoft.Authorization/roleAssignments/e22609a6-f847-4c09-b15c-1134dadbbb00' or the scope is invalid. If access was recently granted, please refresh your credentials.

Code: AuthorizationFailed

debuglogs.txt

Issue script & Debug output

ghaction.yml
debuglogs.txt

            az extension add -n containerapp  --upgrade --allow-preview true
            az version
            az containerapp create --debug --name ${{ env.ACA }} \
            --resource-group ${{ secrets.AZURE_RESOURCE_GROUP }} \
            --environment ${{ env.ACA_ENV }} \
            --kind 'functionapp' \
            --image ${{ env.IMAGE }} --container-name api \
            --cpu 0.5 --memory 1Gi \
            --ingress 'external' --target-port 80 \
            --registry-server ${{ env.ACR }} \
            --user-assigned ${{ secrets.ACA_USER_ASSIGNED }} \
            --secrets azure-sql-connection-string=${{ env.DB_CONN }}

secrets.ACA_USER_ASSIGNED like /subscriptions/<>/resourcegroups/<>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<>

Expected behavior

The create statement should use the user-managed identity and when it cannot assign permissions proceed to attach the user-maanged identity anyway, enabling the script to succeed.

Environment Summary

{
"azure-cli": "2.77.0",
"azure-cli-core": "2.77.0",
"azure-cli-telemetry": "1.1.0",
"extensions": {
"containerapp": "1.2.0b3"
}
}

Additional context

No response

ghaction.yml
debuglogs.txt

[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.

[stephlocke]

Obviously, the workaround will be to give the github action's workload identity the permission Microsoft.Authorization/roleAssignments/write but that's sub-par from a security perspective.

[Greedygre]

Hi @stephlocke

Thanks for reporting this issue.

For az containerapp create --registry-server ${{ ACR registry }}, when run without --registry-identity, --registry-username/--registry-password, it will auto try to use system-identity to pull the image.

Log:

Creating an acrpull role assignment for the system identity

Then it failed with error:

azure.cli.core.azclierror.UnauthorizedError: Role assignment failed with error message: "(AuthorizationFailed) The client 'guidB' with object id 'guidB' does not have authorization to perform action 'Microsoft.Authorization/roleAssignments/write' over scope '/subscriptions/***/resourceGroups/***/providers/Microsoft.ContainerRegistry/registries/***acr4s45c/providers/Microsoft.Authorization/roleAssignments/e22609a6-f847-4c09-b15c-1134dadbbb00' or the scope is invalid. If access was recently granted, please refresh your credentials.

The workaround is run with a valid --registry-identity or --registry-username/--registry-password.