Octopus Azure Account without subscription ID

cloud

(Stewart) #1

Hello,

I want to store an Azure service principal for managing an Azure AD instance that doesn’t have any subscriptions associated with it, but the validation fails because the subscription ID field is empty. I’m able to log in to the tenant using Login-AzureRmAccount - and to include this in a pipeline with variable substitution but this isn’t ideal - which returns no subscription name/ID. I’ve also tried using the subscription the Azure B2C AD resource exists in, but this is in a different tenant so invalid.


(Shannon Lewis) #3

Hi Stewart,

Thanks for getting in touch. We’ve been bouncing this around a bit within the team today, it isn’t a request we’ve had before. Are you able to describe a bit more about your scenario and what types of things you are needing to manage in Azure AD, to help us understand the context fully?

Conceptually this type of account wouldn’t be compatible with any of the other functions we use Azure accounts for. I.e. an account without a subscription doesn’t make sense for deploying a Web App. If we add a new account type it may also make sense to then look at adding other things related to the scenarios it supports, so the more we can understand the scenario the better we can understand the full scope.

Regards
Shannon


(Stewart) #4

Hello,

Our requirement is to manage applications, users etc in AD that are required later in the pipeline using an account that has access in Azure AD to manage the directory, but not permissioned to any subscriptions as it doesn’t need to manage any Azure resources beside AAD. We use a separate principal for deployment that we don’t want to give access to AAD.


(Ben Pearce) #5

Hi Stewart,

You should still be able to achieve this scenario in Octopus today, but it does come with a couple of hoops to jump through and is not a currently supported scenario.

I am also working on an assumption that you already have the Azure AD accounts and scripts setup and working for your scenario.

On your Octopus Server you will need to install the Azure PowerShell modules, so that the script step has access to the Azure functions.
You can get around the validation on the Account Edit page by putting a fake GUID in the Subscription field, the PowerShell line [Guid]::NewGuid().ToString() | clip will generate a new GUID for you to the clipboard. Fill out the other fields with the correct values for your service principal.
In your project create a new Azure Account variable and select the account created above.

Create a new standard script step, this cannot be the Azure PowerShell step. In the script step add the following code to perform the login:

$securePassword = ConvertTo-SecureString $AzureAccountPassword -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ($AzureAccountClient, $securePassword)
Login-AzureRmAccount -Credential $creds -TenantId $AzureAccountTenantId -Environment "AzureCloud" -ServicePrincipal

You could also put the above code into a script module as a reusable function.
In each of the variables in the script, the $AzureAccount bit is the name of the account project variable. You will also need to set your -Environment parameter to the correct Azure Cloud if you are not using the default Azure Global cloud.

I have also raised an issue for this enhancement.

Hopefully, this helps you achieve the Azure AD management functions you are wanting to.

Regards
Ben


(Stewart) #6

Hello Ben,

Thanks for the feedback. I was already doing it a similar way in a Powershell script step.

Entering a random GUID seems to be working, but it is throwing an error as it seems to be validating it when saving. I’m able to see it in the list though afterwards so this is a better option for us than storing the credentials in variable sets.

I’ve subscribed to the github thread.

Regards,
Stewart