Vault-auto-unseal example, client not set up to talk to server

[IanMoroney]

I used the vault-auto-unseal example to set up a cluster based off the ami created by the vault-consul-ami option example.

It appears that the documentation for the vault-cluster module may be incorrect (unless it's a bug), as the vault client is not set up to talk to the server locally.

I was able to do vault status, confirm it was sealed,
do vault operator init, which unsealed the vault and provided tokens,

then, as per the documentation, do vault read secret/foo, and got the following error:

Error reading secret/foo: Error making API request.

URL: GET https://127.0.0.1:8200/v1/secret/foo
Code: 400. Errors:

* missing client token

As per normal procedure, i did NOT do vault login, as the docs indicated that I didn't need to.

[IanMoroney]

For clarity, the "client" that i'm referring to is the client on the server itself when logged into the server via ssh.

[brikis98]

@Etiene When you're back from vacation, could you look into this?

[rjhornsby]

Forgive me if I'm missing something, but it seems like the step missing is to tell the vault client what token to use.

vault operator init, which unsealed the vault and provided tokens

It's correct that you do not need to vault login but you do need to configure the client. You can put the token in a file ~/.vault-token, or IIRC you can also set the env var VAULT_TOKEN.

vault login provides a token. The init command already provided a root token, which is why the auth step isn't required in this situation.

Edit: corrected auth to login -- auth configures authentication methods, while login authenticates you to vault on a previously configured method.

[queglay]

I am also finding that when I apply the auto unseal example that I cannot use the vault commands. If I don't use the unseal example, the deployment is fine though. It's possible that it is just my own unfamiliarity, but I'm not sure what the next steps would be.

I decided to create a fork to implement a turn key example in cloud9 with auto unseal, and share any challenges along the way (I'll submit a PR with my results).

https://github.com/firehawkvfx/firehawk-main

I created a tag to demonstrate the problem which you can replicate with git clone --recurse-submodules --branch v0.0.1 https://github.com/firehawkvfx/firehawk-main.git

This is an example of the implementation, presently using a fork of this submodule. The long term goal of this fork is to eventually provide a best practices vault with HA and auto unsealing deployed from cloud9 to help with the secret 0 problem and avoid handling of AWS Secret Keys.

I believe auto unseal and HA are both open source in the latest versions of Vault (docs say it is enterprise only).

ubuntu@ip-10-4-1-69:~$ vault --version
Vault v0.10.0 ('5dd7f25f5c4b541f2da62d70075b6f82771a650d')

Is it possible these issues would go away if I updated vault?

Cloning this repo uses the variable enable_auto_unseal = true in firehawk-main/main.tf. The deployment succeeds, but vault status produces this on sshing to a vault instance:

ubuntu@ip-10-4-1-69:~$ vault status
Error checking seal status: Get https://127.0.0.1:8200/v1/sys/seal-status: dial tcp 127.0.0.1:8200: connect: connection refused
ubuntu@ip-10-4-1-69:~$ vault operator init
Error initializing: Put https://127.0.0.1:8200/v1/sys/init: dial tcp 127.0.0.1:8200: connect: connection refused

I also tried to not use https:

ubuntu@ip-10-4-1-69:~$ export VAULT_ADDR='http://127.0.0.1:8200'
ubuntu@ip-10-4-1-69:~$ vault status
Error checking seal status: Get http://127.0.0.1:8200/v1/sys/seal-status: dial tcp 127.0.0.1:8200: connect: connection refused
ubuntu@ip-10-4-1-69:~$ vault operator init
Error initializing: Put http://127.0.0.1:8200/v1/sys/init: dial tcp 127.0.0.1:8200: connect: connection refused

Setting enable_auto_unseal = false in firehawk-main/main.tf, vault status works.
I have used this bool to select the template used in the unseal example if true and provided the necesary vars. We also create a kms key in terraform if true.

[queglay]

I fixed the connection issues by building AMI's with the provided packer template example, and updating consul and vault to the latest versions.