I have some build tasks that should be ran against resources located in different Azure subscription. In order to have only one build definition to maintain, i need to be able to parameterize the Azure Subscription field.
For the moment, i have to duplicate the original build definition and only change the subscription in each one, that is painful ti maintain.
The sample below does not work. I tried with the subscription ID, the subscription name, connected service name...
How can i do that ?
It's already supported by VSTS.
Here are the steps to follow:
Create a release definition with Azure resource group deployment tasks.
In all tasks, choose a valid endpoint. You’ll need to do it multiple times and a variable cannot be used here
Create a task group with the tasks above. It would not have Azure subscription as a parameter.
Go to the task group and for each task in the group, you can update the subscription to $(AzureSubscription)
On saving of the task group, the Azure subscription would be bubbled up a as a parameter
You can’t parameterize Azure subscription field in build or release.
There is a similar user voice that you can vote and follow up: Allow service connections to be parameterized in task groups
Related
How can I use the same organization name for my azure kanban boards and my azure pipeline?
when I want to register for azure pipeline, it tells me the organization name is already taken.
The problem is that if we want to launch Kanban boards or pipelines for the first time, we should follow the steps defined in official documentations and for each of them we have to create an organization name, since I have already created my Kanban boards, I couldn't define the same organization name for the pipeline too.
I was expecting that it can recognize this is the same organization as I logged in with the same username, but it couldn't.
The solution I found is that if we have already created Azure boards for an organization and we want to have pipelines for it too, we can add it by going to the Microsoft Marketplace and installing the required extensions such as Azure Pipelines.
I have resource group that is named "VisualStudioOnline-" and inside there is a single resource as given below. Looks like Azure DevOps created it. What is it used for and can I delete it?
PS: I would need to continue use the DevOps organization and projects.
You can navigate to https://dev.azure.com/ and delete the organization from there or you could hit the following url and delete it,
https://dev.azure.com/{ORGANIZATION_NAME}/_settings/
replace ORGANIZATION_NAME with actual value
I don't think you can delete it if you want to keep your Azure Devops environment. As far as I know, billing for Azure Devops needs to be linked to a certain Azure subscription, hence the appearance of the organization in your subscription.
note
I believe it is possible to move the organization to another subscription though (from within Azure Devops UI >> organization settings >> billing >> 'change billing'). This will link the billing for your Devops to the other subscription.
I have never done this myself, but perhaps the resource would then also be moved to the other subscription?
How can we run one Azure Automation runbook for all our subscriptions in the same tenant? Currently, I am making use of one runbook which retrieves the resources in the tenant, but it is listing the resources only from one subscription whereas I have 3 subscriptions present.
How do I make sure it outputs all the resources from all subscriptions? Please help
The problem is that the runbook runs in the security context of an Azure automation account and that account is connected to a subscription and therefore only sees resources within that subscription.
https://learn.microsoft.com/en-us/azure/automation/automation-create-standalone-account
There is a "Azure management group" which works cross subscription
https://learn.microsoft.com/en-us/azure/governance/management-groups/overview
It may be possible to run the runbook in a context of a management group user that has access to all subscriptions. But I have never tried this so not sure if it would work.
I would suggest that you install and run the runbook in each subscription. Then combine the contents of each report.
We provide a library of custom Azure DevOps tasks (Azure DevOps extensions provided through a private Visual Studio Marketplace) to our stakeholders in order to provision resources to Azure. Many times we need to switch an elevated service account to perform operations that are not allowed by the service principal of the Azure service connection, e.g. adding users to groups, or reading secrets from a central key vault.
What is the best way to establish this security context securely? Currently we have the credentials of this elevation service principal hard coded in our task code. Unfortunately this is easily retrieved by our stakeholders because the code is readable within the same Azure DevOps job context, so it is not safe.
Does Azure DevOps provide a special task context that we can utilize to encrypt the service principal credentials somehow? Are there any other routes to securily perform operations from a centralized security principal from within these custom tasks of ours?
If you're using classic Releases you can define variables that you can reference in your steps with the syntax $(variableName). Variables can be made secret, so it's not possible to retrieve them.
Alternatively, if you're using yaml multi-stage pipelines then variables can be defined directly in the yaml. In this case you'll probably what to use a variable group so that you define the secrets either directly in the variable group or link to a key vault.
For the requirement of not allowing new pipelines to be set up to use variable groups you could investigate the Library assets security roles and / or putting your pipelines in a separate Azure Devops project within your organisation.
Depending on what your tasks are doing you might be able to rewrite them to use a task that makes use of the built in Azure Resource Manager service connection, for example the AzurePowerShell#4 task, rather than using your own service principal credentials, as another solution entirely.
First thought is that as soon as pipelines are capable of accessing
the secrets then we are bad.
Not sure if I understand you well. But if you don't want those stakeholders to access the secrets in your task context within some specific pipelines, you can consider combining the Variable Group and Pipeline Security.
1.For Library(Variable Group): Store the secrets here and enable Change variable type to secret. Then manage its security here:
Normally the stackholders can't access the variable group unless you grant access to them. I suggest you create a group to manage the permissions of those stackholders.
2.For pipelines: You can limit the view/edit related permissions in pipelines' security:
For all pipelines:
For one specific pipeline:
You can deny the View/Edit related permissions and only allow Queue build permission so that the stackholders can run your build but not see details about how you define the task context:
Hope it helps :)
A Devops pipeline is linked to one subscription. Is it possible to access resources in multiple subscription from one task in a pipeline?
Is it possible to access resources in multiple subscription from one task in a pipeline?
AFAIK, I do not think it is possible to access resources in multiple subscription from one task.
Just ask you know, we could only link one subscription in one task:
If deployed to multiple environments, we could create a Release pipeline with multiple environments. Then add Deploy task for every environment and choose different Azure Service Connections in different environment. Then you could deploy one app to different Azure environment through one release pipeline.
Hope this helps.
This should be doable with light house configurations.
https://adatum.no/azure/multi-subscription-deployment-with-devops-and-azure-lighthouse
You would have to create a new azure devops SPN. You can then in turn give this SPN account via light house access to the subscription.