there is use-case I am looking for solution. Assume I am assigning RBAC - Owner role to user(xxx) at subscription level. But now I need to exclude this permission to one of the resource group under this Subscription. Is that feasible?
No. Azure RBAC permissions cannot be removed like that.
Owner at subscription level means Owner on all resource groups and resources under it.
You need to assign the roles at resource group level if you want to restrict them there.
The other option is to separate the resources to a different subscription.
Related
I have a client that can only give me full access to one or two resource groups.
I need to deliver some prescripted terraform resources that contain the need for a service principal.
Can you lock an SP to a resource group? The subscription itself is a production subscription so they want to know if you can tie down using role base access just to that group.
Or should I be create a MI account?
Can you lock an SP to a resource group?
You most certainly can. Azure Role-based access control is very granular and you can apply access control at any level (management group, subscription, resource group or even at individual resource).
Please see this for more details: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-steps.
What are the best practices when using Terraform to provision infrastructure on Azure? We are struggling to decide between two variants:
Create one Service principal for Terraform and give it Owner rights to the whole subscription so it can create resource groups for each environment and assign roles to service principals in resources.
Create Resource Groups and service principals for each environment manually and assign terraform's service principal Owner rights to only the Resource Group.
The first option is more convenient, but I'm worried about security concerns when giving Terraform Owner rights on the subscription level.
What would be the best solution?
When you worry about security, there should be a limit to your requirements. If you want to create resources only in one resource group or serial resource groups, and then control them for all things. I'd suggest you create a service principal and assign it the Owner role of the resource group or groups, not the whole subscription. And it's the best way for security and you also have all the rights to control the resources in that group or groups, only limit the scope to that group or groups.
Assign the Owner role to the whole subscription, it's not secure, you know, there would be some mistakes on somebody sometimes.
I would like to give members of a specific role the ability to create resource groups. Can this be achieved without giving users the co-owner role at the subscription level?
You can grant them contributor rights on the specific Azure subscription, they don't have to be co-owner. This is the least-privilege built-in role available that allows you to create resource groups.
However, you could also create a custom role with only one action:
Microsoft.Resources/subscriptions/resourceGroups/write
Read more here: Custom roles for Azure resources
I have a Subscription in my company that is shared for all members of the team (all employees).
We use this subscription for test, dev and also production workloads.
We have only one subscription because it is a sponsored subscription thanks to our MS partnership, so we don't want to create other subscriptions.
I want to restrict the access to a particular resource group that will host production resources where sensible data will be managed.
Because all members of the teams are contributor in the subscription level, they have access to all resource group and I can't remove them from the resource group.
So how can I proceed if I want to revoke their access to the resource group and allow them to use all other resource groups?
So how can I proceed if I want to revoke their access to the resource
group and allow them to use all other resource groups?
AFAIK, Only way to do so is remove the users role (Contributor) at the subscription level and assign them at each resource group (other than production resource group). If a user has a higher role (say Contributor) at subscription level, then you can't assign a lower role (say Reader) at resource group level.
Essentially with Azure RBAC, when you grant access at a parent scope, those permissions are inherited to the child scopes.
You can read more about Azure RBAC here: https://learn.microsoft.com/en-us/azure/role-based-access-control/overview#how-rbac-works.
I am assigned an owner role in my Employer's Azure subscription. He was able to create resource groups, but I can't. We're both wondering why since I was already assigned as Owner, the highest role aside from subscription level.
When I try the az group create --name myGroup -l southeastasia command, its response is
The client 'live.com#<myAccount>#outlook.com' with object id '<object ID>'
does not have authorization to perform action 'Microsoft.Resources/subscriptions/
resourcegroups/write' over scope '/subscriptions/<subscription>/resourcegroups/<myGroup>'.
Edit: I have no subscription level resources
Do you have multiple subscriptions in your tenant? If yes, you should set it.
##list subscription
az account list --output table
##change the active subscription
az account set --subscription "My Demos"
If you only have a subscription, I suggest you could create a sp, then use the sp to create a new resource group. See this link.
Update:
You should give Owner role on subscription level, according to your screenshot, you give Owner role on resource group role, you only create resources in the resource group. You also could not create new resource group. You should give Owner role to your subscription,like below:
Note: This issue is more likely to happen in newer subscriptions and usually happens if a certain resource type has never been created before in that subscription.
Subscription admins often fix this issue by granting resource group owners contributor rights on the subscription level which contradicts with their strategy of isolating access down to the level of resource group level not the subscription level.
For root cause and quick resolution, refer "Common problem when using Azure resource groups & RBAC".
Well, the error clearly says you dont have rights over the scope, so you are either owner of the wrong sub or you have a role that specifically restricts that.