Add client_jwt as variable to templates using azure-arm builder

[Triodes]

With increasing support for using identity federation (for example in Github actions and Azure devops) and the newly built in support for OIDC in the azure packer plugin I think it would make sense to add client_jwt as a variable to the templates using this builder.

If there is support for this idea I'm willing to make a PR for the templates involved.

Aron

[Triodes]

I have since created a PR for this which unfortunately was rejected because of "lack of interest in OIDC authentication". I personally believe that this way of authentication is the way forward. I would like to encourage anyone to express their opinion on this matter.

[wesleykey]

Completely agree. OIDC is a safer authentication mechanism and requires less administrative overhead because we no longer need to manage service principal credentials and their rotation. This absolutely seems to be the direction Microsoft are suggesting Azure DevOps users move in, so would expect to see it available here as an option.

Thanks for the PR though @Triodes. I've incorporated your changes into my code.

[Triodes]

Hey @wesleykey
These were my thoughts exactly.

There was one thing I ran into during testing:
When you hand the OIDC_TOKEN to packer via the client_jwt field, it exchanges it for a Bearer token. This Bearer token is subsequently used for authenticating the actual azure API requests done by packer. Now according to the blog post announcing OIDC support in Azure DevOps this Bearer token should be valid for 1 hour. I believe these Bearer tokens come together with a refresh token which can be used to renew the Bearer token when it has expired.

What I experienced is that the packer builds, which often run several hours, fail after provisioning has completed because the Bearer token has expired.
The initial creation of the VM goes fine, then provisioning is done via SSH (which does not need any Azure API calls). After provisioning is completed we need Azure API calls again for creating the image and then it fails with an expired token.

I basically concluded that this was probably a bug in packer (since support was only recently added) and that it simply fails to use the refresh token to renew the Bearer token. However this is speculation and I never investigated it further.

I was wondering if you have any similar experiences?

Kind regards
Aron

[wesleykey]

Hey @Triodes

I'm using the ubuntu-minimal template which comfortably builds in under an hour so haven't hit this issue. However, I would think you could get around this by using a user assigned managed identity instead of an app registration. Tokens generated for user assigned managed identities should have a lifespan of 24 hours.

Hope that helps. Would be interested to know how you get on.

[Triodes]

One of my colleagues mentioned something about federated credentials for user managed identities, yes. Seems like something worth investigating. Thanks for the tip!

[pinkfloydx33]

@Triodes Years later... did you ever solve the problem without switching to a Managed Identity?

[Triodes]

Ooof, this is from really long ago.... I don't remember exactly but I think we just kept using a service principal with client credentials. The downside of this is that you have to rotate these credentials periodically. However, Azure Devops has much better support t now for authenticating to Azure Resource Manager using managed identities & federated authentication. Which is currently the way I would recommend.
I really don't remember wel enough what I used this for to give more specific pointers, sorry 😔