0

I have a VSTS release pipeline which provisions a new function app with a Managed Service Identity. My solution includes a shared key vault instance for my app secrets. Key vault allows a maximum of 16 access control entries so I've taken the approach of creating an Azure AD group for applications which I will add application service principals to. All straight forward and workable in PowerShell locally, but I'm not able to figure out a way to do this using hosted build servers in the VSTS release pipeline and a Run Powershell In Azure release task.

The Azure CLI is at version 1.X on the Hosted build server and 2.x on the Hosted 2017 build server * 1.x doesn't appear to offer AD group manipulation or graph API access * 2.x does offer az ad group member add but the hosted 2017 build has a problem with New-AzureStorageTable which is used elsewhere in my pipeline, so I can't use it

Similarly, the Azure RM powershell module on the Hosted build server is very old and doesn't appear to support group membership manipulation. The version on the Hosted 2017 server (which I can't use) has commands like Get-AzureRmADGroup but nothing to add a user to that group.

The cmdlet Add-AzureADGroupMember, available in the AAD powershell would be a nice solution, but it's not available on either the Hosted or Hosted 2017 build servers.

I've considered both automation runbooks and direct HTTPS posts to the graph API using the OAuth token available in the release pipeline, but want to stay with PowerShell to keep the number of technologies in my release pipeline as small as possible. I'd also prefer to avoid storing credentials in a secured manner for use in a PowerShell command like Login-AzureRmAccount and rely on the identity of the Service Endpoint I defined for my release pipeline.

Suggestions appreciated.

Josh
  • 4,009
  • 2
  • 31
  • 46

1 Answers1

0

Since the Hosted agent can’t meet your requirements, you can configure a private build agent (it’s free) on your machine: Deploy an agent on Windows.

Regarding Add-AzureADGroupMember cmdlet, you can install it by calling Install-Module -Name AzureAD through Azure PowerShell task, which works fine on Hosted agent.

Script:

Install-PackageProvider -Name NuGet -Force -Scope CurrentUser
Install-Module -Name AzureAD -Force -Verbose -Scope CurrentUser
starian chen-MSFT
  • 33,174
  • 2
  • 29
  • 53
  • Right, but I'm not interested in taking on build/maintenance/cost of a VM for my build pipeline if there is a programmatic PAAS option. – Josh Dec 27 '17 at 02:05
  • You can call Add-AzureADGroupMember cmdlet on Hosted agent, check the update of my reply. – starian chen-MSFT Dec 27 '17 at 05:14
  • I thought I had tried that, but did it again. Install-Module isn't allowed: `Administrator rights are required to install modules in 'C:\Program Files\WindowsPowerShell\Modules'` – Josh Dec 27 '17 at 14:22
  • BTW, the error message suggests adding `-Scope CurrentUser` to install the module in the builduser's directory, but that approach fails with `Install-NuGetClientBinaries : Exception calling "ShouldContinue" with "2" argument(s)` – Josh Dec 27 '17 at 14:40
  • I updated the reply, try again and check the result. – starian chen-MSFT Dec 28 '17 at 01:39
  • Yes, thank you for solving that piece of the pie. Sadly, I came across [another post of yours](https://stackoverflow.com/a/46578937/31299) confirming that my overall goal isn't possible in the release pipeline. Would be nice to be able to assume the identity of the SvcPrincipal we created as a contributor in the subscription and manipulate the AD. Don't like the idea of having a clientid/secret stored somewhere that can be copied out to notepad – Josh Jan 06 '18 at 02:36