Restricting Azure Service Principals for Aviatrix
As Aviatrix provides orchestration of native cloud constructs when building customer environments, certain access permission must be granted to the platform in order to perform these activities. In the case of Azure, this access is provided via service principals. These service principals allow the Aviatrix platform to perform actions such as VNet creation, peering establishments, and UDR management within the subscriptions.
The first step after launching a controller is onboarding the subscriptions using a service principal defined for Aviatrix. For most customers, the easiest method is by creating a service principal and granting 'Contributor' level access to the subscriptions. Some customers may desire to be more granular with the permissions assigned to the service principal and define custom roles. For these customers, Aviatrix has documented the required permissions which can be found here.
In addition to locking down the service principal permissions, some customers may also want to further restrict the Aviatrix service principal to specific resource groups. Doing this ensures that the Aviatrix service principal only has access to defined resource groups to make changes and orchestrate configurations. This approach does come with tradeoffs as it requires more manual configuration and may result in reduced functionality if permissions are not assigned appropriately.
This video discusses the details of restricting the Aviatrix service principal to specific resource groups while leveraging custom roles. It is highly recommended to consult an Aviatrix Solutions Architect when trying to implement this type of deployment.