2

I'm trying to create an Azure Role Assignment which assigns the User Access Administrator role to a service principal but only for Azure Data Factory resources.

I see plenty of documentation on setting scopes by subscription, resource group, or even resource, but can't figure out how to set it for all resources of a certain type.

I've tried this PowerShell command which runs successfully but doesn't have the intended effect. The service principal still can't perform the actions of that role on ADF resources.

New-AzRoleAssignment -ObjectId ddddddd-dddd-dddd-dddd-dddddddddddd -RoleDefinitionId 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9 -Scope "/providers/Microsoft.DataFactory"

Powershell command runs successfully

I've also tried experimenting with wildcards in the scope, but this seems unsupported: /subscriptions/dddddddd-dddd-dddd-dddd-dddddddddddd/resourceGroups/*/providers/Microsoft.DataFactory/dataFactories/*

Here's the documentation I've already read:

Community
  • 1
  • 1
jschmitter
  • 1,669
  • 19
  • 29
  • Furthermore, I can't remove the role assignment created in the screenshot above. "The provided information does not map to a role assignment". But re-applying the PowerShell command throws error: "The role assignment already exists." Seems like a bug in role assignment. – jschmitter Jan 07 '20 at 16:13
  • Create a separate question for your other problem. – Daniel Björk Jan 07 '20 at 17:41
  • @DanielBjörk Yeah just thought that info might help indicate something of why the role assignment isn't working. – jschmitter Jan 07 '20 at 19:18

2 Answers2

1

The Role Assignment is used to assign the user a predefined or custom role "role definition".

The role definition is the one that defines the scope of the role. The scope of the role needs to be subscription(s), resource group(s) and resource(s). You can't define a type of resource. Its more like one or multiple locations.

Scope structure

Structure of RBAC Scope: https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#scope

How to create a Custom Role: https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles

In your case, if you want to grant a user to be able to handle IAM on all DataFactory you will need to manually define each datafactory scope. Then use the actions in the Microsoft.Authorization provider: https://learn.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations#microsoftauthorization

When defining the Scope for the assignment you can either define it with the -Scope <String> parameter or a combination of the following parameters. 

   -ResourceGroupName <String>
   -ResourceName <String>
   -ResourceType <String>

The resource type "-ResourceType ". For e.g. Microsoft.Network/virtualNetworks. Should only be used in conjunction with ResourceGroupName, ResourceName and (optionally)ParentResource parameters to construct a hierarchical scope in the form of a relative URI that identifies a resource.

For more details see: https://learn.microsoft.com/en-us/powershell/module/az.resources/new-azroleassignment?view=azps-3.3.0

Daniel Björk
  • 2,475
  • 1
  • 19
  • 26
  • 1
    I don't think that's exactly what I'm trying to do. `Microsoft.DataFactory/dataFactories/*` would give access to perform all data factory actions. I'm not trying to get the service principal to perform data factory actions. I'm trying to get it to manage access control (limited to data factory resources), which is not a data factory action. But correct me if I'm misunderstanding. – jschmitter Jan 07 '20 at 19:20
  • @jschmitter Im sorry for the confusion. What you are trying to do cant be achived easily. Since the scope is not a type its one or multiple locations. So either you need to rethink what you want to achive or you need to manually define each DataFactory (which is a manual task that will never work in the longrun.). I have updated my answer to match your question better. – Daniel Björk Jan 07 '20 at 19:45
  • Ok, thanks. My only point of confusion then is this: since there is a scope property on role assignments, how is that intended to be used? – jschmitter Jan 07 '20 at 19:50
  • 1
    The scope in the definition defines where you are allowed to assign the role. The scope in the assignment is the relation between the user and the location he will be granted the role. So a user with the role "User Access Administrator" can be granted the permission on all locations defined in the Scope of the role definition. So if you give a user the "User Access Administrator" role on a resource group, he will only get the permissions on that group even though the scope in the definition is the whole subscription. – Daniel Björk Jan 07 '20 at 19:54
0

the existing answer is pretty much on point, however there are a few things you can do to make it work:

  1. the most obvious limit all data factories to a single resource group (or a couple of them) and grant SP owner permissions to those resource groups (or create a custom RBAC role).
  2. use a simple script to assign those permissions dynamically

If you cant put all of the data factories in the same resource group\set of resource groups. Script would look like this ("pseudo" code, not tested, but will give you the idea):

Get-AzSbuscription | Foreach-Object {
    $_ | Select-AzSubscription
    Get-AzDataFactory | Foreach-Object {
        New-AzRoleAssignment -Scope $_.ResourceId`
           -ObjectId ddddddd-dddd-dddd-dddd-dddddddddddd `
           -RoleDefinitionId 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9 
    }
}

and run it on a schedule

4c74356b41
  • 69,186
  • 6
  • 100
  • 141
  • Thats one way to do it, but it might accidently give permissions to subscriptions not intented to and it will give you a governance thats horrable. Everytime you want to remove permissions for a user you will need to build a script to remove the assignments (maybe you dont want to remove the user) and everytime you want to add a new user you need to update the code or have some sort of list to manage. Its better to rethink what he wants to do and find another solution. – Daniel Björk Jan 07 '20 at 21:15
  • well, you didnt offer any solution at all. this is a lot better then not having any solution. excluding subscriptions is trivial, removing permissions with another script is also trivial. modifying this script to assign permissions to a group is also trivial. – 4c74356b41 Jan 08 '20 at 07:54