Edit

Token lifecycle management is now in private preview

  • Article

We previously relied on the Azure DevOps UI to create, renew, and expire personal access tokens. In this release, we're excited to announce Azure DevOps REST API support for personal access tokens, and it's now available in private preview.

Check out the Features list below for details.

General

Azure Pipelines

Azure Artifacts

General

PAT lifecycle management API (private preview)

We're happy to announce the release of new APIs to manage the lifecycle of Personal Access Tokens (PATs) in Azure DevOps. This rich set of APIs allows your team to simplify the management of the PATs they own, offering them new functionality, such as creating new personal access tokens with a desired scope and duration, and renewing or expiring existing ones.

Today, the primary way for you to manage PATs (Personal Access Tokens) is through the UI or by using a limited set of APIs intended only for Project Collection Administrators. This new API unlocks the ability for organizations to set up automation involving PATs, including setting up build pipelines or interacting with work items.

The PAT lifecycle management API is now available for organizations to use in private preview.

Please reach out to us with your use case and your Azure DevOps organization to get access to the API and documentation. We appreciate any feedback you can offer on how this API has helped your organization or can be further improved to meet your needs!

Token management events now in Audit Logs

Personal Access Tokens (PATs) and SSH Keys enable you and your teammates to authenticate with Azure DevOps in a non-interactive way. Many of you have expressed the need to understand by whom and how these tokens are used in order to prevent malicious activity by unauthorized users. With this release, new events will be added to the Audit Logs whenever these tokens are successfully created, updated, revoked, and/or removed.

To see these new events, head over to the Auditing page through your Organizations’ settings page. For additional information on these new events and all available events in your Audit Logs, please see our documentation.

Limit user visibility and collaboration to specific projects

In this sprint, we're releasing a public preview feature to enable organization administrators in Azure DevOps to restrict users from seeing and collaborating with users in different projects. This feature will bring another level of isolation and access control to projects. Your early feedback will help us improve the experience.

By default, users added to an organization can view all organization metadata and settings. This includes viewing the list of users in the organization, list of projects, billing details, usage data, and anything that's accessible through the organization settings. Additionally, users can use the various people-pickers to search for, view, select, and tag all other organization members, even if these users are not in the same project.

To restrict users from this information, you can enable the Limit user visibility and collaboration to specific projects preview feature for your organization. Once enabled, the Project-Scoped Users group, an organization-level security group, will be added to your Azure DevOps organization. Users and groups added to this new group (which can be found by navigating to the Organization Settings -> Permissions) will have two limitations: Hidden organization settings and limited people-picker search and tagging.

Hidden Organization Settings

Users added to the "Project-Scoped Users" group are restricted from accessing the Organization Settings pages, except for Overview and Projects, and are restricted to only viewing data from projects where they belong.

Limited people-picker search and tagging

Using the various people pickers in the product, users and groups added to the “Project-Scoped Users” group will only be able to search for, view, select, and tag members who are also members of the project they’re currently in.

Azure Pipelines

Approver details available in audit logs

You can now view the details about who approved your pipelines in the audit logs. We updated the 'Check Suite Completed' event to include this information. You can access the audit logs from Organization Settings -> Auditing.

Change in process for obtaining free pipelines grant in public projects

Azure Pipelines has been offering free CI/CD to open source projects since September 2018. Because this amounts to giving away free compute, it has always been a target for abuse – especially crypto mining. Minimizing this abuse has always taken energy from the team. Over the past few months, the situation has gotten substantially worse, with a high percentage of new public projects in Azure DevOps being used for crypto mining and other activities we classify as abusive. In addition to taking an increasing amount of energy from the team, this puts our hosted agent pools under stress and degrades the experience of all our users – both open-source and paid.

To address this situation, new public projects created in Azure DevOps will no longer get the free grant of parallel jobs. As a result, you won’t be able to run pipelines when you create a new public project. However, you can request the free grant by sending an email to azpipelines-ossgrant@microsoft.com and providing the following details:

  • Your name
  • Azure DevOps organization for which you are requesting the free grant
  • Links to the repositories that you plan to build
  • Brief description of your project

For more information about parallel jobs and free grants, see our documentation.

Azure Artifacts

Changes to Azure Artifacts upstream behavior

Previously, Azure Artifacts feeds presented package versions from all of its upstream sources. This upstream includes package versions originally pushed to an Azure Artifacts feed (internally sourced) and package versions from common public repositories like npmjs.com, NuGet.org, Maven Central, and PyPI (externally sourced).

This sprint introduces a new behavior that provides additional security for your private feeds by limiting access to externally sourced packages when internally sources packages are already present. This feature offers a new security layer, which prevents malicious packages from a public registry being inadvertently consumed. These changes will not affect any package versions that are already in use or cached in your feed.

To learn more about common package scenarios where you need to allow externally sourced package versions along with a few other scenarios where no blockage to the public packages is needed and how to configure the upstream behavior, see documentation Configure upstream behavior - Azure Artifacts | Microsoft Docs

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,

Aaron Halberg