consul kv command does not pass CONSUL_HTTP_TOKEN

[daveadams]

consul version

Client: 0.7.1
Server: n/a

Operating system and Environment details

Ubuntu 16.04

Description of the Issue (and unexpected/desired result)

From consul kv get --help:

  -token=<value>          ACL token to use in the request. This can also be
                          specified via the CONSUL_HTTP_TOKEN environment
                          variable. If unspecified, the query will default to
                          the token of the Consul agent at the HTTP address.

So, I expect the following two commands to have equivalent behavior:

$ consul kv get -token xyz config/test
$ CONSUL_HTTP_TOKEN=xyz consul kv get config/test

However, the first command with -token xyz specified as a CLI option, passes the token to the API correctly, whereas the second command with the environment variable only does not pass the token to the API.

Reproduction steps

Use netcat to verify, first, on a machine not running Consul, set netcat to listen to port 8500:

$ nc -l 8500

Then in another window, run the first command above. It will hang, but in the netcat terminal you can see the HTTP request that is sent:

GET /v1/kv/config/test HTTP/1.1
Host: 127.0.0.1:8500
User-Agent: Go-http-client/1.1
X-Consul-Token: xyz
Accept-Encoding: gzip

Hit Ctrl-C on the Consul command. This will also kill the netcat process. Restart netcat, and run the second command using the environment variable, and in the netcat window you will see:

GET /v1/kv/config/test HTTP/1.1
Host: 127.0.0.1:8500
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip

In other words, consul kv command does not pass through the CONSUL_HTTP_TOKEN environment variable to the X-Consul-Token header as the documentation suggests.

[arunkumar-m]

Note: This issue will also appear for CONSUL_HTTP_ADDR env variable as well.

[daveadams]

For me, CONSUL_HTTP_ADDR works fine. I'm helping some developers get access to our Consul system from their workstations, and I have them pull a temporary Consul token from Vault, then set their environment to talk to a reverse proxy I've set up to allow VPN access to the Consul HTTP API, so the actual workflow I get is:

$ vault auth -method=ldap username=myuser
[...omitted...]
$ consul kv get config/myapp/myvalue
Error querying Consul agent: Get http://127.0.0.1:8500/v1/kv/config/myapp/myvalue: dial tcp 127.0.0.1:8500: getsockopt: connection refused
$ export CONSUL_HTTP_ADDR=gateway.consul.mycorp.com:443
$ export CONSUL_HTTP_SSL=true
$ export CONSUL_HTTP_TOKEN=$( vault read -field token consul/creds/developer )
$ consul kv get config/myapp/myvalue
Error! No key exists at: config/myapp/myvalue
$ consul kv get -token=$CONSUL_HTTP_TOKEN config/myapp/myvalue
correct-config-value

There's no Consul agent running on my machine, as you can see in the first attempt to run the command without the CONSUL_HTTP_ADDR environment variable set.

[arunkumar-m]

Yes, you are right, it is honoring CONSUL_HTTP_ADDR.
Submitted a pull request for the CONSUL_HTTP_TOKEN bug. #2569
#2610

[ashald]

Same issue with snapshot command in v0.7.2...

[asobrien]

For completeness, the following commands don't currently respect the CONSUL_HTTP_TOKEN environment variable:

• consul kv delete
• consul kv export
• consul kv get
• consul kv import
• consul kv put
• consul snapshot restore
• consul snapshot save

These commands always set the token value to the value passed via the cli (which defaults to "" when -token is not called), the following files are affected by this pattern:

• command/kv_delete.go
• command/kv_export.go
• command/kv_get.go
• command/kv_import.go
• command/kv_put.go
• command/snapshot_restore.go
• command/snapshot_save.go

The complete set of changes required are reflected here.

[slackpad]

These be fixed by #2717, which will centralize handling of the CLI options and environment variable handling.