You might want to grant different permissions to each persona. This document illustrates how to configure access control for Azure resources.
- Azure Resources Access Control
- Only Dev members
- No QA members
Reference:
| Group name | Permissions | Membership | Who |
|---|---|---|---|
| Project Collection Administrators | Has permissions to perform all operations for the collection. | Contains the Local Administrators group (BUILTIN\Administrators) for the server where the application-tier services have been installed. Also, contains the members of the CollectionName\Service Accounts group. This group should be restricted to the smallest possible number of users who need total administrative control over the collection. For Azure DevOps, assign to administrators who customize work tracking. |
Platform Admin |
| Project Collection Valid Users | Has permissions to access team projects and view information in the collection. | Contains all users and groups that have been added anywhere within the collection. You cannot modify the membership of this group. | Data Scientist |
- Dev members
- No QA members
Reference:
| Group name | Permissions | Membership | Who |
|---|---|---|---|
| Contributors | Has permissions to contribute fully to the project code base and work item tracking. The main permissions they don't have or those that manage or administer resources. | By default, the team group created when you create a project is added to this group, and any user you add to the team will be a member of this group. In addition, any team you create for a project will be added to this group by default, unless you choose a different group from the list. | Data Scientist |
| Project Administrators | Has permissions to administer all aspects of teams and project, although they can't create team projects. | Assign to users who manage user permissions, create or edit teams, modify team settings, define area an iteration path, or customize work item tracking. | Platform Admin |
| {team name} | Has permissions to contribute fully to the project code base and work item tracking. The default Team group is created when you create a project, and by default is added to the Contributors group for the project. Any new teams you create will also have a group created for them and added to the Contributors group. | Add members of the team to this group. | Data Scientist |
Simply Platform Admin should not give organization-level and project-level ADO permissions to QA team members.
Create two groups using Azure Active Directory.
| Group Name | Attribute |
|---|---|
| {team name} for Dev members | Main Engineering group who needs to tune data and use Azure Machine Learning |
| {team name} for QA members | Q&A teams who should access only test data |
Each group has the following access:
| Resource Name | {team name} for Dev members | {team name} for QA members |
|---|---|---|
| Subscription | Contributor | No Access |
| Resource Group for dev | Contributor | No Access |
| Resource Group for stage | Contributor | No Access |
| Function App "func-trigger-{BaseName}" | Contributor | No Access |
| Storage Account for dev | Contributor | No Access |
| Storage Account for stage | Contributor | Reader |
- Not see the details on Azure DevOps and Azure ML
- Run a performance experiment pipeline
- Add/Delete test data to/from folders "test-pcm", "test-meta"
- See experiment results on Azure Dashboard
- Receive notifications when experiment is started and ended via email/Microsoft Teams/Slack.
- Access only specific folders for test data in storage
- Access Azure Dashboard to see performance experiment results
- Use managed service identity and Azure Function (HTTP trigger) to run a performance experiment pipeline with key and test config file path
*QA team cannot access to even Azure Function resource.
*Azure Function can access to AML with managed service identity.
Once you add an AAD group as contributor, people in the group can do almost anything for the resource.
Creating custom role is another option to achieve the requirement in order to reduce permissions for QA team as much as possible.
Please refer to the document - Create custom role to know more details.
Create four groups using Azure Active Directory.
| Group Name | Attribute |
|---|---|
| {team name} for Dev members | Main Engineering group who needs to tune data and use Azure Machine Learning |
| {team name} for QA members | Q&A teams who should access only test data |
Each group has the following access:
| Group Name | Data - Test Data | Data - all others |
|---|---|---|
| {team name} for Dev members | ✅ | ✅ |
| {team name} for QA members | ✅ | ❌ |
Each setting for QA team is below:
| Resource | Role |
|---|---|
| Subscription | No Access |
| Storage Account for dev | No Access |
| Storage Account for stage | Reader |
| Container - shared (storage account for dev) | read/execute |
| Folders - Test Data (storage account for stage) | read/write/execute |
Note: The timing of setting above should be before creating other folders.
Create four groups using Azure Active Directory.
| Group Name | Attribute |
|---|---|
| {team name} for Dev members | Main Engineering group who needs to tune data and use Azure Machine Learning |
| {team name} for QA members | Q&A teams who should access only test data |
Each group has the following access:
| Resource Name | {team name} for Dev members | {team name} for QA members |
|---|---|---|
| Subscription | Contributor | No Access |
| Resource Group | Contributor | No Access |
| Dashboard for Dev team | Contributor | No Access |
| Dashboard for QA team (experiment result) | Contributor | Reader |
What QA team should do:
- See experiment results on Dashboard
QA team does not need to have access to subscription and resource groups, need to access only dashboard to see experiment results.
You can check who can access to key vault on "Access Policies" pane.
- Azure DevOps account (Check Azure AD account)
- Managed Identity for Azure Functions (if secrets from key vault (e.g. connecting strings) were added as not key vault link but just secrets to Azure Functions app settings on CI, managed identity not needs to be added)
- Person who manages secrets on Key Vault (Note: if person who is in access control list he/she can add himself/herself/anyone to Access Policy)