There’s two takeaways in this blog post and I’m going to give them away right here in the beginning. According to Azure DevOps documentation all token data like SSH keys and personal access tokens (PATs) are stored in US region. No matter where your DevOps organization resides. You should be aware of this especially if you’re an European organization that has regulations or policies that deny storing any data outside EU boundaries. The other takeaway isn’t a surprise to any security pro: You should always scope your PATs accordingly, and even if it is very tempting to generate a full-scoped tokens that just work. Avoid the temptation! There are some settings you can fiddle with to restrict users’ ability to do dumb things. Let’s start!
Setting the goal
In this blog post we will learn how to restrict and scope Personal Access Tokens in Azure DevOps
Token data
Stated in the Azure DevOps documentation, token data such as PATs and SSH keys are stored in US datacenter. At this point I have more questions then answers…
Okay what does this mean? What data exactly? What is “…data, such as…”?
Based on documentation, for both PATs and SSH keys hash is stored in the “database”. This would, most likely, mean Azure SQL database as it is one of two main components for Azure DevOps service storages. The other storage being Azure Blob Storage. Both are using AES256 encryption at rest.
Enable restrictions
To enable restrictions there are some prerequisites.
- Your Azure DevOps organization needs to be connected to Microsoft Entra directory
- You need to have Azure DevOps Administrator Entra ID role assigned
The restrictions are under the Organizational settings > General > Microsoft Entra
This is how the Microsoft Entra view looks when you don’t have the sufficient role. No policies are visible.
Activate the Azure DevOps Administrator role via PIM and refresh the view or do a new login. You should now see Policies section under the Download button.
The policies that you can now configure are:
- Restrict organization creation
- Ability to display custom error message
- Restrict global personal access token creation
- Restrict full-scoped personal access token creation
- Enforce maximum personal access token lifespan
- Maximum allowed lifespan for new tokens (in days)
- Automatically revoke leaked personal access tokens
Restrict organization creation
This setting does not prevent any user from creating Azure DevOps organization, but it prevents users from connecting those organizations to Microsoft Entra directory. You should have a process of creating DevOps organizations and when this is enabled anyone with Azure DevOps Administrator Entra ID role can still create an organization. Also there is allowlist available for this setting but I recommend do not use it. Stick to the Entra role unlocking the creation process.
Restrict global personal access token creation
If this setting is enabled, users cannot create PATs that are valid for multiple organizations. For example a user who has been delegated access to three DevOps organizations could create a PAT that would work in the scope of all three DevOps organizations. Turn this on to deny creation of these type of global tokens.
Restrict full-scoped personal access token creation
If this setting is enabled, user cannot create PATs that grant full access (all write accesses available), but they actually have to do some scoping. We will take a look at this in the next chapter.
Enforce maximum personal access token lifespan
To limit the lifetime that the PAT is valid, you can change and save a number of days under this setting.
Automatically revoke leaked personal access tokens
This setting is on by default when you first check the policies after activating the needed role. If the setting is enabled, Azure DevOps PATs checked into public GitHub repositories will be automatically revoked. This policy applies to all PATs within Azure DevOps Organizations linked to your Microsoft Entra tenant.
Note! Any settings that you configure here are global in nature, meaning that when there is multiple Azure DevOps organizations connected to the same Microsoft Entra ID directory and you change some settings in one organization, those changes will apply to other connected organizations as well.
Scoping the token
Now that we have our policies in effect let’s create one personal access token.
Right from the get-go we get a notification saying that we cannot create full-scoped or global personal access tokens and that lifespan duration of token cannot exceed 10 days according to company policies.
I’m signed in to the ‘devops-fallback’ organization and cannot change it. This is because we have restricted global PATs. Furthermore, I cannot extend the expiration date beyond 10 days because of the lifespan limitation. Great!
Because we restricted full-scoped PATs, the ‘Full access’ radio button is greyed out. We have to assign scope permissions manually. This is also desired effect.
Notice, that even if we did restrict full-scoped PATs, I can still choose to add all the available scopes manually and DevOps will let me create that token.
When scopes are checked we press Create and we get our token! Make sure to copy it into a safe location.
Please note that if you’re using Windows Clipboard history the token will be available in the history memory! You can clean it up by deleting it from the memory (from three dots).
Regenerate, revoke and edit PAT
You can Revoke, Regenerate and Edit your PATs. Once your PAT has expired come back and regenerate it. Regenerating does not change the scope but extends the token validation date by the same amount of days that it was valid to begin with.
Revoking a token naturally makes the token invalid.
Editing the token opens the same flyout window you filled in when you created the token. Here you can change the scope, validation duration and name of the token.
Summary
I hope that you learned how to gain visibility into these policies that are hidden behind the Azure DevOps Administrator role. Notice that it isn’t enough to have Global Administrator role, because GA role does not see those settings. Once you have visibility, take your time to configure them according to your practices, but usually restrictive path is a way to here.
Stay secure!
