For this credential helper to work, two important things are needed which must be in sync
The vault URL
Valid credentials for the vault cluster at the URL
It's expected that the config file would contain both of these, and that they would be consistent with each other, so all is well.
But if a docker/podman push/pull command is run in an environment with VAULT_ADDR set pointing at a different vault cluster than the credentials are valid for, the push/pull operation will fail because the credentials at the hardcoded path in the config file aren't valid for the URL provided by the environment variable. While some auto-auth login methods allow themselves to be completely configured via environment variables, not all of them do, e.g. approle, so the config file must be used).
Having to make sure the VAULT_ADDR env var is not set in a conflicting way is confusing, and counterintuitive.
I guess the env var is probably being picked up by the vault auto auth code, rather than the credential helper code itself, so it's not necessarily a bug in this project, but it's most definitely a usability issue with this credential helper.
I wonder if anything could be done in this credential helper, like dropping the VAULT_ADDR env var when the helper is first launched, so the auto-auth code doesn't see it?
Perhaps only if no other auth-related VAULT_* env vars are set?
Or only if an DCVL_IGNORE_VAULT_ADDR=1 env var is set? (This could be set system-wide where appropriate and avoid end uses having to manage their own environment so carefully)
I could of course wrap docker-credential-vault-login in a helper script which drops the VAULT_ADDR environment variable, but that only solves the problem for me.
Reproduction Steps
Steps to reproduce this issue, eg:
Configure the DCVL config file with a valid vault URL and credentials
Test a container push/pull to confirm the operation is successful
set VAULT_ADDR env var pointing at a different vault cluster
Overview of the Issue
For this credential helper to work, two important things are needed which must be in sync
It's expected that the config file would contain both of these, and that they would be consistent with each other, so all is well.
But if a docker/podman push/pull command is run in an environment with VAULT_ADDR set pointing at a different vault cluster than the credentials are valid for, the push/pull operation will fail because the credentials at the hardcoded path in the config file aren't valid for the URL provided by the environment variable. While some auto-auth login methods allow themselves to be completely configured via environment variables, not all of them do, e.g. approle, so the config file must be used).
Having to make sure the VAULT_ADDR env var is not set in a conflicting way is confusing, and counterintuitive.
I guess the env var is probably being picked up by the vault auto auth code, rather than the credential helper code itself, so it's not necessarily a bug in this project, but it's most definitely a usability issue with this credential helper.
I wonder if anything could be done in this credential helper, like dropping the VAULT_ADDR env var when the helper is first launched, so the auto-auth code doesn't see it?
VAULT_*
env vars are set?DCVL_IGNORE_VAULT_ADDR=1
env var is set? (This could be set system-wide where appropriate and avoid end uses having to manage their own environment so carefully)I could of course wrap docker-credential-vault-login in a helper script which drops the VAULT_ADDR environment variable, but that only solves the problem for me.
Reproduction Steps
Steps to reproduce this issue, eg:
A copy of your
config.json
fileOperating system and Environment details
N/A
Log Fragments
N/A