I am using deployment group to deploy a .NET Core Console app to an on prem VM. In order to register the target I run the PAT on the VM. Is there a way I can use a Service Account to generate the PAT and use that to register the VM instead of my personal account?
I have used this article as a guide.
https://medium.com/#samjwright/automating-deployments-to-on-premis-servers-with-azure-devops-bb0e6cac4656
Is there a way I can use a Service Account to generate the PAT and use
that to register the VM instead of my personal account?
If you can use the service account to log in, then you can also create PAT with proper scopes in the user settings of the service account. You can refer to this ticket.
In addition, PAT is only used during registration of agent. The identity of agent pool administrator is needed ONLY at the time of registration and is not persisted on the agent, nor is used in any further communication between the agent and Azure Pipelines or TFS. Once the registration is complete, the agent downloads a listener OAuth token and uses it to listen to the job queue.
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.
I see that Service Connection is a link between Azure Pipelines and Azure Subscription to trigger Pipelines.
But can I create a Service Connection and get client id and secret and use that to obtain access token. And with that access token I can run the Azure Pipeline via c# code with REST APIs?
Is this what a service connection used for ?
But can I create a Service Connection and get client id and secret and
use that to obtain access token.
You can generate token via this, but you can't use it in C# code to run the pipeline.
Service connection between 'Azure Pipelines and Azure Subscription' just for you to create an app in AAD, this will also create related Enterprise App(service principal) in Azure portal side.
The service principal can be assigned permissions in the Azure portal to access resources. Once the service principal has access to a resource at the Azure Portal, the devops pipeline using the service connection associated with the service principal will also have the same access.
The original purpose of the above is service connection design is to allow the pipeline to have access to the resources at the portal.
Why we can't use the app's clientid and secret to get an access token to run the pipeline?
It is clearly in this official document:
https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/authentication-guidance?view=azure-devops
The Azure DevOps API doesn't support non-interactive service access
via service principals.
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 it possible to install a self-hosted agent using a managed service account (MSA)?
Or is password input required when setting the service account?
You couldn’t directly connect an azure devops agent to Azure Devops Service with MSA.
Azure Devops Service supports to use PAT or Alternate Credentials (‘alt’ authentication method).
Azure Devops On-premise also supports ‘negotiate’ authentication method (Kerberos or NTLM).
It could be useful to know that the PAT token is only used during the initial configuration of the agent.
When the PAT expires or needs to be renewed, the agent will remain connected without issues.
If the agent runs as service mode, you could also configure the “logon account” in local service or re-configure the agent.
Here is a doc about the agent auth-type.
When does a Deployment Group stop working due to expiration or regeneration of the Personal Access Token (PAT) that it was configured with?
If I regenerate the PAT, do I need to update the deployed agents, e.g. reconfigure them with the new PAT?
What happens if I just edit the PAT, update the Expiration date, but don't do anything else, e.g. do not regenerate the PAT or do any changes at the configured deployment agent? Will it stop it from expiring and the configured deployment agent still work?
We have Azure DevOps pipeline, along with a deployment group configured to install the solution to one server.
We have a service account, which we use have generated a PAT and used that token to configure the Deployment Group.
I have tried to regenerate the token, which gave me a new PAT. I have not tried to configure the server with the new PAT. However, deployments still seem to work just fine hours from regenerating the PAT.
What is the proper way to update the PAT so that it does not expire and my deployment agents do not stop working?
From the official Microsoft docs:
To register an agent, you need to be a member of the administrator
role in the agent pool. The identity of agent pool administrator is
needed only at the time of registration and is not persisted on the
agent, and is not used in any subsequent communication between the
agent and Azure Pipelines or TFS. In addition, you must be a local
administrator on the server in order to configure the agent.
Your
agent can authenticate to Azure Pipelines or TFS using one of the
following methods: Personal Access Token (PAT): Generate and use a PAT
to connect an agent with Azure Pipelines or TFS 2017 and newer. PAT is
the only scheme that works with Azure Pipelines. Also, as explained
above, this PAT is used only at the time of registering the agent, and
not for subsequent communication.
So, if you remove or re-generate the PAT the agents will keep working without any issues.
You can do two things:
You can Edit token and change expiration date, this is the easiest way
You can Regenerate token, this will create new token, and you will have to:
2.1. Write down your agent user capabilites, name, service user account etc.! Because once you remove the configuration this information will be lost
2.2 Remove agent's configuration (in agent's folder), run ".\config.cmd remove"
2.3 Configure agent with new PAT (in agent's folder), run ".\config.cmd"