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

Set VAULT_ADDR in process env when using token helper #651

Conversation

ianferguson
Copy link
Contributor

Community Note

  • Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
  • Please do not leave "+1" comments, they generate extra noise for pull request followers and do not help prioritize the request

Description

Closes #526

I'm opening this as a draft pull request because I'd like to get the maintainers thoughts on the approach being taken.

I've been using a token helper that stores tokens based on the configured value of VAULT_ADDR in the environment while using terraform across many Vault clusters, and having support for this would make it much easier to run changes en masse and avoid needing to manage setting and unsetting the VAULT_ADDR for different applies based on what was configured in the Vault terraform provider.

Release note for CHANGELOG:

VAULT_ADDR is always set to the provider's address attribute when a Vault token helper is used to resolve a Vault token.

Output from acceptance testing:

  • None at this time -- if the general approach is ok with the maintainers, I can write up some specific tests for this.

@ghost ghost added the size/XS label Jan 15, 2020
@ianferguson ianferguson marked this pull request as ready for review February 11, 2020 16:43
@tyrannosaurus-becks
Copy link
Contributor

Thank you for your PR. I have thoughts and questions on it and to avoid splitting the conversation, I'm going to comment on the linked issue further.

@tyrannosaurus-becks tyrannosaurus-becks self-assigned this Feb 21, 2020
@ianferguson
Copy link
Contributor Author

@tyrannosaurus-becks sounds good! I was offline all last week, so will check in on the discussion on the original issue, thanks for following up on this

@@ -116,8 +116,7 @@ func getTestRMQCreds(t *testing.T) (string, string, string) {
}

// A basic token helper script.
const tokenHelperScript = `
#!/usr/bin/env bash
const tokenHelperScript = `#!/usr/bin/env bash
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The extra newline added after the backtick caused the script to come out as


#!/usr/bin/env bash
echo "helper-token"

With the shebang on the 2nd, rather than 1st, line. When executed as an exec by the cmd package for a user using fish shell the follow error silently happened:

> /usr/local/bin/fish -c $tmpScriptPath
Failed to execute process '$tmpScriptPath'. Reason:
exec: Invalid argument
The file '$tmpScriptPath' is marked as an executable but could not be run by the operating system.

Removing the line break here fixes that otherwise perplexing test failure that non-bash users may see

}()
}
err = os.Unsetenv(config.ConfigPathEnv)
reset, err := tempUnsetenv(config.ConfigPathEnv)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ended up using TestAccProviderToken as a template for writing TestAccProviderVaultAddEnv, and in the process of reading them and writing another similar test consolidated some of the setup/tear down refactoring -- if this is not ok I can unwind the changes here

@ianferguson
Copy link
Contributor Author

@tyrannosaurus-becks I've updated the PR with a flag (add_address_to_env) for turning the new functionality on and off (and it defaults to the current non-adding behavior), added tests and updated the documentation.

The tests pass for me against a local vault server -dev, but fail on circleci with:

--- FAIL: TestAccProviderVaultAddrEnv (0.02s)
    --- FAIL: TestAccProviderVaultAddrEnv/AddAddressToEnvNotConfigured (0.01s)
        provider_test.go:683: bad token value: want "https://pretest-env-var.example.com", got "http://127.0.0.1:8200"
    --- FAIL: TestAccProviderVaultAddrEnv/AddAddressToEnvIsFalse (0.01s)
        provider_test.go:683: bad token value: want "https://pretest-env-var.example.com", got "http://127.0.0.1:8200"
    --- FAIL: TestAccProviderVaultAddrEnv/AddAddressToEnvIsTrue (0.00s)
        provider_test.go:683: bad token value: want "https://provider.example.com", got "http://127.0.0.1:8200"

Which I'll take a look at on Monday or Tuesday, but otherwise I think this should be about ready for review based on what we discussed on #526

Copy link
Contributor Author

@ianferguson ianferguson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got the tests passing -- it turns out the way that env vars were being configured for these tests, combined with how ExternalTokenHelper's in hashicorp/vault turn the configured binary value into an actual os exec.Cmd struct resulted in the preconfigured test env vars (including VAULT_ADDR=http://127.0.0.1:8200) being reloaded by the shell that ended up invoking the external token helper command. I addressed this as surgically as I could, but let me know if y'all would prefer a different approach.

@tyrannosaurus-becks this should be ready for a review whenever y'all have a chance

// when the ExternalTokenHelper's command is formatted into a shell invocation to exec here:
// https://github.com/hashicorp/vault/blob/master/command/token/helper_external.go#L117-L132
//
resetBashEnvEnv, err := tempUnsetenv("BASH_ENV")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think its possible that a better fix here might be to move all of the vars set here: https://github.com/terraform-providers/terraform-provider-vault/blob/f42716aae3aebc8daf9702dfa20ce3f8d09d9f4d/.circleci/config.yml#L26-L32 to an Environment object in the circleci yaml configuration for the container these tests are run in, as documented here: https://circleci.com/docs/2.0/env-vars/#setting-an-environment-variable-in-a-container

That being said, I don't know the finer details of these tests or how circle manages those environment variables/containers across multiple steps well enough to be confident that that wouldn't have any unintended side effects, so I took a more surgical route to fixing these tests that rely on testing the VAULT_ADDR change when a token helper is called.

@ianferguson ianferguson force-pushed the set_vault_address_into_process_env branch from 12dd847 to bfaad51 Compare March 17, 2020 13:41
@ghost ghost added size/XL and removed size/L labels Mar 17, 2020
Copy link
Contributor

@tyrannosaurus-becks tyrannosaurus-becks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ianferguson thank you for doing this! Much appreciated. Looks great.

@tyrannosaurus-becks tyrannosaurus-becks merged commit a34dea4 into hashicorp:master Mar 30, 2020
dandandy pushed a commit to dandandy/terraform-provider-vault that referenced this pull request Jun 17, 2021
* Set VAULT_ADDR in process env when using token helper

* Add add_vault_addr_to_env argument, tests, udpate docs

* Unset BASH_ENV to avoid clobbering VAULT_ADDR test values

* Add changelog line
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Export VAULT_ADDR env variable when calling a token helper
3 participants