Terraform-provider-azurerm: client_secret encoding

[MMollyy]

Community Note

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

Description

Hello,

I am skipping the community resources to ask this question, because it already is a running ticket with Azure AD support from Microsoft. Where the engineer is now asking me to confirm the following, which I do not read about in the documentation:

On this page: https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow
It shows for a client_secret that it needs to be URL-encoded. My question is, does terraform azurerm provider URL-encode the client_secret by default?

I am asking this because our org is currently in the process of changing non-expiring secrets, that terraform pipelines use, to short lived secrets. (secrets created JIT, and removed once pipeline completes/fails)
The non-expiring secrets are not popping out errors at all, but the short lived secrets are popping out errors maybe 10%, 20% or 30% of the time. There is no base line to be found as for when it would pop out the error.

The Azure AD engineer is telling me that the logs show it is giving the error because the format of the client_secret is not being accepted because it is not URL-encoded whenever the error occurs.

Just in case, here is the the error:

* provider.azurerm: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to https://management.azure.com/subscriptions/f456ggr-45gfsf-45fsdf/providers?api-version=2017-05-10: StatusCode=401 -- Original Error: adal: Refresh request failed. Status Code = '401'. Response body: {"error":"invalid_client","error_description":"AADSTS7000215: Invalid client secret is provided.\r\nTrace ID: 119894af-8cd0-4fd8-8595-ed6ef2b06f00\r\nCorrelation ID: 5d88af2b-a97f-4898-a607-6712eb8a010e\r\nTimestamp: 2019-04-10 14:58:17Z","error_codes":[7000215],"timestamp":"2019-04-10 14:58:17Z","trace_id":"119894af-8cd0-4fd8-8595-ed6ef2b06f00","correlation_id":"5d88af2b-a97f-4898-a607-6712eb8a010e"}

Getting this error during terraform plan, as well as terraform apply steps.
Current azurerm provider: 1.23.0 & 1.3.1 both tested

The short lived secret generated is used for the Azure RM provider. I have succesfully completed the terraform apply using this flow. It's just a very unreliable flow with the secret 3 or 4/10 not working because it isn't URL-encoded.

PS: We are not using the Azure AD provider to create anything Azure AD related. In case you're wondering: Azure AD is I&AM (not infrastructure), and we have many other I&AM related challenges that the Azure AD provided cannot help us with.

[kalafut]

@MMollyy From comments on the other ticket it sounds like this has been ruled out, correct?

[MMollyy]

@kalafut Microsoft still mentioned the URL-encoding seems to be incorrect in the failing cases. But development needs to move forward and we've been stuck on this for too long. So I can't say it's been ruled out, as I don't know if Terraform puts default encoding on the client_secret when using it during its operations with the Azure API.

If you like I can drop the ticket number in your mail or something if you'd like a reference point with Microsoft.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!