There isn’t an Azure Data Factory Reader role unless you create an Azure Custom Role. Having a Reader role comes in handy. You certainly don’t want to give everyone access to creating and developing Azure Data Factory solutions.
I believe it’s really important to spend some time creating this role. In this post, you will see how to create a custom reader role. This article is valid for the creation of any other custom role. You can define what you need for your specific service.
The contents of this blog post:
- Introduction to Azure Custom Roles
- Definition and creation of the Azure Data Factory Custom Reader Role
- Testing the Custom Role
- What if the GIT repository is enabled?
Introduction to Azure Custom Roles
In order to create Azure Custom Roles you need to be an Owner, a User Access Administrator or be granted the ‘Microsoft.Authorization/roleDefinitions/write’ permission to create custom roles.
The good news is that you can create them using PowerShell libraries and up to 5000 per directory.
You can also look at the existing roles to explore if you can re-use one or if it already exists.
In the case of Azure Data Factory, there is only a contributor which is aimed at data engineers who are going to develop solutions.
Once that you create a role, you can find it using the filters.
In addition, you can also modify it if required.
Definition and creation of the Azure Data Factory Custom Reader Role
During the creation of the custom roles, you need to configure the following options:
Define a name. Choose if you want to start creating a role from scratch, from an existing one or to import a JSON definition custom role file.
Time to define the permissions.
One thing I’ve found is there is a well-defined naming convention for the permissions. First, choose the Azure Data Factory provider.
You can filter by using a keyword. In this example I’ve used the word ‘read.’
After you define the permissions, you’ll see them in the window.
Here you can define if the scope of the permission is at the subscription or resource group levels.
In this section, you can download the JSON definition file for code version control and re-use it if necessary.
Review and Create
The last section displays a summary. Finally, the creation of the role is executed.
Testing the Custom Role
Now we need to test the custom role. Assign the role to a different user.
In the following images, you will see that I am connected with the user that has been assigned to the new ADF_Reader role.
The next step is to try to delete a dataset!
It seems that it has been deleted successfully.
But this is just a local copy. Once we try to publish the changes, the permission will be denied.
What if the GIT repository is enabled?
If you have GIT enabled, the users who don’t have access to the GIT repository won’t be able to publish the changes either.
I suggest removing access to the GIT repository for the users who you don’t want to make changes.
The user will see the following alert when they enter Azure Data Factory.
Having some control over defining our Custom Azure Roles is easy and allows you to meet specific needs within your environment. The input for defining the roles needs to come from the application and technical stakeholders in collaboration with security and infrastructure teams. Not even the best Azure administrator will be able to achieve the required organization roles for a company.
It’d be nice to have some default reader roles created in Azure for the different services. The creation of the role is not a time-consuming activity but it needs to be documented and included as part of any robust environment.
See my previous post on Azure Synapse Analytics Serverless here.
Mark Kromer01 . 07 . 2020
Well done, thank you so much for this!
David Alzamendi03 . 07 . 2020
Thanks for the feedback Mark 🙂
Henry18 . 02 . 2021
Hi, thank you for this. I wanted to add an update after testing this out myself. Although you cannot publish, the changes you have made will be updating the Azure DevOps Repository (assume you have GIT enabled) – which is not very ideal. I was wondering if you were able to find a configuration which will suppress even the update into workspace? Cheers.
David Alzamendi27 . 02 . 2021
Thank you for your feedback. If you have GIT enabled, the users who don’t have access to the GIT repository won’t be able to publish the changes either. I suggest removing access to the GIT repository for the users who you don’t want to make changes.
Let me know if I can expand my info or this does not work for your scenario.
Mac28 . 09 . 2022
Thanks and keep up the god work. One question, after implementing the solution I see that users with the custom role assigned have rights to create/delete and save Pipelines within the Data Factory. They can’t publish anything, as expected, but they can manage pipelines which is something we are trying to prevent. I’m I seeing this correctly? If so, what can we do to fix it?. Best