Azure Role-Based Access Control (RBAC) and PowerShell - Marcin Gastol
15630
post-template-default,single,single-post,postid-15630,single-format-standard,bridge-core-3.0.7,bridge,qode-page-transition-enabled,ajax_fade,page_not_loaded,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-29.4,qode-theme-bridge,qode_header_in_grid,wpb-js-composer js-comp-ver-6.10.0,vc_responsive
Full 3
Marcin Gastol
DevOps • Azure • Python • AI & ML • Security

Full 3

Azure Role-Based Access Control (RBAC) and PowerShell

Introduction to Role-Based Access Control (RBAC)

RBAC stands for “Role-Based Access Control,” and here is how it works.
Access control is an essential component of data protection in any setting, regardless of whether the infrastructure in question is located on-premises or in the cloud. The Role-Based Access Control (RBAC) method is now becoming more used as an approach to access management. RBAC stands for role-based access control and is a policy-free access control method that centers on roles and privileges. It limits access to just those people inside an organization who are allowed to use it.

The responsibilities that various users play within an organization are taken into consideration when RBAC makes judgments about access permissions. Users take on the roles that have been allocated to them, such as administrator, supervisor, or employee, and these roles are subject to permissions (such as read, write, and execute). This concept helps to simplify access management by enabling administrators to control permissions for roles, which can then be delegated to individual users, rather than having to manually manage permissions for each user.

RBAC on Azure: A Brief Introduction


Azure Role-Based Access Control, or Azure RBAC, is an authorization system that was built on Azure Resource Manager and offers fine-grained access control of Azure’s resources. Azure RBAC was given the acronym “Azure RBAC.”

With Azure RBAC, you can divide up the tasks that each member of your team is responsible for and allow just the level of access to users that they need to carry out their obligations. You don’t have to provide unfettered access to everyone to use your Azure subscription or resources; instead, you may choose to let just specified activities be performed. For instance, using Azure RBAC, you may provide the ability to manage virtual machines in a subscription to one employee while allowing another employee to manage SQL DBs inside the same subscription to a different employee.

Azure RBAC comes with a lot of pre-configured roles, each of which may be assigned to a resource, management group, subscription, resource group, or individual resource at a variety of different scopes. One example of this would be the “Virtual Machine Contributor” position, which gives the user the ability to construct and administer virtual machines. You may also design your unique roles for special needs!

PowerShell administration of Azure RBAC roles and permissions


You can manage the resources you have in Azure by using PowerShell, which is a sophisticated toolset that you can use through the PowerShell command line. There are a lot of PowerShell cmdlets available for handling Azure, and Azure RBAC is not an exception to this rule.

Appointing Someone to a Role


You may make use of the New-AzRoleAssignment cmdlet in order to delegate a role to a user. A user with a particular user principal name (UPN) may be given the “Reader” role inside the subscription scope by executing the following command:

PowerShell
New-AzRoleAssignment -SignInName user@domain.com -RoleDefinitionName "Reader" -Scope "/subscriptions/<SubscriptionId>"

Demo: Real use case scenario

Now to make some fun of using that, let’s take a look at a real-world application that illustrates the capabilities of Azure RBAC’s role-based access control.

Take for example the firm Garson IT Ltd., which maintains a significant presence on Azure. The Azure environment that Garson utilizes is rather broad, as seen by the presence of numerous subscriptions, each of which houses a number of resource groups and resources. Their information technology department is made up of a few different teams, including Infrastructure, Database, and Development.

The goal of Garson IT Ltd. is to implement the concept of least privilege, which is providing each team with just the rights that are essential to the completion of their task and nothing else. They come to the conclusion that PowerShell and Azure RBAC will be the best tools for doing this.

Infrastructure Team


Management of virtual machines and network configurations falls within the purview of the Infrastructure team. Garson makes the decision to provide them with the ‘Contributor’ role at the subscription level. This provides them with the ability to manage all resources but does not provide them with access to assign roles in Azure RBAC.

They execute the following using PowerShell.

PowerShell
New-AzRoleAssignment -ObjectId <InfrastructureTeamGroupId> -RoleDefinitionName "Contributor" -Scope "/subscriptions/<SubscriptionId>"
New-AzRoleAssignment -ObjectId <DatabaseTeamGroupId> -RoleDefinitionName "SQL DB Contributor" -Scope "/subscriptions/<SubscriptionId>/resourceGroups/<DatabaseResourceGroup>"
New-AzRoleAssignment -ObjectId <DevelopmentTeamGroupId> -RoleDefinitionName "Reader" -Scope "/subscriptions/<SubscriptionId>"

Database Team

The Database team is tasked with managing SQL databases. They are given the ‘SQL DB Contributor’ role at the level of the resource group containing the databases.

PowerShell
New-AzRoleAssignment -ObjectId <InfrastructureTeamGroupId> -RoleDefinitionName "Contributor" -Scope "/subscriptions/<SubscriptionId>"
New-AzRoleAssignment -ObjectId <DatabaseTeamGroupId> -RoleDefinitionName "SQL DB Contributor" -Scope "/subscriptions/<SubscriptionId>/resourceGroups/<DatabaseResourceGroup>"
New-AzRoleAssignment -ObjectId <DevelopmentTeamGroupId> -RoleDefinitionName "Reader" -Scope "/subscriptions/<SubscriptionId>"

Development Team

The Development team needs to view resources to understand the structure and status, but they don’t require permissions to change anything. Thus, they are assigned the ‘Reader’ role at the subscription level.

PowerShell
New-AzRoleAssignment -ObjectId <InfrastructureTeamGroupId> -RoleDefinitionName "Contributor" -Scope "/subscriptions/<SubscriptionId>"
New-AzRoleAssignment -ObjectId <DatabaseTeamGroupId> -RoleDefinitionName "SQL DB Contributor" -Scope "/subscriptions/<SubscriptionId>/resourceGroups/<DatabaseResourceGroup>"
New-AzRoleAssignment -ObjectId <DevelopmentTeamGroupId> -RoleDefinitionName "Reader" -Scope "/subscriptions/<SubscriptionId>"
No Comments

Post A Comment

Verified by MonsterInsights