[enhancement]: Add support for Workload Identity Federation when joining agent to a pool

[HarryGwinnell]

We're currently using PATs to join the agent to our pool, but in an effort to remove PATs and secrets, we're trying to switch to secretless auth where possible. We currently have our ADO organization connected to Tenant A, but the agents are created in an Azure Subscription managed by Tenant B.

Managed Identities do not work cross-tenant, so federation becomes necessary. The agent does support Service Principal auth, but it requires a Client Secret. Instead, it'd be useful if the Service Principal option allowed a Federated Identity to be used instead. Alternatively, we can produce a federated OAuth token ourselves, if the agent allows passing an OAuth token.

[DmitriiBobreshev]

Hi @HarryGwinnell, thanks for the feedback, even if the agent has Oauth connection, it could not be configured through agent's configuration.
We are working on more prioritized issues at the moment, but will try to implement Federated Identity soon.

[HarryGwinnell]

@DmitriiBobreshev Is there a rough timeline for this? It's blocking some S360 work and may become a hard blocker in some upcoming waves

[sbebrys]

@HarryGwinnell we are planning do the same and after some tries I could confirm that access_token gained from manually exchanging client-assertion-token can be used instead PAT (as the same parameter with auth type PAT) and worked well.

Because our solution is based on Keda scaler, where each agent is running once as job in kubernetes, I also requested Keda to support workload identity there, to give scaler password less access to the ado job queue. Keda implemented that and now we could run agents from different tenant or even cloud.

Still we have challenge how to not expose injected client-assertion-token to the jobs and unregister agent after 1h (final ado access_token expiration time cannot be managed).

It will be great to have this support out of the box, but timeline is unfortunately unknown.