Packer: use_azure_cli_auth not considered if subscription_id is set

[rickardp]

When filing a bug, please include the following headings if possible. Any
example text in this template can be deleted.

Overview of the Issue

This concerns the azure-arm builder.

When using CLI auth as described in #10156, I find that is is not possible to set a subscription_id. This is problematic since I want to create the objects in a different subscription than the default. Generally a user or principal has access to more than one subscription.

A paragraph or two about the issue you're experiencing.

Reproduction Steps

Set the following properties in the JSON:

"use_azure_cli_auth": true,
"subscription_id": "xxxx"

when building, observed the following log output

==> azure-arm: Initiating device flow: XXX
==> azure-arm: Microsoft Azure: To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XXXXXXXX to authenticate.

When removing the subscription_id property,

==> azure-arm: Running builder ...
==> azure-arm: Getting tokens using Azure CLI
==> azure-arm: Getting tokens using Azure CLI
    azure-arm: Creating Azure Resource Manager (ARM) client ...

Note that the creation of resources continues in the default subscription and I have no way of controlling this AFAIK.

Packer version

1.6.6-dev (nightly)

Simplified Packer Buildfile

See above

Operating system and Environment details

Linux AMD64, Mac ARM64

Log Fragments and crash.log files

See above

[nywilken]

Hey @rickardp good catch, and thanks for testing out the latest dev builds. I'm not sure if we will be able to get to this soon, but PRs are welcomed if you are interested in making the fix. Or maybe @simongottschlag has some time to help us out.

[simongottschlag]

Hi!

My thought when writing it was that the selection of subscription would be done outside of Packer, with Azure CLI.

I think this is how it's done in terraform, but I'm not 100% sure without digging into the question.

When using this with GitHub Actions or Azure DevOps, the selection is already made. I would personally prefer the application not to be able to jump out of the context I've selected.

[simongottschlag]

I may actually be wrong about terraform. Looking into the HashiCorp helper, it does seem like it enables choosing subscription: https://github.com/hashicorp/go-azure-helpers/blob/master/authentication/auth_method_azure_cli_token.go

Without looking deeper at this, it seems like the SDK I implemented doesn't allow this, which may be the case why HashiCorp have their own :) https://github.com/Azure/go-autorest/blob/e85e33a04d242eb0eba5408e4dadf8783047b62f/autorest/azure/cli/token.go#L125-L175

We would most likely have to reimplement the cli auth with the HashiCorp helper to get this working correctly.

I would count this issue as an enhancement / feature request rather than a bug, with a workaround that is changing the subscription before running Packer.

I fully understand that this may not be what @rickardp wants to hear though. :(

I don't have time in the near future to look into changing to the HashiCorp helper, but would be willing to help out and test if someone else implements it.

@nywilken @rickardp do you agree with me that this isn't a bug and rather a feature request/enhancement?

[rickardp]

I haven't looked at the APIs you use (I suppose you use the Go library), but I am quite familiar with the Python library (the one powering the CLI itself), and the way it is designed is that there is indeed a "default" subscription, but all commands take a subscription argument.

IMHO, letting the CLI choose the subscription is not the best choice since it I would then have to manipulate global state to set the subscription. Note that it is very common to separate deployments using different subscriptions, and usually they share the same tenant AD, meaning the default subscription is almost always wrong. The command you mention is probably "as account set", which I consider a bit dangerous for the reasons above (think about deploying to multiple subscriptions using one service principal, where I would always need to guard each command).

Maybe it helps to clarify my use case:
I already have a Docker image that sets up the Azure CLI (hence my interest in the CLI auth). From here I do e.g. ARM deployments, run CLI commands to multiple subscriptions, and this is where I also want to run packer. The CLI auth would make a really simple integration path, otherwise I would have to write some kind of wrapper script to extract the secrets, copy the config and then set the default sub, or manage a separate service principal for the purpose. In my use case, interactive login is not going to work either since this would also need to run on Azure DevOps (there I do "az sp login")

So, feature request or not, I believe without the possibility to set subscription it would IMHO
1) be confusing to users familiar with the Azure CLI
2) lead to poor design by manipulating global config files during script execution

Because of this I would maybe consider not releasing this feature in its current state. (Though I didn't get the difficulty of fixing it, the subscription and token are two completely distinct things, aren't they?)

Also, regarding
" _I would personally prefer the application not to be able to jump out of the context I've selected_"
I would personally argue the opposite - the pipelines set up the credentials, while the resource groups and subscriptions are "one level below", so this is probably ver opinionated (I suspect in our case it is how our IT manages subscriptions from an admin/billing PoV)

[simongottschlag]

You may be correct! Sorry for not thinking about your use case. 👍 Have never used it that way myself.

I won't have time in the near future to look at your use case unfortunately. But if you take a look here you should be able to get started with a PR and I'll help you out the best I can:

• https://github.com/hashicorp/packer/blob/862700b1a59f390df94cf96539041342c1638568/builder/azure/common/client/config.go#L136-L138
• https://github.com/hashicorp/packer/blob/862700b1a59f390df94cf96539041342c1638568/builder/azure/common/client/config.go#L209-L211
• https://github.com/hashicorp/packer/blob/862700b1a59f390df94cf96539041342c1638568/builder/azure/common/client/config.go#L320-L328

[rickardp]

That would certainly be interesting, I'll see if I manage to allocate some time in the upcoming days.