Vault: -dev with consul backend fail to start up: Vault is already initialized

Created on 12 Jan 2017  Â·  10Comments  Â·  Source: hashicorp/vault

Hi,

Running vault in dev mode (with a configuration file) like this

VAULT_DEV_ROOT_TOKEN_ID=1c997ece-64af-5dff-da60-12067898e701,VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200 usr/local/bin/vault server -dev -config /etc/vault/config.hcl

and a config.hcl of

backend "consul" {
  address = "127.0.0.1:8500"
  path = "vault/"
  token = "<valid token>
}

fails the 2nd time its started with

==> Vault server configuration:

                 Backend: consul (HA available)
                     Cgo: disabled
         Cluster Address: https://10.0.2.15:8201
              Listener 1: tcp (addr: "0.0.0.0:8200", cluster address: "", tls: "disabled")
               Log Level: info
                   Mlock: supported: true, enabled: false
        Redirect Address: http://10.0.2.15:8200
                 Version: Vault v0.6.4
             Version Sha: f4adc7fa960ed8e828f94bc6785bcdbae8d1b263

Error initializing dev mode: Vault is already initialized

In dev mode it would be nice if one of these things worked:

a) vault deletes the Consul path if it exist in dev mode and continue startup
b) vault accept that Consul path exist and use whatever is there

Thank you!

Most helpful comment

I have a similar problem.
We are using a dockerized development environment that includes a vault container and a consul container.
In our case, we can't loose data between sessions, that's why we are using consul and not inmem backend, and also, having to manually unseal and set a new token every day, is not a solution.

It would be good if the -dev mode was able to detect an already initialized backend, and in that case, just unseal it instead of failing. If not by default, at least based on configuration or command line options.

Would that be possible?

All 10 comments

Dev mode uses inmem; if you are overriding that with configuration, it's up to you to manage state. Vault will not delete the path, because it's too easy for someone to give a config file to real data and accidentally hit -dev and blow it away.

@jefferai so its not possible to use -dev with any kind of backends? or how should one go about doing this correctly ?

It is. As I said, if you choose to use this with a backend that persists state, it is up to you to clear it when appropriate.

I have a similar problem.
We are using a dockerized development environment that includes a vault container and a consul container.
In our case, we can't loose data between sessions, that's why we are using consul and not inmem backend, and also, having to manually unseal and set a new token every day, is not a solution.

It would be good if the -dev mode was able to detect an already initialized backend, and in that case, just unseal it instead of failing. If not by default, at least based on configuration or command line options.

Would that be possible?

How would the dev mode logic know the key to unseal it?

That's a good point.

What if it was possible to pass it using something like -dev-unseal-key? Something similar to -dev-root-token-id, which is only used in dev mode.

The logic would be.

  • Try to initialize backend.
  • If it works, print unseal key for later use, and unseal the backend with it.
  • If it fails, check for the -dev-unseal-key option and try to unseal the backend with the value.
  • If the -dev-unseal-key was not provided, then print the "Error initializing dev mode: Vault is already initialized" message and die.

Since only one key will be provided, it will never affect any production environment, which requires at least 3.

Maybe the process should also check cases where the -dev-unseal-key option is provided with an incorrect value, but this is just a prove of concept.

@acelaya Can you clarify the use-case for me? Why not just use a startup script that basically does that for you?

What you're describing is basically just using dev mode as a shortcut for a fairly simple startup script that checks Vault's status code to see if it's initialized or not and either runs vault init or unseals with the known key. While technically what you propose could be done, it starts to get pretty far towards blurring the line between dev and not-dev.

Yes, I have to admit you are right.
That's what I've end up doing, a script that automatically ups all
containers and unseals vault.

I don't think it makes sense to implement what I initially requested.

Thanks for your time anyway :)

--
Alejandro Celaya Alastrué

El 14 abr. 2017 5:13 p. m., "Jeff Mitchell" notifications@github.com
escribió:

@acelaya https://github.com/acelaya Can you clarify the use-case for
me? Why not just use a startup script that basically does that for you?

What you're describing is basically just using dev mode as a shortcut for
a fairly simple startup script that checks Vault's status code to see if
it's initialized or not and either runs vault init or unseals with the
known key. While technically what you propose could be done, it starts to
get pretty far towards blurring the line between dev and not-dev.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/vault/issues/2265#issuecomment-294171363,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACl-ZDSu0XR3R2wO3y-926XcjpK11gMQks5rv40ggaJpZM4Lhulp
.

@acelaya Could you share your docker-compose script / and related ?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lexsys27 picture lexsys27  Â·  3Comments

Wonder007 picture Wonder007  Â·  3Comments

frntn picture frntn  Â·  3Comments

anthonyGuo picture anthonyGuo  Â·  3Comments

jasonmcintosh picture jasonmcintosh  Â·  3Comments