Open rrjjvv opened 1 month ago
I created a test for all sixteen possible combination of flags and environment variables (or lack thereof). Half of them (in my opinion) simply don't make sense and if they occurred, would probably be user or developer bugs. They might be best left as undefined behavior, but I still wanted to enumerate them, figure out my logical expectations, and see the behavior both pre- and post-fix.
Without changes, four out of the sixteen possibilities fail; one is my bug report, one is a variation of my report, and two are "this probably wouldn't happen in the real world". With my proposed changes, all sixteen pass (and all other existing tests continue to pass as well).
I'll create a PR early next week with my proposal unless you indicate you want to hash it out here, or handle it yourselves.
Describe the bug From the docs:
Thus, given
I would expect the 'cli-host' to be used. I do not know if this holds true for every sub-command, but
vault status
andvault read
use the environment variable (I suspect it affects the majority of sub-commands, if not all).To Reproduce I encountered this issue in a live environment (actual running server and agent), but the actual issue does not require these and using
-output-curl-string
is a convenient/quick way to illustrate in isolation.Expected behavior
(using address
http://cli.invalid
, nothttp://env.invalid
)Environment:
vault status
):1.12.6
(but not relevant)vault version
): verified with1.11.6
,1.12.6
,1.16.3
, andmain
Vault server configuration file(s): N/A
Additional context I created a longer reproduction to
I ran this against a few release binaries; all behaved the same, so only showing the oldest version I tried:
This is from
main
(at some point last night), which also has the issue, but with some selective logging to show the flow:So the issue is that on the
command
side, the environment is read early https://github.com/hashicorp/vault/blob/d382103f62643780f406e16f385c536a177702c3/command/base.go#L101 and proceeds to (correctly) prioritize flag values (as well as "agent trumps server") https://github.com/hashicorp/vault/blob/d382103f62643780f406e16f385c536a177702c3/command/base.go#L105-L110 but the problem is that on theapi
side (which has no concept of flags), it performs the same "agent trumps server", with its only data source being the environment https://github.com/hashicorp/vault/blob/d382103f62643780f406e16f385c536a177702c3/api/client.go#L637-L639In short, the
config
on the command side is deliberately/correctly configured before passing it toNewClient
on the api side, butNewClient
isn't fully respecting it.I have a possible fix but I can't validate it, since the test suite (
make test
) has failures (on a pristine checkout). So before spending time trying to figure that out, I figured I'd wait for confirmation that it is indeed a bug and that it should be fixed. As well, the conversation on the PR that introduced these changes made it seem like "agent wins over server" had some nuances and that maybe this 'bug' isn't as straightforward as I thought, and maybe you want to handle it yourselves.