Author: admin

If you think of from an organizational perspective, there will be
multiple accounts, and there will be multiple subscriptions meant for different environments and workloads.

Using management groups, you can logically group subscriptions. This way, management groups offer a new scope above the subscriptions, which can be used for granting access, assigning policies, and analyzing costs.

All access or policies assigned to the management group will be inherited to the subscriptions that are part of the management group.

Management groups enable administrators to do the following:

• They can logically group subscriptions into different containers.
• They can apply policies and access a set of subscriptions easily.
• Cost management can be scoped at the management group level for tracking the costs of multiple subscriptions in a single shot.
• Budgets can be created at the management group level, which is ideal for teams and projects having multiple subscriptions.

Management groups can be created from the Azure portal, PowerShell, and the CLI. There will be a default management group that will be provisioned along with your tenant called the root management group. All new management groups will be created as children of this root management group.
Creating a management group is a straightforward process you can perform by searching and navigating to management groups in the Azure portal

Two parameters are required while you create a management group. The first one is Management Group ID; this identifier is used to denote the management group when you want to run commands against the management group.

Second, you need to add a display name, which will act like a friendly name for your management group. Whenever you are making PowerShell, Azure CLI, or REST API calls, you will be using the identifier to point to the management group.

*Management Group ID cannot be modified once the management group is created.
To management groups, can be leveraged to apply policies and grant access easily on a larger scope.

Each tenant represents an organization, and it is a fully independent resource. Every tenant that you create is logically separated from other tenants that you manage in a multi-tenant environment. Even if you are the common administrator for all these tenants, there
will not be any parent-child relationship between these tenants or directories.

Resource independence, administrative independence, and synchronization independence are there between the tenants.

Resource independence is when you create or delete a resource in one tenant; this action will have no impact on any other resource in another tenant.

However, there is a small exception that we discussed in the case of cloud identities from external directories . By default,
Microsoft Azure Entra directory doesn’t delete Guest users when they are deleted from their home tenant; however, we can set this up manually.

Administrative independence is when a non-admin user (say the user’s name is John) of tenant A creates a new tenant, say tenant B.

• John will be the Global Administrator of the tenant B as he created the new tenant. The user will be added as a user from external Directory. Here it says external tenant directory, because John is not from tenant B but from tenant A.
• Administrators of tenant A have no control over tenant B. If the users of tenant A need to access or manage tenant B, then John must invite these users to tenant B and give the necessary role. One thing to note here is that if the admins of tenant A takeover John’s account, they can access tenant B.
• Adding or removing an admin role in one tenant will not affect the role of the user in the other tenant. Here we’re not removing the user; we are adding or removing the Azure directory roles, which will have no impact on the other tenant, and all roles the user has in the other tenant will be retained.
• When it comes to synchronization independence, you can set up independent synchronization on each Azure Directories.

This post is focused on managing Role-Based Access Control (RBAC), and we’ll see what RBAC is and how to apply it at the different scope levels. We will also cover how to create and assign custom RBAC roles and how to interpret RBAC roles within the Azure portal.

In brief, the following topics will be covered in this chapter:

• Creating a custom role
• Providing access to resources by assigning roles at different scopes
• Interpreting access assignments.

Creating a custom RBAC role

RBAC is a general term used for restricting access to users, based on a role. It works on the Just Enough Access (JEA) concept where a specific user/group will be provided minimum access to perform their specific job on a specific resource. Custom roles can only be created and updated by a user who has the following role assigned: Microsoft. Authorization/roleDefinitions/write permissions.

When it comes to RBAC, it is very important to understand how and where it is applied. Azure RBAC can be applied to the following security principals:

• User

• Group

• Service principal

• Managed identity

Now that we know what security principals support RBAC, the next step is to have a look at role definitions. A role definition is a collection of permissions that can be applied to security principals; however, in Azure, this is referred to as a role. A role is what determines what operations are allowed – for example, read access, write access, or the deletion of resources.

The following are some built-in roles within Azure:

• Owner role: This is the role that includes all permissions; you can read, add, and remove resources. You also have the capability to add and remove other users to and from resources as owners or other roles.

• Contributor role: This role has the same permission as an owner, except you cannot add or remove additional users to and from resources.

• Reader role: This role has the ability to view resources, but cannot amend, add, or remove users or resources.

Moreover, there are multiple built-in roles within Azure, and it is recommended that you have a look at them: https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles.

The next part is to understand scope. Scope is the target resource that you need to assign a role to. In Azure, there are mainly four scope levels that roles can be assigned to:

• Management group

• Subscription

• Resource group

• Resource

The following diagram displays the main scope levels in Azure:

In summary, RBAC consists of three main sections:

• Security principal: Selects who is going to have access

• Role: Selects what type of access is going to be assigned to the security principal

• Scope: Selects the resource that the user and the role will be applied to

Now that we understand built-in RBAC roles within Azure, let’s take a look at custom RBAC roles. Custom RBAC roles can be created if the built-in RBAC roles do not meet specific requirements.

Custom RBAC roles can be created in the following ways:

• The Azure portal

• Azure PowerShell

• The Azure CLI

• The REST API

In this section, we had a look at RBAC in Azure and how it works from a logical perspective.

let’s see how to create a custom role.

Creating a custom role

Let’s go ahead and use the Azure portal to create a custom RBAC role from scratch named IT Support – Restart VMs only, which can only restart virtual machines and deny the startup and shutdown of them:

1. Navigate to the Azure portal by opening a web browser and browsing to https:// portal.azure.com.

2. In the top section search bar, search for and select Subscriptions:

3. Select an active subscription; in my case, this will be the Azure subscription 1 subscription, as seen in the following screenshot and click on it:

4. Next, under the Basics tab, enter the custom role name and description and select the Start from scratch setting under Baseline permissions. Under Custom role name, specify IT support – Restart VMs only; it is also best practice to provide a brief description in the Description field when creating resources in Azure:

5. Next, we need to specify the permissions. Click on the Add permissions button, and in the search bar that pops up, search for Virtual machines and select Microsoft Classic Compute:

6. A new blade will pop up with all the compute permissions. Scroll all the way down to Microsoft.Compute/virtualMachines and select Read: Get Virtual Machine and Other: Restart Virtual Machine, and then click Add:

7. Next, we need to exclude this role from starting and shutting down virtual machines. Click on the Exclude permissions button and search for Virtual machines again, and then select Microsoft Compute:

You will notice that the new role now has the following permission types:

• Action: Read the Virtual Machine (VM).
• Action: Restart the VM.
• NotAction: Start the VM.
• NotAction: Shut down the VM.

Click on Next.

10. Next, we have Assignable scopes, where we can choose where this custom role will be available for assignment. In this scenario, we are going to leave it at the default subscription level that was automatically added and then click on Next:

11. Next, we have the JSON tab, which shows the permissions for the new role in JSON format; we also have the ability to download the JSON code. For now, let’s click on Next:

12. The last tab is the Review + update tab, which is a summary of our configuration; click on Create:

13. A new pop-up window will appear, stating that the new custom role has been created and that we can start assigning the role as soon as replication has taken place, which is usually around 5 minutes or less.

In this section, we have created a custom RBAC role via the Azure portal from scratch, which only allows a VM to be restarted and blocks any start or shutdown attempts on a VM.