New policies for personal access tokens

  • Article

In this sprint, we added new policies to restrict the scope and lifespan of personal access tokens (PAT). In addition, we updated the Team Foundation Version Control (TFVC) Windows Shell extension to support Visual Studio 2019.

Check out the following feature descriptions for details.

General

Azure Pipelines

Azure Repos

General

Restrict personal access token (PAT) scope and lifespan via Azure AD tenant policy

Personal access tokens (PATs) make it easy to authenticate against Azure DevOps to integrate with your tools and services. However, leaked tokens could compromise your Azure DevOps account and data, putting your applications and services at risk.

We received feedback about administrators not having the necessary controls to limit the threat surface area posed by leaked PATs. Based on these feedback, we’ve added a new set of policies which can be used to restrict the scope and lifespan of your organization’s Azure DevOps personal access tokens (PATs)! Here’s how they work:

Users assigned to the Azure DevOps Administrator role in Azure Active Directory can navigate to the Azure Active Directory tab in the organization settings of any Azure DevOps organization linked to their Azure AD.

Image PAT controls

There, administrators can:

  1. restrict the creation of global personal access tokens (tokens that work for all Azure DevOps organizations accessible by the user)
  2. restrict the creation of full-scoped personal access tokens
  3. define a maximum lifespan for new personal access tokens

These policies will apply to all new PATs created by users for Azure DevOps organizations linked to the Azure AD tenant. Each of the policies have an allow list for users and groups who should be exempt from the policy. The list of users and groups in the Allow list will not have access to manage policy configuration.

These policies only apply to new PATs, and will not affect existing PATs that have already been created and are in use. After the policies have been enabled however, any existing, now non-compliant PATs must be updated to be within the restrictions before they can be renewed.

Conditional access policy support for IPv6 traffic

We are now extending conditional access policy (CAP) support to include IPv6 fencing policies. As we see people increasingly access Azure DevOps resources on devices from IPv6 addresses, we want to ensure that your teams are equipped to grant and remove access from any IP address, including those coming from IPv6 traffic.

Azure Pipelines

Retain pipelines that are consumed in other pipelines

Classic releases had the ability to automatically retain builds that they consume. This was one of the gaps between classic releases and YAML pipelines, and it stopped some of you from moving to YAML. With this release, we have addressed this gap.

Now you can create a multi-stage YAML pipeline to represent your release, and consume another YAML pipeline in it as a resource. When you do so, Azure Pipelines will automatically retain the resource pipeline as long as the release pipeline is retained. When the release pipeline is deleted, the lease on the resource pipeline is released and its own retention policies are followed.

Changes in the automatic creation of environments

When you author a YAML pipeline and refer to an environment that does not exist, Azure Pipelines automatically creates the environment. This automatic creation can occur in either the user context or the system context. In the following flows, Azure Pipelines knows about the user performing the operation:

  • You use the YAML pipeline creation wizard in the Azure Pipelines web experience and refer to an environment that hasn't been created yet.
  • You update the YAML file using the Azure Pipelines web editor and save the pipeline after adding a reference to an environment that does not exist.

In each of the above cases, Azure Pipelines has a clear understanding of the user performing the operation. Hence, it creates the environment and adds the user to the administrator role for the environment. This user has all the permissions to manage the environment and/or to include other users in various roles for managing the environment.

In the following flows, Azure Pipelines does not have information about the user creating the environment: you update the YAML file using another external code editor, add a reference to an environment that does not exist, and then cause a manual or continuous integration pipeline to be triggered. In this case, Azure Pipelines does not know about the user. Previously, we handled this case by adding all the project contributors to the administrator role of the environment. Any member of the project could then change these permissions and prevent others from accessing the environment.

We received your feedback about granting administrator permissions on an environment to all members of a project. As we listened to your feedback, we heard that we should not be auto-creating an environment if it is not clear as to who the user performing the operation is. With this release, we made changes to how environments will be automatically created:

  • Going forward, pipeline runs will not automatically create an environment if it does not exist and if the user context is not known. In such cases, the pipeline will fail with an Environment not found error. You need to pre-create the environments with the right security and checks configuration before using it in a pipeline.
  • Pipelines with known user context will still auto-create environments just like they did in the past.
  • Finally, it should be noted that the feature to automatically create an environment was only added to simplify the process of getting started with Azure Pipelines. It was meant for test scenarios, and not for production scenarios. You should always pre-create production environments with the right permissions and checks, and then use them in pipelines.

Remove Insights dialogue from Build Pipeline

Based on your feedback, the task/pipeline Insights dialogue box that displays when navigating the Build Pipeline has been removed to improve the workflow. The pipeline analytics are still available so that you have the insights you need.

Azure Repos

Updates to Team Foundation Version Control (TFVC) Windows Shell extension for Visual Studio 2019

The previous version of the TFVC Windows Shell extension only worked on computers that had Visual Studio 2017 installed.

We have released a new version of this tool that is compatible with Visual Studio 2019. The extension provides integration with Windows Explorer and the common file dialogs. With this integration, you can perform many source control operations without having to run Visual Studio or a Team Foundation command-line tool.

Next steps

Note

These features will roll out over the next two to three weeks.

Head over to Azure DevOps and take a look.

Go to Azure DevOps

How to provide feedback

We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.

Make a suggestion

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Vijay Machiraju