Description
Problem
Azure DevOps pipelines using a service connection with workload identity federation (Microsoft's recommended, secretless auth pattern — see Azure DevOps docs) expose an OIDC token via $env:idToken, but never populate $env:servicePrincipalKey. Any Packer build using these templates with such a service connection fails with:
Undefined -var variable ...
because client_jwt is never declared in variable.ubuntu.pkr.hcl / variable.windows.pkr.hcl, nor wired into the azure-arm source block in source.ubuntu.pkr.hcl / source.windows.pkr.hcl.
packer-plugin-azure's azure-arm builder has supported client_jwt as a config field for OIDC auth for several releases (confirmed working on v2.3.3) — these templates just never expose it.
Impact
Anyone following Microsoft's own guidance to move Azure DevOps service connections to workload identity federation (away from secret-based service principals) cannot use these templates for azure-arm builds without a manual local patch.
Prior history
This was raised in #160666 and a fix #8533 was rejected in 2023 for "lack of interest in OIDC authentication." Given Microsoft's continued push toward workload identity federation as the default/recommended auth method since then, I'd like to reopen this as a supportability gap rather than a feature request.
Fix
Opened #14436 — adds the client_jwt variable and wiring for both Ubuntu and Windows templates. Would appreciate a maintainer look, even if just to confirm whether this is in scope for the repo.
Platforms affected
Runner images affected
Image version and build link
N/A — this isn't a runtime failure in a built image. It's a build-time failure in this repo's own Packer templates when used as a source for custom image builds (as documented in docs/create-image-and-azure-resources.md), reproducible on any commit/version of images/ubuntu/templates/ or images/windows/templates/ with an azure-arm service connection configured for workload identity federation.
Repro: run packer validate (or packer build) against images/ubuntu/templates/ (or windows) passing client_jwt as a -var, with no client_secret/client_id/client_cert_path set. Fails with:
Undefined -var variable 'client_jwt' is not a valid variable name
because client_jwt isn't declared in variable.ubuntu.pkr.hcl/variable.windows.pkr.hcl or wired into the azure-arm source block. My build link is a private Azure DevOps pipeline, so no public URL to share — happy to paste the exact error text if useful, but it's the same generic "Undefined -var variable" message above.
Is it regression?
No.
Expected behavior
When a Packer build against images/ubuntu/templates/ or images/windows/templates/ is invoked with a client_jwt variable (an OIDC token from a workload identity federation service connection) instead of client_secret, it should validate and build successfully — client_jwt should be declared in variable.ubuntu.pkr.hcl/variable.windows.pkr.hcl and wired into the azure-arm source block in source.ubuntu.pkr.hcl/source.windows.pkr.hcl, exactly as client_id/client_secret/client_cert_path already are. This would let builds authenticate via OIDC without requiring a service principal secret, matching Microsoft's own guidance to prefer workload identity federation over secret-based service principals.
Actual behavior
The build fails immediately at packer validate/packer build time with:
Undefined -var variable 'client_jwt' is not a valid variable name
because client_jwt is not declared anywhere in variable.ubuntu.pkr.hcl / variable.windows.pkr.hcl, and the azure-arm source block in source.ubuntu.pkr.hcl / source.windows.pkr.hcl only wires client_id, client_secret, and client_cert_path. There is no way to authenticate the azure-arm builder via OIDC/workload identity federation using these templates as-is — you're forced to fall back to a secret-based service principal, even though the underlying packer-plugin-azure builder already supports client_jwt.
Repro steps
- Clone this repo and cd images/ubuntu/templates (or images/windows/templates).
- Set up an Azure service connection/identity using workload identity federation (OIDC) rather than a client secret — e.g. in Azure DevOps, a service connection with addSpnToEnvironment: true, which exposes an OIDC token via $env:idToken but never populates a service principal secret.
- Run packer init . followed by:
packer validate -var="client_jwt=" -var-file=... .
- (omitting client_secret, client_id's secret pairing, and client_cert_path, since none apply to OIDC auth).
- Observe the failure:
Undefined -var variable 'client_jwt' is not a valid variable name
- Confirm the gap by inspecting variable.ubuntu.pkr.hcl/variable.windows.pkr.hcl — no client_jwt variable is declared — and source.ubuntu.pkr.hcl/source.windows.pkr.hcl — the azure-arm source block only references client_id, client_secret, tenant_id, subscription_id, and client_cert_path, never client_jwt.
Description
Problem
Azure DevOps pipelines using a service connection with workload identity federation (Microsoft's recommended, secretless auth pattern — see Azure DevOps docs) expose an OIDC token via $env:idToken, but never populate $env:servicePrincipalKey. Any Packer build using these templates with such a service connection fails with:
Undefined -var variable ...
because client_jwt is never declared in variable.ubuntu.pkr.hcl / variable.windows.pkr.hcl, nor wired into the azure-arm source block in source.ubuntu.pkr.hcl / source.windows.pkr.hcl.
packer-plugin-azure's azure-arm builder has supported client_jwt as a config field for OIDC auth for several releases (confirmed working on v2.3.3) — these templates just never expose it.
Impact
Anyone following Microsoft's own guidance to move Azure DevOps service connections to workload identity federation (away from secret-based service principals) cannot use these templates for azure-arm builds without a manual local patch.
Prior history
This was raised in #160666 and a fix #8533 was rejected in 2023 for "lack of interest in OIDC authentication." Given Microsoft's continued push toward workload identity federation as the default/recommended auth method since then, I'd like to reopen this as a supportability gap rather than a feature request.
Fix
Opened #14436 — adds the client_jwt variable and wiring for both Ubuntu and Windows templates. Would appreciate a maintainer look, even if just to confirm whether this is in scope for the repo.
Platforms affected
Runner images affected
Image version and build link
N/A — this isn't a runtime failure in a built image. It's a build-time failure in this repo's own Packer templates when used as a source for custom image builds (as documented in docs/create-image-and-azure-resources.md), reproducible on any commit/version of images/ubuntu/templates/ or images/windows/templates/ with an azure-arm service connection configured for workload identity federation.
Repro: run packer validate (or packer build) against images/ubuntu/templates/ (or windows) passing client_jwt as a -var, with no client_secret/client_id/client_cert_path set. Fails with:
Undefined -var variable 'client_jwt' is not a valid variable name
because client_jwt isn't declared in variable.ubuntu.pkr.hcl/variable.windows.pkr.hcl or wired into the azure-arm source block. My build link is a private Azure DevOps pipeline, so no public URL to share — happy to paste the exact error text if useful, but it's the same generic "Undefined -var variable" message above.
Is it regression?
No.
Expected behavior
When a Packer build against images/ubuntu/templates/ or images/windows/templates/ is invoked with a client_jwt variable (an OIDC token from a workload identity federation service connection) instead of client_secret, it should validate and build successfully — client_jwt should be declared in variable.ubuntu.pkr.hcl/variable.windows.pkr.hcl and wired into the azure-arm source block in source.ubuntu.pkr.hcl/source.windows.pkr.hcl, exactly as client_id/client_secret/client_cert_path already are. This would let builds authenticate via OIDC without requiring a service principal secret, matching Microsoft's own guidance to prefer workload identity federation over secret-based service principals.
Actual behavior
The build fails immediately at packer validate/packer build time with:
Undefined -var variable 'client_jwt' is not a valid variable name
because client_jwt is not declared anywhere in variable.ubuntu.pkr.hcl / variable.windows.pkr.hcl, and the azure-arm source block in source.ubuntu.pkr.hcl / source.windows.pkr.hcl only wires client_id, client_secret, and client_cert_path. There is no way to authenticate the azure-arm builder via OIDC/workload identity federation using these templates as-is — you're forced to fall back to a secret-based service principal, even though the underlying packer-plugin-azure builder already supports client_jwt.
Repro steps
packer validate -var="client_jwt=" -var-file=... .
Undefined -var variable 'client_jwt' is not a valid variable name