az ad sp create-for-rbac for existing application DELETES EXISTING PASSWORDS even though the command failed

[kcIcon]

Describe the bug

Background
I am currently using GitHub workflows and actions to push a container image to an Azure Container registry.

I was logged in as an administrator account that has access to two subscriptions for my Organization. One for development and test and one for production accounts. However, they are for the same tenant id.

I confirmed that my development/test subscription was the default subscription when running in Azure CLI by entering az account list

Using Microsoft documentation at "Create a service principal with role and scope" I identified the scope at which I wanted to apply the role based authentication and I wanted a service principal to be contributor to the container registry that is under the resource group for granularity of access considering these are push and pull actions that are needing to be performed.

• The application with the name provided for --name already existed. There is no information on that application stating that it is for a particular subscription or that.

• The resource group already existed under the dev/test subscription.

• The subscription id provided is for the dev/test account (as shown below).

Action performed
I ran the following command:
az ad sp create-for-rbac --name [name redacted] --role contributor --scopes /subscriptions/[subscription redacted]/resourceGroups/[resource group redacted] --json-auth

However, because I dont have the permissions to assign roles/permissions therefore the command failed. Or so I thought.

Expected Outcome
If I had the permissions I was expected that a new service principal be created for the resource group and application ID to be able to contribute.

Actual Outcome
Until we noticed that all role based logins were failing because the previous secret used for authentication had been deleted and a new one had been created for the Enterprise application [name redacted], rather than the resource group:

Investigation
Nowhere in the documentation does it state that if there is an application with the name provided that it will ignore other parameters:

The examples provided lead me to believe that I needed to provide the application ID name that I wanted the service principal to relate to with the way "MyApp" is being used. However, it is probably recommended that I have left the --name parameter blank so that a random name be provided to the service principal.

Source Code for CLI: ISSUE
This link takes you to the definition for the "create_service_principal_for_rbac"

azure-cli/src/azure-cli/azure/cli/command_modules/role/custom.py

Line 1151 in 38c45a3

def create_service_principal_for_rbac(

This is where I noted that it will try and create an application, if it already exists, delete all passwords and create a new rbac one that expires in 1 years' time (screenshot provided previously). THEN it tries to do the role assigned which failed due to my permissions, however, the password deletion and new key had already been completed.

EXPECTED RECTIFICATION

1. A warning that existing passwords/keys will be removed if the action is to proceed and that it should also state the scope at which it is going to apply the service principal before continuing. Then give the user and option to cancel the operation if it is not desired outcome.
2. Update your documentation to state that the name must be unique. If it matches any other scope then it will be applied at that scope regardless of what you have provided. All documentation leads the user the believe that the name is not of importance and therefore, would not have expected this outcome

This issue resulted in an outage of a production system for 3 hours yesterday.

Related command

az ad sp create-for-rbac

Errors

The command failed saying that my user account did not have access to perform or write role based permissions. I dont have the exact error and am not wanting to retry since the outage that it resulted in yesterday.

However, it obviously did not rollback all activities performed by the command

Issue script & Debug output

see above

Expected behavior

see above

Environment Summary

Activity Date	19/03/2024, 13:15
Activity Type	Update service principal
Correlation ID	7c397970-e489-46f3-94ee-14d8b7583cea
Category	ApplicationManagement
Status	success
Initiated by (actor)
Type	User
Additional Details
User-Agent	python/3.9.14 (Linux-5.10.102.2-microsoft-standard-x86_64-with-glibc2.35) AZURECLI/2.58.0 (RPM) cloud-shell/1.0
AppId	587cc61f-c3e8-4e07-ab40-01210b2b9e5a

Additional context

No response

[yonzhan]

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

[TheKLARKEN]

This bug caused a production issue for us as well, as our keys for prod and non-prod were unfortunately part of the same App Registration, and both got deleted.

For further context, I mistook the az ad sp create-for-rbac command as creating SP credentials for RBAC, not creating the SP itself with credentials for RBAC.

I was following the documentation reference in the recent Helm v2 deprecation notice, which is why I ran it against an existing SP. Even so, it should fail with an explanatory error--it shouldn't delete all credentials on the existing SP. 😓