Open rajeshkamal5050 opened 1 year ago
@rajeshkamal5050 - Just to be clear, our templates do not require the AzCLI, but that terraform Azure provider does require AzCLI. To remove this dependency there would need to be a change in the Azure Terraform provider itself.
About what @wbreza mentioned, here are the docs: https://learn.microsoft.com/en-us/azure/developer/terraform/authenticate-to-azure?tabs=bash#terraform-and-azure-authentication-scenarios
We might be able to explore creating a service principal, just like we do for pipeline config. I will try to put a demo together and see if it works.
If it works, at some point, probably before provision
, azd would check if teamplate is terraform
and if there is already a service principal info (tenant/appid/secretid) within the configuration. If the principal info is missing, azd would try to create it.
It worked. I proposed the next flow:
azd provision
(or azd up
), azd should check if:
service-principal
is set up in the env (appId, tenant, secret). If yes, azd just continues and let terraform to use it.service-principal
is found, then azd prompt user something like: How do you want to authenticate Terraform to Azure?
, and show a list like:
Create a new service principal
. This makes azd to automatically create a service-principal and set it up. Then let terraform to use it. Use an existing service principal
. This will make azd to prompt for appId
and secret
(the tenant is already known by azd)Use az log in
. Add this option only when az
was found but without login. Then lauch az login
from azd.Cancel
. Allow user to cancel the operation.Let me know what you think.
@weikanglim @ellismg for feedback as well.
I am happy to bring the implementation based on what we decide here.
@gkulin for awareness. We link to Terraform official doc for authentication using az cli (https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/azure_cli)
Wrong Grace,@puicchan. Should be @gkulin
Wrong Grace,@puicchan. Should be @gkulin
Opps! Fixed. Thanks @savannahostrowski.
Here's what terraform supports for authN: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs#authenticating-to-azure
Here's terraform's code module for authN: https://github.com/hashicorp/go-azure-helpers/tree/main/authentication
They seem to be tied directly to az
instead of using the identity libraries (which wasn't yet available) for user-login scenarios. I suspect that it also helps with their tenant resolution in multi-tenancy scenarios (they pass az account get-token --subscription <SUB_ID>
that will automatically resolve).
I don't think an ask for terraform
to use azd
instead of az
is reasonable. It sounds somewhat circular since azd
is meant to extend and integrate with terraform
as an IaC provider. A protocol like using HTTP via MSI endpoint could be used as an indirection but is still hacky for what the protocol is meant for.
I think the feature of az
deprecation needs to be looked at holistically from Microsoft's point of view. The fundamental question is: what should applications depend on, if they want to develop an Azure application? For various reasons (and ones that similar to why we chose to avoid az
's dependency), I think it should not be the az
CLI, but a library. And thus we arrive at the same plan that we've been pushing for to create a central identity store that isn't bundled with az
.
Hi, we are using terraform quite extensively and i would love to have support for azd
The azurerm
provider is using az
token to get authenticate as mentioned @weikanglim
The helper module is github.com/Azure/go-autorest/autorest/azure/cli
So i guess using token from azd
shouldn't be a issue if there is helper module available.
FYI: Terraform CLI is using own (independent on provider) authentication on backend storage, however this already support MSAL library.
The second option may be azd
will wrap az login
? Or have option to login with token from az
like terraform does?
@petr-stupka , I created a PR to add azd as auth Authorizer: https://github.com/hashicorp/terraform-provider-azurerm/pull/22827
I am not sure how long it can take for it to be accepted, but you can start using it if you checkout the branch and build/install the azurerm
provider locally. Then you can tell terraform
to use that azurerm
provider by using the ~/.terraformrc
file with something like:
provider_installation {
# Use /home/developer/go/bin as an overridden package directory
# for the hashicorp/azurerm provider. This disables the version and checksum
# verifications for this provider and forces Terraform to look for the
# azurerm provider plugin in the given directory.
dev_overrides {
"hashicorp/azurerm" = "/home/vivazqu/go/bin"
}
# For all other providers, install them directly from their origin provider
# registries as normal. If you omit this, Terraform will _only_ use
# the dev_overrides block, and so no other providers will be available.
direct {}
}
@vhvb1989, just 👍🏼 👍🏼 👍🏼
Tested and here is the feedback.
AZD
azd provision
seems to work as expected
use_cli
must be set to false otherwise az
is used by default
use_cli = false
use_azd = true
Terraform
Using provider.conf.json
{
"storage_account_name": "${RS_STORAGE_ACCOUNT}",
"container_name": "${RS_CONTAINER_NAME}",
"key": "azd/azdremotetest.tfstate",
"resource_group_name": "${RS_RESOURCE_GROUP}",
"use_azuread_auth": true
}
Initializing the backend...
╷
│ Error: Error building ARM Config: obtain subscription(<subscriptionid>) from Azure CLI: parsing json result from the Azure CLI: waiting for the Azure CLI: exit status 1: ERROR: Please run 'az login' to setup account.
Seems like creds comming from again from az
- hashicorp/terraform/internal/backend/remote-state/azure
Docs for backend - https://developer.hashicorp.com/terraform/language/settings/backends/azurerm
Azd terraform templates require Az CLI. This is primarily due to TF Azure Provider has dependency with Az CLI for the authn context. Let us investigate to see if there is a way for us to pass Azd's authn context to TF Azure Provider and make it use instead of an Az CLI call.
If there is no capability exposed in the TF side. Let's file an upstream bug on TF. @wbreza @ellismg