Closed Pieeer1 closed 1 month ago
Hi @Pieeer1, thanks for suggesting this. Whilst I appreciate the potential utility here, we won't be adding the ability to provide a bare access token to the provider. There are multiple reasons that this does not scale and potentially causes more issues.
Instead, support for a desired authentication mechanism should be implemented in the provider and/or SDK. There are a number of objective and subjective criteria we try to apply when considering additional authentication methods, including but not limited to:
So unfortunately we will not be able to add the ability to consume a bare access token, as it simply doesn't scale and will block future work in the provider.
From where do you plan to source access tokens? It may be that we can consider implementing direct support for a new authentication mechanism, subject to the above considerations.
Taking the above into account, I'm going to close this issue and the corresponding PR, but am happy to continue the discussion in this thread. Thanks!
@manicminer That's entirely fair. The temporary lifetime of the tokens is an issue I noted above. This is really just an unfortunate scope issue with the user_impersonation scope being required for the tenant creation functionality. This requires user interaction obviously, so tenants IE https://github.com/hashicorp/terraform-provider-azuread/issues/1263 would not be able to function entirely.
The tokens would be sourced ideally from the
az account get-access-token
(same way this provider accesses them through the azure cli authorizer)
If this functionality is never implemented, and user_impersonation is not changed as the scope, 1263 becomes nigh impossible.
Do you know a way to get a token from Azure CLI with the necessary scope(s)?
We have some preliminary ideas for improvement in this area, but if there's a way to shoehorn Azure CLI to provide a working token I'd be keen to look at that.
I played around with that on another branch before realizing it was a larger change than I initially thought, as the way the scopes are attached to the environments are a little tough. Additionally, it requires user interaction to login using a user_impersonation scope. When you do a default az login
and it opens a browser, that is the scope that you receive.
Unfortunately, I think the protections provided by the user_impersonation scope make this difficult to automate. Example:
This happens even though I am logged in with the user impersonation scope:
To add on, this does not verify the scope the az cli is logged in under. It is just the default for the cli when running locally.
Community Note
Description
I would like to add the ability to authenticate through bringing your own auth token. This would allow for the user_impersonation token to be utilized with cloud environments/gtihub actions/ado pipelines by doing the following:
az login
az account get-access-token
Taking that token as input, setting to the environment variable, and using that to scaffold environments as a user. This would in my opinion be useful to have as creation of certain resources (tenants) requires the user_impersonation token.One Potential Issue is the lack of refresh-ability with the token, as msal tokens traditionally last 60~ minutes. I think the benefits outweigh the negative in this case.
New or Affected Resource(s)
provider "azuread" {}
Potential Terraform Configuration
References
Tenant Creation Feature which would benefit from this-> https://github.com/hashicorp/terraform-provider-azuread/issues/1263 Scope Required as user_impersonation for CIAM tenants here -> https://learn.microsoft.com/en-us/rest/api/activedirectory/ciam-tenants/create?view=rest-activedirectory-2023-05-17-preview&tabs=HTTP
0000