Almost everyone who has integrated an app or service with Azure DevOps has used a Personal Access Token (PAT) or an SSH key for authentication. Personally, I’ve done it as well. It’s convenient, fast, and functions effectively - up until it doesn’t.
Even so, I want to highlight that, despite the apparent convenience, such authentication methods do not align with best practices - especially concerning security, scalability, and automation, so turning to them in today’s context is problematic.
Thus, for the remainder of this discussion, I aim to highlight the issues with using PATs and SSH keys for application authentication and explore more effective authentication methods.
The Appeal of PATs and SSH Keys
- Quick to create: Just a couple of clicks and you’re set.
- Perfect for quick experiments: Need to test Git access or kick off a pipeline? Just do it.
- Nice for scripts: You can easily slap a PAT onto a curl command or script and never worry about it again.
Sounds great, right? Well… until all hell breaks loose.
While working with Azure DevOps, one is bound to love the sheer speed and simplicity of authenticating applications using Personal Access Tokens or SSH keys. It is almost always the first suggestion to pop up in the docs or on Stack Overflow when trying to set up Git access for CI/CD tools, bots, or deployment platforms.
The matter of fact is, just because something is feasible does not make it right, nor secure. But just because we can doesn't make it the best practice.
Let me take you through a recent instance that really put this point into perspective.
The Sync Issue That Uncovered A Larger Problem
I was updating the Argo CD release setup with our Azure DevOps Git repositories to streamline application deployments. Everything was fine until I noticed that some applications were not syncing.
At first, I thought the cluster or network was at fault. However, my investigation pointed to something else entirely:
The SSH keys for Argo CD to authenticate with the Azure DevOps repo had expired, and to make matters worse, the keys belonged to an employee who was no longer with the company.
Our GitOps pipeline was now in the dead pool.
What Was the Mistake?
The configuration was seemingly correct on the surface; in reality, it relied on two vulnerable assumptions:
- The individual tied to the SSH or PAT credentials would still be around.
- A manual rotation of the token or key would be done before expiry.
Spoiler: neither of those occurred.
This wasn't a sync problem - it was a visibility shortfall, a process failure, and a security vulnerability, all in one.
Why PAT Tokens and SSH Keys Are Not the Perfect Option for Application Access
Let's break down the biggest problems:
- They Don't Support Granular Access Controls: PATs typically have pre-set scopes. You can't restrict access to a single pipeline or repository unless you fundamentally hack things. And SSH keys? They're even more so - it's often all or nothing. This means that if the token or key gets compromised, it may grant access to everything that the user has access to.
- They Have an Expiration Date: PATs run out of time every 30 to 365 days. SSH keys may have given arbitrary expiration. Either way, they will fail without automatic rotation.
- Tied to a User = Not Great for Automation: PATs and SSH keys are user-scoped, which means:
- If the user departs the company? The token is lost.
- If MFA and/or account policies change, things break..
- Need to audit who caused what? Good luck: Applications should make use of app identities, not people identities.
So, What Shall We Do Instead?
Until Azure DevOps has identity federation (such as GitHub's OIDC model), we can still make a big improvement in our practices:
- Use Service Accounts Instead of Personal Ones: Make special service users (such as [email protected] or argo-bot) with limited access. This keeps automation separate from human users and prevents interruptions when individuals leave.
- How about limiting the breadth of PATs: One better practice in the guidelines for PATs is for them to have the least access right required, mainly only Code: Read to a repo or project, just to pour information.
- Rotate Automatically: Make use of scripts, pipelines, or secret management systems to rotate tokens from time to time and refresh your tools (such as Argo CD) automatically.
- Store Secrets Securely: Do not hardcode tokens into manifests. Keep them in tools such as:
- Azure Key Vault
- HashiCorp Vault
- SealedSecrets or External Secrets Operator in Kubernetes
- Monitor and Audit: Establish PAT expiration alerts. Periodically audit who has what tokens, who owns them, and where they are used.
Last Words
My Argo CD problem would have become an even bigger problem — just think what would have happened if the failed sync had gone undetected in a production environment. That's the risk of using user-scoped, long-lived credentials.
Automation is not about compromise.
We, as DevOps engineers, must advocate for solutions that are not only workable but also secure, fault-tolerant, and auditable.
If you are continuing to authenticate with an SSH key or your own PAT from "that one person who knows everything," perhaps it is time to end that.