Hi there,
I’m running vault in a HA configuration with a consul storage backend. At startup vault gives me the error message:
[ERROR] service_registration.consul: error running service registration: redirect address must not be empty
This issue is similar to the one described here: Service Registration Error: “redirect address must not be empty”
Specifying api_addr = “http://127.0.0.1:8200”
in the configuration as suggested in the discussion works and the message disappears from the logs.
According to the documentation (Server Configuration | Vault | HashiCorp Developer) I should be able to alternatively set this value via the environment variable VAULT_API_ADDR
. But when only setting the environment variable and not adding the setting to the config file, I still get the error message.
Am I missing something here?
Do you start the process with the environment variable set (it’s spawning a subshell, I guess)?
VAULT_API_ADDR=... vault...
Alternatively you’ll have to set the environment variable in the systemd unit file.
I think only setting the variable in your shell and starting vault won’t help. You’ll have to pass it to the process/ subshell.
My bad, I forgot to mention I’m running this in a kubernetes environment. The environment variables are set via the pod manifest so I think they are properly set in a “system-wide” manner before vault is started.
I ran a few tests to make sure that variables are actually set.
This is how I originally configured the vault container to run:
# this runs the 'vault server' command via docker-entrypoint.sh
...
containers:
- name: vault
args:
- server
image: vault:1.4.1
...
I replaced the args
section with the following:
# this just runs the 'env' command
command:
- env
In a second run I replaced it with this one:
# this runs the 'env' command via docker-entrypoint.sh
args:
- env
Both cases lead to successfully printing all the set environment variables:
...
VAULT_API_ADDR=https://x.x.x.x:8200
VAULT_CLUSTER_ADDR=https://x.x.x.x:8201
VAULT_REDIRECT_ADDR=https://x.x.x.x:8200
SKIP_CHOWN=nonempty
SKIP_SETCAP=nonempty
...
Note that I successfully use both SKIP_… variables to run vault as non-root (I’m running the official vault docker image ).
This is how the variables are set in the container manifest:
env:
- name: SKIP_CHOWN
value: nonempty
- name: SKIP_SETCAP
value: nonempty
- name: VAULT_REDIRECT_ADDR
value: https://x.x.x.x:8200
- name: VAULT_API_ADDR
value: https://x.x.x.x:8200
- name: VAULT_CLUSTER_ADDR
value: https://x.x.x.x:8201
While env
prints all the variables just fine, I still get the error message when starting vault as mentioned above:
2020-05-15T13:33:17.249Z [ERROR] service_registration.consul: error running service registration: redirect address must not be empty
When setting the option api_addr = "https://127.0.0.1:8200"
in the config and not changing anything except recreating the vault pod, the message will not show anymore.
@Wolfsrudel I was able to verify that the environment variable VAULT_API_ADDR
is exposed to the vault binary:
Not specifying VAULT_API_ADDR
leads to this output:
==> Vault server started! Log data will stream in below:
2020-05-18T15:18:53.538Z [INFO] proxy environment: http_proxy= https_proxy= no_proxy=
2020-05-18T15:18:53.635Z [WARN] no `api_addr` value specified in config or in VAULT_API_ADDR; falling back to detection if possible, but this value should be manually set
2020-05-18T15:18:53.635Z [ERROR] service_registration.consul: error running service registration: redirect address must not be empty
When specifying VAULT_API_ADDR
the WARN
line from above is not shown:
==> Vault server started! Log data will stream in below:
2020-05-18T15:16:27.098Z [INFO] proxy environment: http_proxy= https_proxy= no_proxy=
2020-05-18T15:16:27.112Z [ERROR] service_registration.consul: error running service registration: redirect address must not be empty
This output also shows that even so vault correctly detects that VAULT_API_ADDR
is set, vault still throws the initial error. This can only be prevented by specifying the api_addr
option in the configuration file which, according to the documentation, should be equal to setting the VAULT_API_ADDR
environment variable.
This looks like a bug to me.
1 Like
If it’s a known bug already we should just wait for a bugfix release and use the workaround 'til then.
this is fixed in version 1.4.2