Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update the vendor azure-sdk-for-go from 10.0.2 to 18.1.0 #18476

Closed
wants to merge 2 commits into from

Conversation

alphalzh
Copy link

@alphalzh alphalzh commented Jul 17, 2018

Background: #16763
I would like to add support for using SAS tokens for azurerm backend authentication, since it's a more secure workflow than using long-lived access keys to authenticate an azurerm remote backend. However, the current version of azure-sdk-for-go (version 10.0.2) in vendors/ does not support SAS tokens, but it is introduced in a later version. So I updated the azure-sdk-for-go to use the latest version.

Testing:

  • I confirmed that azure-sdk-for-go is only used for remote Azure tfstate backend. Thus, no existing functionalities related to deploying resource to Azure will be affected.
  • I verified that all unit tests pass.
  • I also manually verified that Azure tfstate backend works properly. terraform init will correctly initialize the remote backend, terraform apply will correctly update/create tfstate in Azure storage account if remote backend is used.

Note: mastr/guid is a requirement for the newer version of azure-sdk-for-go and is added as a dependency.

@alphalzh alphalzh changed the title Update the vendor azure-sdk-for-go Update the vendor azure-sdk-for-go from 10.0.2 to 18.1.0 Jul 20, 2018
@tombuildsstuff
Copy link
Contributor

hey @alphalzh

Thanks for this PR - apologies for the delayed response here!

To give a little more information on our plans for the AzureRM Backend - currently most of the authentication logic used by the Backend is duplicated between the AzureRM Provider and the Backend - which both use a different version of the SDK.

In the near future we're intending to refactor this authentication related logic out into it's own package, which will allow us to add support for multiple authentication mechanisms within the Backend (e.g. for example, this'd allow us to support Azure CLI / CloudShell etc - and potentially other authentication types such as SAS Tokens). From a UX perspective this should mean it's also required for users to specify the name of the storage account/container (and possibly the resource group) - meaning the backend configuration becomes considerably simpler than it is today.

Since we're taking a slightly different direction here I'm going to close this PR for the moment - but I'd like to thank you for this contribution :)

Thanks!

@ghost
Copy link

ghost commented Apr 1, 2020

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants