Enhancement Request: `azurerm` backend authentication upgrade to match provider

jaredfholgate commented 9 months ago

Terraform Version

1.6.5

Use Cases

I want to use az CLI service principal authentication in my CI / CD pipelines. I am able to do that with the upgraded authentication in the provider for plan and apply, but init does not support it for the azurerm backend.

I'd like to have a consistent authentication experience across all commands.

The original driver for this is running terraform test with OIDC auth. Since the Azure DevOps ID Token is only valid for 10 minutes and each test configures a new provider for each time it times out if there are a few tests in there.

Attempted Solutions

There is no solution other than using the existing mechanism to supply service principal credentials.

Proposal

Update the azurerm backend authentication code to match the provider code.

References

For clarity, this is the line in v0.43.0 of the target library that explicitly breaks SP auth with CLI: https://github.com/hashicorp/go-azure-helpers/blob/202cb910fbce8b8a78fe6e40177569b6ad59e885/authentication/auth_method_azure_cli_token.go#L72

The target library has significantly changed since that version and that code no longer exists in there.

No response

crw commented 9 months ago

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

Noel-Jones commented 3 weeks ago

Is there likely to be a resolution for this? I've ended up here having spent a fair while trying to reasearch why my CI/CD pipelines fail to apply changes if I don't complete the manual validation within 10 minutes. After this time applying the plan file fails with the error "AADSTS700024: Client assertion is not within its valid time range". All this became an issue after I switched to the "recommended" use of Workload Identites. I arrived here via https://github.com/microsoft/azure-pipelines-terraform/issues/201 and https://github.com/microsoft/azure-pipelines-terraform/issues/89

It does not appear to be clear in the initial use case / description just how much of an issue this appears to be for many people. 33 people have upvoted this but I believe a lot more would if they found their way here.

I have seen a few references to workarounds but with no clear examples of quite what to do. If anyone can advise a workaround then I would be grateful if they could post details.

crw commented 3 weeks ago

@Noel-Jones it is possible this could be addressed, but difficult to say how likely or when. Thanks for the additional use case!

magodo commented 3 weeks ago

Related: https://github.com/hashicorp/terraform/pull/35381 (though closed)

jaredfholgate commented 1 week ago

I think it is worth re-visiting this and adding some clarity as there are a few overlapping issues at play here:

The original intent for this issue was to add support for az cli authentication with a service principal to bring it inline with the providers. This would also have provided a workaround for the token expiry issue people are facing, albeit not a native solution to the problem.
With regards to the token expiry issue in Azure DevOps, that could now be solved using the native capability in the Go SDK: https://devblogs.microsoft.com/azure-sdk/improve-security-posture-in-azure-service-connections-with-azurepipelinescredential/. This probably warrants a separate issue, but fundamentally the authentication library needs to be updated. Cross referencing this issue for azapi: https://github.com/Azure/terraform-provider-azapi/issues/515#issuecomment-2222773147
The other thing people may come here for is support for using different identities for provider and backend auth. This could be achieved by adding alternative environment variables that don't overlap with the provider environment variables.

Hopefully that helps in some way or I may have caused extra confusion...

hashicorp / terraform