Use different environment variables than terraform-provider-azurerm

[RockyMM]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritise this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritise the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

AzureAD provider uses ARM_CLIENT_ID and many other ARM_* environment variables to authenticate to Azure. This is proving to be a bit of an issue for my use case, where I need to perform some changes in the Azure AD B2C tenant. In this tenant I have a different service principal than in the parent subscription and all the ARM_* parameters are different. This leads to a difference in where I configure the azurerm provider with environment variables, but azuread provider is configured with variables and the secret tfvar file is injected during the build process.

Potential Terraform Configuration

I propose that the prefix is changed so that we configure authentication like this:

> $env:AAD_CLIENT_ID = "00000000-0000-0000-0000-000000000000"
> $env:AAD_CLIENT_SECRET = "12345678-0000-0000-0000-000000000000"
> $env:AAD_TENANT_ID = "10000000-0000-0000-0000-000000000000"
> $env:AAD_SUBSCRIPTION_ID = "20000000-0000-0000-0000-000000000000"

[manicminer]

@RockyMM Thanks for suggesting this. As you might have guessed, we intentionally continue to use the same environment variables to ease configuration for the vast majority of practitioners (and also for historical reasons as the early AzureAD provider resources were originally embedded in the AzureRM provider).

I do not expect that we'd look to change this as it would impact the majority of users. However, I have some suggestions that might be of help to you.

1. Use the same credentials across both tenants (recommended)

Create a multi-tenant application in your primary tenant, and create linked service principals in each tenant you want to manage. This way, you'll be able to use the same credentials (client secret, certificate, or OIDC) across multiple tenants and the only provider properties you'd need to change are tenant_id (for AzureAD and AzureRM) and subscription_id (for AzureRM). Setting up this topology can also be done entirely with Terraform.

2. Use OIDC (recommended where possible)

If you're running Terraform in a managed environment that supports OIDC, e.g. in a CI setting, then OIDC offers a credential-free way to authenticate both providers. We have built-in support for GitHub Actions, as well as support for generic OIDC providers where the ID token might be supplied as an environment variable, or as the content of a file in the filesystem. You can use OIDC with a single multi-tenant application, which yields the least configuration, or with multiple applications, by specifying the appropriate client ID as an environment variable or in your provider block.

3. Use input variables to specify the credentials

If you cannot use a multi-tenant application, you can use input variables to inject the appropriate credentials and consume these in your provider block. This might take the form of a tfvars file, or perhaps a wrapper script or CI automation to add these to the terraform command line (taking any reasonable precautions on multi-user systems). It looks like you might be doing this in some form already - it's worth noting that explicit configuration in the provider block does take precedence over environment variables so this method is useful for overriding values.

Hope this helps! Since I don't believe we'll look to change the current behavior, I'm going to close this issue as unplanned, but please feel free to open additional feature requests for authentication methods that we don't support, or if you find a way we can improve the existing supported authentication methods. Thanks!

[RockyMM]

Hi @manicminer, thanks for a very detailed response. Over the holidays, I will definitely investigate could we migrate to the approach (1) that you described. We are already using approach (3).

Thanks again!