In the Azure DevOps user interface, one can edit the list of Pipelines that are authorized to use a Service Endpoint (aka Service Connection). This list can be retrieved from the API using:
GET https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{id}/resources
which lists resources that the pipeline is authorized to use.
All I see in pipelines' resources are "endpoint"s (Service Connections) and "queue"s (Agent Pool, I guess). But not Environments. We absolutely have Environments that specific Pipelines are authorized to use.
How do I get this information using the Azure DevOps REST API?
I'll admit, this is not very intuitive. I've done this a handful of times and it took me a bit to remember how exactly to do this. The documentation for this is under "Distributed Task".
The endpoint you are looking for is Pipeline Permissions - Get:
GET https://dev.azure.com/{organization}/{project}/_apis/pipelines/pipelinepermissions/{resourceType}/{resourceId}?api-version=7.0-preview.1
In your case, the resourceType should be environment and the resourceId should be the ID of the environment you want to query for.
To query for IDs of your environments, you will need to the use the Environments - List endpoint. Be careful with the term "environment" in Azure DevOps as there is a legacy "Release Environment" and the modern "Pipeline Environment". The link I put for the list environments endpoint is for the Pipeline Environments.
Related
i am implementing CI/CD pipeline that needs to register an AAD Application with permissions to read/write into Site collections, this would mean that the pipeline itself need to have permission to 'Sites.FullControl.All'. I want to understand from the security perspective, if this is desirable, i.e., a pipeline having FullControl access to a SharePoint tenant. What are the recommended practices w.r.t. this, will the application registration in such scenarios be manually done by Ops team?
According to your description, it seems that you want to use the service connection in the Azure CI/CD pipeline.
We can create a service connection with Service principal (automatic) or Service principal (manual).
Use the following parameters to define and secure a connection to a Microsoft Azure subscription using Service Principal Authentication (SPA) or an Azure managed Service Identity.
Automated subscription detection. In this mode, Azure Pipelines
queries Azure for all of the subscriptions and instances to which you
have access. They use the credentials you're currently signed in with
in Azure Pipelines (including Microsoft accounts and School or Work
accounts).
If you don't see the subscription you want to use, sign out of Azure Pipelines and sign in again using the appropriate account credentials.
Manual subscription pipeline. In this mode, you must specify the
service principal you want to use to connect to Azure. The service
principal specifies the resources and the access levels that are
available over the connection.
For more information, you could refer to Azure Resource Manager service connection.
we have azure devops pipelines to build and deploy various projects.
Rccently, we wanted to use the "azureblog file copy" pipeline to copy some files to a blob storage.
This needs write access to the storage account over in azure.
Our administrator says that the pipeline runs as whoever manually runs the pipeline. If this is true, we would have to give all devs and users read/write access to the blog storage, which would be crazy.
I assume he is wrong, and that pipelines run as a specific designated user no matter how they were kicked off. The question is, how to find out what this user is for a given pipeine?
The "edit pipeline" has a security tab near the top, adn this lists a but of "Azure Devops groups", which are presumably groups who have the ability to run the pipelines.
But where is the pipeline user defined?
which user do Azure devops pipelines run as?
It depends on the context in which you are discussing the question.
If you mean inside a pure DevOps service, then I can tell you that the user that the pipeline runs on is not the one who triggers the pipeline (which is the case with native DevOps services by default, unless you install some weird extension or have a problem with the pipeline special design), but this identity:
<Project Name> Build Service Account
'run as someone' is just a property of pipeline run. Pipeline run as 'Build Service Account'(On the DevOps side), If you need a pipeline to download or upload an artifact, you can clearly feel this. If the account mentioned above has no permission, you can't do anything.
If you mean the user's operations based on the Azure side, then I can tell you that for native DevOps service, the 'user' that the pipeline performs operations on the Azure side is not the person who triggers the pipeline. The pipeline of DevOps service consists of multiple tasks, and tasks generally interact with other services through service connection (you can find this in Project settings).
There are many types of service connections. When interacting with services in Azure, this type is generally used:
Azure Resource Manager -> Service principal
When you create a service connection of this type on the DevOps side, Azure will also create an AAD app related to this service connection, and this ADD app corresponds to a service principal in Azure. In Azure, permissions are assigned based on service principals or users, and your DevOps pipeline's operations to Azure are based on this service principal and have nothing to do with anything else in DevOps. On the Azure side, this service principal can be considered as an Azure-side 'avatar' of the tasks of the DevOps pipeline.
If you are interacting with Azure through pure code/pure script, then please follow the logic of the script/code.
Our administrator says that the pipeline runs as whoever manually runs
the pipeline. If this is true, we would have to give all devs and
users read/write access to the blog storage, which would be crazy.
For native DevOps service, of course not. Unless this pipeline has a special design.
I believe the pipeline runs as the "agent". Who the "agent user" is will depend on, first, whether you've chosen a "Microsoft-hosted" or "self-hosted" agent to run your pipeline.
When running pipelines in Azure DevOps that are directly working with Azure Resources you need an Azure Resource Manager service connection. The credentials used to make the service connection are the credentials the pipeline will use when it runs.
You can have your administrator provide you with an Azure AD account that has the permissions you need and then use that Azure AD account to create the service connection for the pipeline. Once you have created the service connection you can use the ResourceID of that connection in place of you azureSubscription.
Here is the link to the Microsoft documentation on creating a service connection.
Here is the link to the Microsoft documentation on the Azure file copy task. To verify you can use the service connection in place of the azureSubscription.
I am fairly new to Azure Devops and Azure Databricks.
I have created Azure Databricks workspace using Azure Devops CI/CD Pipeline.
Now I am looking for a solution to Add Users to Azure Databricks workspace using DevOps Pipeline.
There are several methods:
Use databricks_user resource from Databricks Terraform provider - it could be as simple as example below, or you can combine it with azuread provider, and pull users from Azure Active Directory. Another advantage of Terraform provider is that you can combine it with user groups, and other things.
resource "databricks_user" "me" {
user_name = "me#example.com"
}
Use Databricks SCIM API for Users (part of general SCIM API) - creation is quite straightforward, you just need to form correct JSON as described in docs (I didn't want to copy JSON from there), and do a call with curl or something like that. Also,
There is a collection of PowerShell scripts developed by the DataThirst company, that include scripts for adding & removing users, etc. These scripts are using REST API under the hood, and could be simpler than to use REST API. Some of these tasks are also available on the DevOps marketplace.
In any case, you need to authenticate to the workspace. For automated pipelines you have two choices - service principals or managed identity associated with DevOps worker, and they should have Owner or Contributor permissions on the workspace level, or be added into workspace as admin users.
For REST API authentication of service principal is described in details in documentation, for managed identity you just get the token from internal REST API.
Databricks Terraform provider also supports both service principals and managed identity.
Is it possible to have a service principal account trigger a build pipeline? I have a CMS that whenever a document is published it fires of an event/webhook that's calls an Azure Function. The function then calls Azure DevOps using the API to trigger the correct build pipeline. Up until now we have relied on personal access tokens (PAT) from a "lucky" team member, but obviously that isn't an ideal solution. If the PAT expires or the team member leaves our pipeline breaks down. I was hoping to use the PAT Lifecycle Management API* to generate a PAT on the fly, but as the documentation states; "On-behalf-of application" solutions (such as the “client credential” flow) and any authentication flow that does not issue an Azure AD access token is not valid for use with this API".
This seems like a fairly common scenario, having an external dependency kicking of a build pipleline, so how should I go about doing this without using person-dependent tokens?
https://learn.microsoft.com/nb-no/azure/devops/organizations/accounts/manage-personal-access-tokens-via-api?view=azure-devops
Externally trigger an Azure DevOps Build using a Sevice Principal account
I am afraid it it impossible to use REST API to trigger an Azure DevOps Build using a Sevice Principal account.
That because the Azure DevOps API doesn't support non-interactive service access via service principals.
You could get the info from the document Choose the right authentication mechanism：
Is there a way to require that Azure Functions be updated through an Azure pipeline, and not someone using the VSCode integration or azure functions core tools CLI?
I don't believe that there is a direct way to restrict deployment by method (AZ CLI, Az Powershell, Azure DevOps, Azure Portal, etc.), as ultimately most everything in Azure goes through REST APIs, ARM templates, etc.
What you can do is to organize your functions into a resource group or groups, to which you limit Contributor/Administrator/Owner access to the service principal associated with your Azure DevOps service connections. Allow other users the ability to read/inspect resources in that group, but only allow the service principal the right to create objects there. You may also need to allow the managed identities greater privileges to operate within that space, but the concept remains the same - limit the autonomy of interactive users in the space where your Azure Functions live.