Role Setup for Installation in Microsoft Azure
This article provides access control requirements for deploying Avi Vantage solution in Microsoft Azure.
Overview
Azure Role-Based Access Control (RBAC) provides granular access to its resources. This enables configuring various users with IAM roles.
By default, Microsoft Azure has various built-in roles which define the level of access to the resources associated with it. For instance, the reader role has read-only access, where as, the owner role provides complete access.
In addition to built-in roles, Azure allows creating custom roles. Along with access permissions, custom role provides finer control over specific resources.
The Avi Vantage solution interacts with a multitude of objects in the user’s Azure subscription. This article provides guidelines on the permissions required for various objects to maximize security posture.
Role Requirements
The role requirements are defined for the following two stages:
Controller Deployment
The Avi Controller cluster needs to be deployed in a resource group where the controller admin has a role of contributor or higher.
Microsoft Azure Cloud Configured with Avi Vantage
In Azure, the Avi Controller interacts with various resources and manages their lifecycles.
These operations require specific permissions. The contributor role provides sufficient level of permissions when attached to the required resource groups. However, Avi solution requires permissions that is a subset of those granted by the contributor role.
Hence, it is recommended to use a custom role that provides appropriate level of access that are limited to the required resources.
-
The Avi Controller is configured to deploy Service Engines in a specific resource group that is tied to the user’s subscription. This user should have the contributor role for this resource group.
-
The deployed Avi cloud can provide load balancing services to a VNet present in a different resource group from the one mentioned above. In addition, Avi Controller uses the following resources in this resource group:
- If enabled during cloud configuration in the Controller, DNS zones to be used for Azure DNS.
- Scale sets and Azure VMs used as back-end servers.
Resource groups provide an easy way to manage access to a group of resources in Azure. It is recommended to provision Avi Controller cluster in a new resource group of its own, for better isolation. Service Engine VM instances and all other Azure resources that are dynamically created by Avi Controller can reside in the same resource group (for small deployments), or can exist in a resource group of their own.
The Avi Controller and Service Engines can be attached to an existing VNet for connectivity, independent of which resource group they reside in.
Deployment Scenario
Figure 1. Role definition in Avi Vantage deployment for Azure
Note: In Figure 1, Cloud Credential is a credential asset which could either be a service principle object, as in case of an application or an username/password credential set, as in the case of an user.
- The Avi Controller belongs to Avi Controller resource group. The Controller admin exercises his privileges to deploy the Avi Controller in this resource group.
- Avi Controller creates the required resources in the Avi Cloud resource group cloud resource group. The credential asset needs contributor or a role of higher access to the Avi Cloud resource group.
- The credential asset also needs custom role access to other resources, such as, VNet, DNS zones, and scale sets. This custom role helps define access to specific resources. Details on configuring custom role is provided in the following section.
- The Avi cloud and VNet resource groups are configured as a part of the credential asset.
Custom Role for Accepting Avi Service Engine SKU End User License Agreement
Starting with Avi Vantage release 18.1.4, the Avi Controller utilizes Avi Service Engine SKUs published in Azure Marketplace to instantiate Service Engines. There are separate SKUs for the two license models that Avi Vantage supports:
- Bring your own license
- Pay as you go
Microsoft Azure requires an one-time acceptance of software terms and conditions for each provisioned SKU based on subscription.
As the Service Engine SKUs are instantiated by the Avi Controller via the cloud credential, the cloud credential must be configured with a custom role at the subscription level.
The custom role requires the following permissions:
"Microsoft.MarketplaceOrdering/offerTypes/publishers/offers/plans/agreements/read",
"Microsoft.MarketplaceOrdering/offerTypes/publishers/offers/plans/agreements/write"
This custom role can then be applied to the cloud credential, at the subscription level.
After completing the Azure cloud configuration successfully, this IAM role assignment can be removed from the cloud credential.
Configuring Custom Role
The custom role can be configured using Azure CLI, PowerShell, or REST API. For more details on Azure CLI, refer to Manage Role-Based Access Control with the Azure CLI.
Configuring Custom Role for Azure Autoscaling
Azure autoscaling needs more permissions in addition to read only access. Create a new role using this JSON file and assign this role to existing roles.
Configuring Avi Controller Role for Ongoing Operations
Avi provides custom role definition under the name Avi Controller. This can be downloaded from the location here.
Once the role has been created, it can be assigned to the resource groups that are managing Avi deployment.
Configuring Avi Marketplace Role for Accepting License Terms
Avi provides this custom role definition under the name Avi Marketplace, This can be downloaded from this link.
Once the role has been created, it can be assigned to the cloud credentials at the subscription level.
Resource Group Recommendations
- The Avi Controller cluster should be deployed in a separate resource group, earmarked for this purpose.
- Each VNet that is configured in Avi Controller should be deployed in its own resource group.