First, here is some background about what Visual Studio Team Services (VSTS) can do concerning Azure Resource Manager (ARM).
As you probably know, Releases in VSTS has the capability to deploy build artifacts to subscriptions in Azure. Releases are configured through a list of tasks that performs the actual work, such as for example creating infrastructure with ARM-templates, or web-deploying applications to App Services.
VSTS lets you store connection details to Azure Subscriptions in Service Endpoints for later reuse in release tasks.
There are many Service Endpoint types, but the one of interest regarding ARM is the Azure Resource Manager Service Endpoint. When you create a new ARM Endpoint you enter its name, select one your Azure subscriptions in a dropdown, and if you are lucky, VSTS will create the connection. I will explain the prerequisites to be ?lucky? below.
The connection is actually an Azure application which use its service principal in the Azure Active Directory (Azure AD) to access subscriptions.
If you cannot find the subscription you intend to deploy to in the drop down, or if VSTS fails to create the endpoint, you can attempt to create it manually, either by creating the application and service principal by hand in the Azure Portal, or through the PowerShell API. Here is a blog post by Roopesh Nair that explains the procedure in more detail. It links to a PowerShell script that I have used on many occasions as a base when I had to set things up manually.
Manual or Automatic Creation
As you might already know, ARM service endpoints can only be shared within the team project where they are created. Since it takes a few minutes to get through the manual steps, I think that creating ARM Endpoints manually is a real pain, especially if your company use many team projects. I find it more beneficial to spend time to configure the subscriptions so that each user can let VSTS create the endpoints automatically for them, right when they are needed.
Automatic ARM Endpoint Creation Prerequisites
Here is a list of prerequisites that needs to be met to make VSTS able to create applications and grant subscription rights to their service principals. Some are more obvious than others.
- You must have an activated Azure Subscription (Duh!).
- Each subscription belongs to an Azure AD, and the account that you use to log into VSTS with needs to be present there.
- The account needs to be able to create an application in the Azure AD.
- The account needs to have the
*/readandMicrosoft.Authorization/*/Writepermissions in the subscription.
Creating an Azure Subscription
If you have a Visual Studio Subscription or a Windows Developer account, you can activate your subscription with free credits through https://my.visualstudio.com. If you intend to use the subscription for production, create a Pay-As-You-Go subscription, preferably as a free account to start with from https://azure.microsoft.com/en-us/free.
Adding an account from another Azure AD
Adding users to an Azure AD has become much easier in the new portal compared to how it was done in the old. Now you can add or invite users in the same dialog.
If you enter a user email that corresponds to the Azure AD domain, a new user will be created. If you enter an email belonging to another domain, an invitation will be sent out, and the account will be added as a guest. I find it convenient to assign users that I add to the correct groups right in the add dialog.
Allowing Creation of Applications in Azure AD
There is a setting named Users can register applications which is found under Azure Active Directory - User settings. If set to Yes, non-administrator users are allowed to add applications to the Azure AD. If it is set to No, then your user accounts which is going to be able to add VSTS ARM Endpoints will have to be assigned to the Global administrator directory role. To my knowledge, it is not possible to add applications with any of the Limited administrator directory roles.
If your Azure AD administrator is not fond of letting people creating applications as they like, my best advice is that you create a new directory for subscriptions, and that you add the user accounts that might create ARM endpoints in that as guests.
Guests users gets special treatment in Azure AD, and have a setting named Guest users permissions are limited which needs to be set to No to make them able to add applications. If it is set to Yes, it will not matter if you even assign the Global administrator role to the guest account. If you need to use guest accounts, this setting needs to be set to No. Period.
Assigning the User Access Administrator Role
The application service principals VSTS creates to use to connect to subscriptions gets Contributor rights by default. Because of this, the user that creates the ARM endpoint needs to be allowed to assign permissions in the subscription.
There are two default subscription roles that have the required permissions to do this, one is the Owner role, and the other the User Access Administrator role.
One way to archive this could be to assign the accounts as subscription co-administrators, which would grant them the Owner role. This would work, but gets tedious if you have many accounts that should be able to create ARM endpoints. What is easier is to grant the role you intend to use using a group, let?s say one named VSTS Endpoint Managers.
If you are really lucky, you have a colleague that already maintains a directory group that you can reuse.