-agent-address flag should have higher precedence than the env var

[raskchanky]

Description

Resolves #27404

The issue here, as I understand it, is that the VAULT_AGENT_ADDR environment variable takes higher precedence than the -agent-address CLI flag, in violation of what our docs say about how CLI flags should take precedence. The people reporting and commenting on the issue provided a wonderful reproduction shell script that makes this problem easy to see.

From what I can tell, NewClient is doing the right thing, by prioritizing the agent address over the regular address. The main problem is that the API client doesn't have access to CLI flags - it can only work from the config it's given.

I think the fix I've done here is correct, in that 1) the repro shell script now does the right thing in all cases, including the last one and also 2) nothing about the way the CLI parses its config has changed, so all the other callers of api.NewClient() will still get the same behavior they've always gotten.

TODO only if you're a HashiCorp employee

• Backport Labels: If this PR is in the ENT repo and needs to be backported, backport
  to N, N-1, and N-2, using the backport/ent/x.x.x+ent labels. If this PR is in the CE repo, you should only backport to N, using the backport/x.x.x label, not the enterprise labels.
  • If this fixes a critical security vulnerability or severity 1 bug, it will also need to be backported to the current LTS versions of Vault. To ensure this, use all available enterprise labels.
• ENT Breakage: If this PR either 1) removes a public function OR 2) changes the signature
  of a public function, even if that change is in a CE file, double check that
  applying the patch for this PR to the ENT repo and running tests doesn't
  break any tests. Sometimes ENT only tests rely on public functions in CE
  files.
• Jira: If this change has an associated Jira, it's referenced either
  in the PR description, commit message, or branch name.
• RFC: If this change has an associated RFC, please link it in the description.
• ENT PR: If this change has an associated ENT PR, please link it in the
  description. Also, make sure the changelog is in this PR, not in your ENT PR.

[github-actions]

CI Results:
All Go tests succeeded! ✅

[github-actions]

Build Results:
All builds succeeded! ✅

[VioletHynes]

This looks good to me, but one thing I'm not sure about is if we want to add a corresponding proxy-address, as these are kind of 'deprecated' (as is using Agent as an API proxy). (This isn't something I'd block a PR on as this is out of scope for a bug fix)

We don't actually document VAULT_AGENT_ADDR anymore -- in favour of Proxy: https://developer.hashicorp.com/vault/docs/commands#vault_proxy_addr

I'm still approving this, as this still fixes a bug and I'm not sure how widely a new -proxy-address flag would even be adopted, but I thought I'd share the context.

[raskchanky]

@VioletHynes Thanks for the additional context! I don't think adding a new flag would be that big of a deal, and if it lines up more with our recommendations, then it seems worth doing. I'll look at doing that today, if I have time.

[biazmoreira]

@raskchanky Josh, I'm also not sure which flags should stay and which ones should be removed. Maybe something to check with product? Anyways, leaving my approval as well!

[raskchanky]

Just to be clear, I won't be removing any CLI flags.

[VioletHynes]

I agree that no flags should be removed

[raskchanky]

@VioletHynes Whenever you have a free moment and are dying to do some code review, I would appreciate your input and feedback on my latest commit, bd2fbe4. Does this seem like it should do the right thing? I tested it locally with nc and it seems to work. I was looking for where to add tests for something like this but it doesn't look like we have existing tests for this sort of plumbing. 🤷

[VioletHynes]

Looks good! Apologies for sowing a little bit of confusion. We should update to no longer reference Vault Proxy if we are still wanting to bring in -proxy-address

[raskchanky]

After some further discussions with @VioletHynes I've decided to revert that last commit and just keep the original bug fix.