Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vault runs with the default listener of 127.0.0.1, but Docker requires that applications inside containers listen on 0.0.0.0 #12579

Closed
TMFEspresso opened this issue Sep 17, 2021 · 1 comment

Comments

@TMFEspresso
Copy link

Describe the bug
The only way to run vault login -method=oidc from inside a container is to specify the listenaddress parameter to be 0.0.0.0.

To Reproduce
If you try to run the following:

docker run --rm -it \
  --cap-add=IPC_LOCK \
  --volume ${PWD}:/app \
  -p '8200:8200' \
  -p '8250:8250' \
  -e 'VAULT_ADDR=https://remote-vault-instance-that-auths-via-oidc.com' \
  vault:latest vault login -method=oidc

And then you paste the resulting redirect url into your browser, you will get a 404.

This is because vault as an application is listening on 127.0.0.1 from inside the container. Docker does not like this.

How you can determine that Vault is listening on that address is by running the following:

# start up a vault container 
docker run --rm -it \
  --cap-add=IPC_LOCK \
  --volume ${PWD}:/app \
  --name=vault \
  -p '8200:8200' \
  -p '8250:8250' \
  -e 'VAULT_ADDR=https://remote-vault-instance-that-auths-via-oidc.com' \
  vault:latest /bin/ash

# install net-tools so you get netstat
apk add net-tools

# run the vault login command, without defining a different listenaddress
vault login -method=oidc

# while the `vault login` is still running, in another tab/window, exec into the docker container 
docker exec -it $(docker ps -q --filter "name=vault") /bin/ash

# run netstat like so:
netstat -anp

You should get something like:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:8250          0.0.0.0:*               LISTEN      28/vault
tcp        0      0 172.17.0.3:40342        10.10.5.147:443         ESTABLISHED 28/vault

In order for localhost:8250 to correctly map from your host machine, to Docker, and to your application, that 127.0.0.1:8250 blurb needs to be 0.0.0.0:8250 (or something like :::8250).

To cross-reference this with a properly configured application's container, like nginx, we get this:

docker exec -it $(docker ps -q --filter "name=nginx") /bin/bash
root@c761ba56b8aa:/# netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1/nginx: master pro 
tcp6       0      0 :::80                   :::*                    LISTEN      1/nginx: master pro 

If we assume that that output is what is needed for something like localhost:80 to map from a host machine to an nginx application inside a Docker container, we can run our vault login test again like so:

# while exec'd into the vault container we spun up before, run this:
vault login -method=oidc listenaddress=0.0.0.0

# open a new tab/window, exec into that vault container, then run this:
netstat -anp

And you see that netstat is showing similar output to what nginx is utilizing:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 172.17.0.3:40346        10.10.5.147:443         ESTABLISHED 63/vault
tcp        0      0 :::8250                 :::*                    LISTEN      63/vault

And more importantly, you can visit the url output by vault login -method=oidc listenaddress=0.0.0.0 in your host machine's browser, and the redirect works properly, and then the login succeeds inside the container.

Expected behavior

In a perfect world, running vault login -method=oidc from inside a container would just work with no additional parameters, since the container and the Vault application inside it would automatically set the listenaddress to 0.0.0.0.

If this is unachievable, PLEASE FOR ALL THE KITTENS ON THE INTERNET update your Docker Hub docs to include that parameter in this use case since this is not at all straightforward.

Environment:

  • Vault Server Version (retrieve with vault status): 1.8.1
  • Vault CLI Version (retrieve with vault version): Vault v1.8.2
  • Server Operating System/Architecture: OSX 11.3.1 & Docker 20.10.8, build 3967b7d

Vault server configuration file(s): none, just the base container

@TMFEspresso
Copy link
Author

TMFEspresso commented Sep 17, 2021

Ahhhh I posted this in the wrong area. Moving to docker-vault.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant