hi @houk-ms can you pls have a look? @arrownj fixed a simliar issue before, you can talk with him for context.

@dharmab Thanks for the feedbacks! Actually, this is a behavior as expected, which provides users a way to delete all the role assignments in a subscription.
And, before taking any actions, AzureCLI will prompt the message This will delete all role assignments under the subscription. Are you sure? as a reminder.

@yungezz I personally recommend we add an example in the doc to describe the usage rather than change the command itself which may block the users that are already using this way to delete all their role assignments.

which provides users a way to delete all the role assignments in a subscription.

Why is this something a user would ever want to do? And why is it the default if no arguments are passed? That's like if you typed rm and the default was This will delete all files under the current directory. Are you sure?

Whether or not someone would want to delete all of their role assignments in a subscription is not necessarily at issue.

The problem is that this is absolutely the wrong way to offer that feature. Something so destructive should require additional arguments!

Prompting the user for confirmation when they enter az role assignment delete is not sufficient to correctly ascertain that someone positivitely wants to utterly wipe their subscription.

hi @dharmab thanks for raise the issue. I see the concern. Actually that's the reason cli prompt for a confirmation for delete all. We'll look at customer scenario again to validate this.

I accidentally did this:

az role assignment create --assignee "$SOME_VAR" --role "Owner"

SOME_VAR was accidentally set to empty string. I did not get any prompt and EVERY OWNER WAS DELETED.I lost access to my subscription. Cannot even file a support ticket cause I lost permissions.
Is there a way to fix this?

Forget to mention:
azure-cli 2.7.0 *

core 2.7.0 *
telemetry 1.0.4 *

@Catramen I'm so sorry. I'm not a MSFT employee but I'll forward your comment to my TAM and hopefully they can help route it.

This issue was previously reported in #2933 and the prompt for "delete all" was added in #8862.

The logic is to search for all assignments and delete them all:

    assignments = _search_role_assignments(cmd.cli_ctx, assignments_client, definitions_client,
                                           scope, assignee, role, include_inherited,
                                           include_groups=False)

    if assignments:
        for a in assignments:
            assignments_client.delete_by_id(a.id)

I agree this behavior is insane and should be changed even though it is a breaking change.

If you have already deleted all role assignments, and luckily you are a Global Administrator in AAD tenant, there is a chance to recover it: https://docs.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin

#15278

I accidentally did this:

az role assignment create --assignee "$SOME_VAR" --role "Owner"

SOME_VAR was accidentally set to empty string. I did not get any prompt and EVERY OWNER WAS DELETED.I lost access to my subscription. Cannot even file a support ticket cause I lost permissions.
Is there a way to fix this?

This specific issue is tracked in #15278. We'll fix it to throw error when --assignee is empty string in az role assignment delete.

Today az role assignment delete behavior isn't that consistent on when to promoting, when to delete all. Let's use this issue to track refine work on role assignment delete behavior. Worth to check policy assignment delete also. Reassign to @jiasli .

Was this ever fixed?

EDIT: Ah, it was (at least partially) fixed in PR #15282.

EDIT: This is still a hideously dangerous footgun. az role assignment delete should do nothing and return a 1 to the shell, indicating an error. It should never, ever ask to delete everything. If someone wants to delete everything, that should be a separate command or something. All PR #15282 did was to make this safe to use in a scripted fashion. Interactive users who don't pass any command line args after delete are still at risk.

I have created PR #30470 to remove the "delete all role assignments under the subscription by default" behavior. At least one of --ids, --assignee, --role, --resource-group, --scope must be provided. If none is provided, az role assignment delete will show an error.

I also proposed a more aggressive solution: make --scope a required argument for az role assignment delete (#30471).

@dharmab, @Starblade42, @Catramen, @evanfoster, please kindly share your thoughts or suggestions.