Access to Cost analysis in Azure Databricks managed resource group - azure

In our organization, we have a common Azure subscription with a separate resource group for each solution. I have Owner rights for my solution's resource group, but when we create Databricks workspaces, a separate managed resource group databricks-rg-*** is created which I don't have access to. To be able to manage our Azure costs, I need to have access to the Cost analysis section of this managed resource group. What role do I need in this resource group to be able to see the costs?

To be able to manage our Azure costs, I need to have access to the Cost analysis section of this managed resource group. What role do I need in this resource group to be able to see the costs?
To see the cost, the Reader role is enough. If you want to do other operations except reading, you need the role e.g. Contributor, Owner.

Related

Azure RBAC Permission

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.

Service principal or Managed Identity

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.

Azure policy to auto add user group in resource group contributors

This is my first project in Azure. Please avoid if any mistake. I have a user group "Azure Cross Team Contributors". I want to add it in resource group contributors by default whenever I create any resource group. I got to know there is policy, But not able to write policy rule. What would be policy rule for this scenario.
Similar thread answered on Microsoft Q&A , so updating here for broader community usage. Thank you AshishMishra and DCtheGeek for helping on the thread.
Azure Policy lets you audit the compliance of the configuration of Azure Resource Manager (ARM) properties.
In some cases, such as AKS or Guest Configuration, it can also audit configuration of Resource Provider properties. While Azure Policy can be used to audit how a role definition is defined (sample here), it isn't for applying roles to specific objects. That's the domain of Azure role-based access control (RBAC).
If you want the group "Azure Cross Team Contributors" to have access to all resource groups within a subscription, an easier alternative is to grant the role assignment at the subscription scope.
There isn't a built-in role with the name "Resource Group Contributors".
Feel free to revert back if you have any further queries. Thank you.

Terraform with Azure. Access rights best practices

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.

Azure Access Control for Resource Groups

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.

Resources