`ad sp create-for-rbac` should handle creating the role assignment

[colemickens]

As dicussed here: #631 (comment)

It would be helpful if the create-for-rbac command would also create the RBAC Role Assignments, including handling ocp-aad-session-key between the Graph/ARM calls so that we can painless create an SP and give it permissions all in one command.

If this isn't done, everyone who wants to create an SP from a script and give it permissions has to write logic to handle the Graph consistency issues.

[yugangw-msft]

We probably can't do it for this sprint, but suggest get it supported in the next one or so. Due to a known RBAC system's shortcoming, that it takes around 30 seconds to get newly created service principal propagated, and before that, role assignment create would fail. I have personally received 4 customer reports on this, so i can imagine improving this would help lots of people.

[yugangw-msft]

The needed code change is not hard. To maintain the parity and consistency with the role assignment create. l am thinking about to expose 4 new parameters:

    --create-role-assignment: create a role assignment
    --resource-group: create the role assignment on a resource group
    --resource-id: create the role assignment on a specific resource 
    --role: the role name

Once --create-role-assignment flag is on, the default scope will be at subscription level, but you can use resource group or id to be more specific.
The other option is to expose a new super command, maybe called ad sp create-and-apply-role-assignment or any other better naming. I kind of like that, though a little awkward, but we are working around a service bug. For hack or workaround, i like it be explicit.
Please comment

[colemickens]

That sounds excellent! cc: ahmetalpbalkan (old account) (@ahmetalpbalkan)

I presume that it defaults to --role + current active subscription? Will it take a --subscription-id parameter like all of the other commandlets?

It's nice to have --subscription-id because I can require it was a top level input and then pass it along without needing to worry about what the "active" subscription is in the CLI at the moment.

[yugangw-msft]

Your presumption is right.
For --subscription-id, azure-cli doesn't have general support to work off non active subscription like xplat-cli does. I will see whether i can wire that up as well. If not due to cost reason, i will log a separate issue to get it done in near future. The workaround is to call account set before invoke the command

[yugangw-msft]

Mayuri Diwan (@mayurid) , suggest to move out of the backlog and plan for the current/upcoming sprint.

[mayurid]

Done

[colemickens]

This is going to make a lot of things easier, thank you Yugang Wang (@yugangw-msft) !

[yugangw-msft]

Cole Mickens (@colemickens), you are welcome. 2 FYIs:
1.Creating role assignments on other subscriptions is supported right now, though the global --subscription-id parameter support will come later.
2. You can use --scopes to provide space separated scope to create multiple assignments on resource groups, subscriptions, or individual resources
So you have all you have asked.

For public release, the ETA will be next week, but you can always use daily docker image or night builds through curl to try out. Let me know if you see any issues.

[colemickens]

Hm, which one is the nightly docker image? I can't find it / remember it...