backend/http: Support for bearer tokens from environment

[the-maldridge]

Current Terraform Version

$ terraform version
Terraform v0.12.26

Your version of Terraform is out of date! The latest version
is 0.12.28. You can update by downloading from https://www.terraform.io/downloads.html

Use-cases

Presently, terraform backends may store credentials on disk in plain text. This is only the case for some providers, as many providers provide a client specific way of fetching credentials from the environment, or from other secure storage. I would like to be able achieve this same level of security with the http backend, which has the flexibility to work with custom state storage systems (such systems are very useful for breaking bootstrapping loops where terraform is used to provision other infrastructure that might otherwise be a suitable state store).

Attempted Solutions

I have used the http backend for some time now with a backend that supports locking. This works exceptionally well and functions as documented. However, it does mean that since the state storage backend uses SSO that I have to be more careful than usual about the credentials on disk.

As I am the author of the state backend, I have considered abusing the basic auth configuration to send a special user value, such as __JWT__ that would then inform the application that the "password" is in fact a signed token. While this would resolve the issue that SSO credentials are saved to disk, it does not make the token particularly easy to rotate, since this would involve re-initializing the backend.

Proposal

I suggest altering the HTTP backend in such a way that one of two things is possible:

• Option A: Support reading the basic auth credentials from environment variables if they are not set in the backend config. This would allow the solution I originally planned to use with a minimum of modification. It also enables chaining commands together to inject short term credentials for terraform to make time-bound access to remote state.
• Option B: Support reading a single authorization token from an environment variable and presenting it as Authorization: Bearer <token> in the request. This would supercede the use of basic auth and would permit more complex authentication schemes to be possible based on external helpers.

I prefer option B since it is in my opinion the more correct way to accomplish a short lived access token to a remote service.

[tjhiggins]

looks like there is a pr: #21510
also this is prob a duplicate of #22526