Vault: Feature : Ability to init in -dev mode in a way that is helpful for docker dev/testing

[grempe]

I was recently creating a docker image to do some development with Vault. It was a _far_ more painful experience than it needed to be. I would propose a few changes (to -dev mode) that would make things much easier.

As it currently stands you can't really use -dev mode in a docker container since it will only bind to 127.0.0.1 and this is not changeable. So you are forced to run in full non-dev mode. However, no other docker container will be able to speak to vault in this mode since the other instances won't know the random token that was created on startup, and the vault will still be sealed. This means I have to manually intervene when I start that docker container in order for other containers that depend on vault to work. The following changes would go a _long_ way to making this a better dev/test experience:

• Allow -dev mode instance to listen on both 127.0.0.1 and 0.0.0.0
• Allow manual specification of an additional root key when starting in -dev mode. This would allow test apps or other dev containers to know they can always talk to the container without having to parse the root token from the text output of the init command and somehow pass that from one container to another. I'm now setting -id="insecure-dev-only-token" as an additional root token which I can add to variables in my other dev/test docker containers that want to talk to this vault dev instance.
• Allow the output of the init command to be specified to be machine readable JSON, not text that may need to be extracted with awk as I had to with a my bash script (see below).
• Allow dev mode to be configured with any of the backends for secret storage that the non-dev mode can do. This would allow me to test, for example, storage in AWS S3 or consul. Not just inmem.

In case its helpful to anyone, here is my Dockerfile that I ended up creating for Vault dev and also the script that I have to run on the vault docker host in order to sort of accomplish this today. Note that I also had to set this up as a cron job on the docker container to run every minute since there is no easy way for me to run it only after vault was started by the init system since I have no hook into that event. I'd love feedback that I am missing something obvious to make all of this better but for now its a hack that should not be needed:

https://github.com/grempe/dockerfiles/tree/master/vault
https://github.com/grempe/dockerfiles/blob/master/vault/rootfs/usr/local/bin/vault-init.sh

These changes, since they only apply to -dev mode (an inherently insecure mode) should not weaken the security of Vault at all.

[jefferai]

Hi @grempe ,

I think that the reason it was far more painful to use -dev mode in your situation than you wanted is because -dev mode wasn't designed for your situation :-) It was designed for those of us doing development _on_ Vault more than for those doing development _with_ Vault. When the parameters of -dev mode don't suffice for my testing, I just spin up a normal instance.

It sounds like what you really want is to be able to use -dev mode with a config file and a specified root token ID. I must admit that I'm not really sure what that buys you. It'd be up to the caller to ensure that the backend storage is wiped between runs; for safety Vault should not do it. So that loses the benefit of using the inmem store, which is to always have fresh 'n clean storage. I don't think plumbing all of the potential options in the config file into command line flags is reasonable, so you'd still need the configuration file. The only thing you'd really get out of this is automatic unsealing and a second root token with a known ID -- and as you pointed out, this is something you can do with a script that executes on startup, which is a very normal paradigm with Docker images, and you could put the desired token ID into a Docker env var, which is also a very normal paradigm with Docker images.

Allow the output of the init command to be specified to be machine readable JSON, not text that may need to be extracted with awk as I had to with a my bash script (see below).

The Vault CLI is just a wrapper around Vault's JSON API, so it's already output in machine readable JSON if you use curl, httpie, or any other HTTP client. You can also use the -format=json flag if you want to use vault init to get the output in JSON (this is a global option that works for any command using the CLI).

[jefferai]

My colleague pointed out that format is only an option on vault read; regardless, the straight Vault API can be used with any HTTP client to get the results back in JSON.

[grempe]

Let me address some of your questions/statements and see if I can clarify why I think this would be useful.

It was designed for those of us doing development on Vault more than for those doing development with Vault. When the parameters of -dev mode don't suffice for my testing, I just spin up a normal instance.

Well, that is not clear from your getting started guides which starts everyone out in -dev mode. Regardless, dev mode provides one crucial difference that normal mode does not, namely auto-unseal which is great in the sense that I don't need to know the unseal key, but not so great in the sense that I do need to know the random root token that was generated for this -dev instance.

It sounds like what you really want is to be able to use -dev mode with a config file and a specified root token ID. I must admit that I'm not really sure what that buys you.

In my scenario my entire app does not run in a single docker container. I am using (following best practices) docker compose to spin up an entire environment of containers, all linked together using docker networking backplane. e.g. a vault instance, a redis instance, and a Ruby Sinatra instance. So when compose starts up all of these instances there is no way for the Sinatra instance to know what root token it should initialize vault-ruby client with. So in this scenario if I were able to deterministically start vault, but specify it should start with a specific non-random root token, then I could pre-configure that non-random root token in my other dev/test containers, or setup my local OS X host env to always use that token for talking to vault.

It'd be up to the caller to ensure that the backend storage is wiped between runs; for safety Vault should not do it. So that loses the benefit of using the inmem store, which is to always have fresh 'n clean storage.

I am using the inmem store in development. But even if I weren't its not a security risk since this is explicitly dev/test mode only and there should be no real secrets being stored.

The only thing you'd really get out of this is automatic unsealing and a second root token with a known ID -- and as you pointed out, this is something you can do with a script that executes on startup

Well, yes, and that is exactly what I was asking for :) And yes, as I demonstrated, it can technically be done with another script that runs after vault startup but it has a number of downsides:

• I cannot simply run that script when the instance is up, since there is no way for me to know that it is actually up. The init system cannot reliably give me notification (that I am aware of) when vault is running.
• Therefore the hack I came up with was to run this post-start script every minute via cron. Since every minute is the most granular I can get that means that I have to wait up to one minute after the docker container starts until I can access it. This is a total fail for a testing scenario within docker containers, or even in dev. I have to sit around for a minute to do anything.
• I can't restart my container, if I do all of the unseal is lost and the script will never run again since I dropped a file on first run that is the lock to tell the script not to run more than once.

Alternatively, if I could have my init script call something like this _single_ command with no follow ups needed:

vault server -dev -config=vault.hcl

And that vault.hcl would configure a specified (maybe additional, maybe only, doesn't really matter) root token it would work without any extra scripts, and it would work if I restarted vault from the init system, or if vault crashed and was restarted, or if I restarted the whole container. It may not be desirable to specify this token in the config, in which case a single extra command line flag to init would do it nicely.

Regarding the bind to 0.0.0.0. Testing this out right now I see that if I start in -dev with a config that specifies:

listener "tcp" {
 address = "0.0.0.0:8200"
 tls_disable = 1
}

Then I get this in the output:

      Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
        Listener 2: tcp (addr: "0.0.0.0:8200", tls: "disabled")

If that means that vault is in dev mode and listening on 0.0.0.0 as well as 127.0.0.1 that may remove the need for one of my original requests.

and you could put the desired token ID into a Docker env var, which is also a very normal paradigm with Docker images

I do not know of a way to make an environment variable in one container available in another container at runtime without writing it to another service as an intermediary (consul, redis, db, etc). If you do I'm all ears.

So, if the 0.0.0.0 is working as it appears it may be then my feature request really boils down to allowing me to specify what I want the root token to be when I start vault in dev mode. With this single feature I think I can have my dev/test environment always use the same root token across containers and not need to use a hacky and unreliable post-startup script (which everyone has to re-invent and which can only be done in a container that supports an init system and cron which I would say most containers don't).

Thanks for hearing me out.

Glenn

[grempe]

And the curl suggestion is a good one, but again I would not need the additional complexity if I can specify a root token on -dev startup.

[jefferai]

Well, that is not clear from your getting started guides which starts everyone out in -dev mode.

Well sure -- for a quick "play with some commands" scenario dev mode is more than enough :-)

In my scenario my entire app does not run in a single docker container. I am using (following best practices) docker compose to spin up an entire environment of containers, all linked together using docker networking backplane. e.g. a vault instance, a redis instance, and a Ruby Sinatra instance. So when compose starts up all of these instances there is no way for the Sinatra instance to know what root token it should initialize vault-ruby client with. So in this scenario if I were able to deterministically start vault, but specify it should start with a specific non-random root token, then I could pre-configure that non-random root token in my other dev/test containers, or setup my local OS X host env to always use that token for talking to vault.

You could also specify that in an env var and have your initialization script that runs when the container starts up populate that root token. This is very common practice -- see, for instance, postgres or mysql which provide customization in this way.

It'd be up to the caller to ensure that the backend storage is wiped between runs; for safety Vault should not do it. So that loses the benefit of using the inmem store, which is to always have fresh 'n clean storage.
I am using the inmem store in development. But even if I weren't its not a security risk since this is explicitly dev/test mode only and there should be no real secrets being stored.

The issue here isn't a security one, it's a "known state of the storage backend" one. Vault should never wipe the configured backend simply because someone passes in -dev, but if it doesn't, you no longer are guaranteed an empty, pristine Vault when starting up in dev mode. Only inmem guarantees this, and it's one of the cornerstone principles of dev mode.

I do not know of a way to make an environment variable in one container available in another container at runtime without writing it to another service as an intermediary (consul, redis, db, etc). If you do I'm all ears.

You write the same env var to all of the containers.

With this single feature I think I can have my dev/test environment always use the same root token across containers and not need to use a hacky and unreliable post-startup script (which everyone has to re-invent and which can only be done in a container that supports an init system and cron which I would say most containers don't).

Most containers have an init script, and you don't need a cron; merely starting Vault in the background, sleeping for a second or two, and then running a series of commands against it should be enough. There's no need to wait a full minute.

As you noted, you can also specify a configuration file or directory and the configurations will be merged, so if you really want to use dev mode but have persistent data, this is possible. But in this scenario, since the unseal keys and root tokens are stored in the persistent data store, starting in dev mode doesn't buy you anything, and you can already populate the root token in the other services.

So I'm a bit confused at what the issue is, here. You wanted to not use the inmem store with dev mode, but for reasons I explained, wiping a non inmem store when dev mode starts up is not something Vault will do. Since you're using persistent data, you can pre-configure it, or start with a known snapshot of the data, so you already know your root tokens and unseal keys. Given that, you can already populate it into your other containers. Plus, you can already start a listener on any interface you like. All of these things forego the point of dev mode, but they're also all things that you can already do in dev mode.

[grempe]

Well that was a bit of a surprise @jefferai

Thanks for implementing my request even though it seemed we were crossing paths a bit on understanding one another.

What is the best way for me to get a test build of vault with this code? Or do I need to build from source or wait for next release?

Let me try to quickly clarify what I was getting at before. I had a few nice-to-have's in my original request. Sorry I think they muddied the discussion a bit. My request (and what you implemented which looks like it will do the trick based on my quick perusal of the commit) really just boiled down to needing to set my own root token to go along with the auto-unseal behavior (and inmem memory wipe) of dev mode.

This provides one major positive difference. In a dev vault container you don't need to take action, parsing what is intended to be only human readable text, and issue at least five additional commands (extract unseal key, unseal, extract token, auth with token, issue new deterministic root token) on your instance in order for it to work and be accessible to _other_ containers without human intervention.

That's it! With this, there is no need for scripts to write and debug, cron, or sleep. Boom! It starts, its unsealed, I know the root token, and I can access it immediately with that pre-shared token from anywhere that can talk to that vault. Thank you! Can't wait to try it out!

Some Extra Info

I don't use an init script to start the vault instance as you might often see. This is actually a problem in the docker community. I use a lightweight init _system_ which allows for supervision, proper exits and shutdown on failure, and ability to have other needed systems also running and supervised on the container such as syslog and cron. This blog post will explain it better than I ever could. I use the s6 init system on Alpine Linux but the Phusion approach is the same.

https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/

You write the same env var to all of the containers.

Yes, I can achieve this effect now by writing a script as I did. Decide on a common token, write the script to set that token in the vault instance, hard code all other containers to know this token as well. I know its possible, but the scripted approach has a large number of downsides (hard to run it initially since init system does not notify when vault is actually running, init systems are not meant to run one off tasks each time a process is supervised and started/restarted as this multi-step unseal process is actually highly unusual (but needed for this tool), post-start script is hard to run reliably on vault process restart or container restart. Its all just a hack and messy. The new way is clean. One command. Boom.

So I'm a bit confused at what the issue is, here. You wanted to not use the inmem store with dev mode, but for reasons I explained, wiping a non inmem store when dev mode starts up is not something Vault will do

I'm with you on this. It would be a nice to have to be able to do all of what I said above but play with other backends as well in dev, but it is not a must have for my needs.

Anyway, thanks for listening, thanks for reading this far, and thanks for writing the code.

[grempe]

@jefferai

A problem.

I've just had a chance to test out the new commit. I spun up a golang official docker container, and I built and ran the tests on vault. I copied the resulting vault binary into a branch of my own vault Dockerfile and tested several config scenarios.

There seems to be an issue preventing me from starting in -dev mode and also passing in a -config in the docker container. Being able to make use of the config to specify the listen address is important for the docker scenario. If you'd like me to file a separate bug I can do that if you think its unrelated to this commit.

Vault Dev w/ no additional config file

/usr/local/bin/vault server -dev -root-token-id="insecure-dev-only-token"

starts normally, but is only listening on 127.0.0.1

==> WARNING: Dev mode is enabled!

In this mode, Vault is completely in-memory and unsealed.
Vault is configured to only have a single unseal key. The root
token has already been authenticated with the CLI, so you can
immediately begin using the Vault CLI.

The only step you need to take is to set the following
environment variables:

    export VAULT_ADDR='http://127.0.0.1:8200'

The unseal key and root token are reproduced below in case you
want to seal/unseal the Vault or play with authentication.

Unseal Key: ebf93635703ff4d6d4d247e5ec27e1fc2d93ca04670b66a99a976bd5b0e342e7
Root Token: insecure-dev-only-token

==> Vault server configuration:

         Log Level: info
             Mlock: supported: true, enabled: false
           Backend: inmem
        Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
           Version: Vault v0.5.2-dev (f88c6c16db3b3428c6cdc80519fe36a8409c4559)

==> Vault server started! Log data will stream in below:

2016/03/03 00:17:18 [INFO] core: security barrier initialized (shares: 1, threshold 1)
2016/03/03 00:17:18 [INFO] core: post-unseal setup starting
2016/03/03 00:17:18 [INFO] core: mounted backend of type generic at secret/
2016/03/03 00:17:18 [INFO] core: mounted backend of type cubbyhole at cubbyhole/
2016/03/03 00:17:18 [INFO] core: mounted backend of type system at sys/
2016/03/03 00:17:18 [INFO] core: post-unseal setup complete
2016/03/03 00:17:18 [INFO] core: root token generated
2016/03/03 00:17:18 [INFO] core: pre-seal teardown starting
2016/03/03 00:17:18 [INFO] rollback: starting rollback manager
2016/03/03 00:17:18 [INFO] rollback: stopping rollback manager
2016/03/03 00:17:18 [INFO] core: pre-seal teardown complete
2016/03/03 00:17:18 [INFO] core: vault is unsealed
2016/03/03 00:17:18 [INFO] core: post-unseal setup starting
2016/03/03 00:17:18 [INFO] core: mounted backend of type generic at secret/
2016/03/03 00:17:18 [INFO] core: mounted backend of type cubbyhole at cubbyhole/
2016/03/03 00:17:18 [INFO] core: mounted backend of type system at sys/
2016/03/03 00:17:18 [INFO] core: post-unseal setup complete
2016/03/03 00:17:18 [INFO] rollback: starting rollback manager

Vault Dev w/ config file that changes the listen address:

/usr/local/bin/vault server -log-level=debug -config=/etc/vault.hcl

vault.hcl is always:

backend "inmem" {}

listener "tcp" {
 address = "0.0.0.0:8200"
 tls_disable = 1
}

disable_mlock = true

And this results in what seems to also be a clean startup, in _normal_ mode not dev, and a binding on 0.0.0.0 which is good. Of course no unseal happens as expected.

==> Vault server configuration:

         Log Level: debug
             Mlock: supported: true, enabled: false
           Backend: inmem
        Listener 1: tcp (addr: "0.0.0.0:8200", tls: "disabled")
           Version: Vault v0.5.2-dev (f88c6c16db3b3428c6cdc80519fe36a8409c4559)

==> Vault server started! Log data will stream in below:

Vault Dev w/ -config file that changes the listen address _and_ -dev mode combined.

Combine these two concepts, -dev AND -config to cause a bind to 0.0.0.0 I get a fail:

/usr/local/bin/vault server -dev -log-level=debug -config=/etc/vault.hcl

Fails with:

==> WARNING: Dev mode is enabled!

In this mode, Vault is completely in-memory and unsealed.
Vault is configured to only have a single unseal key. The root
token has already been authenticated with the CLI, so you can
immediately begin using the Vault CLI.

The only step you need to take is to set the following
environment variables:

    export VAULT_ADDR='http://127.0.0.1:8200'

The unseal key and root token are reproduced below in case you
want to seal/unseal the Vault or play with authentication.

Unseal Key: f5898171986bf799901c011dbec622a43c21ef90ddf8e1ff09b1da5d2418b397
Root Token: 8cbdde7e-fc66-dbd0-deaf-88996e352bbb

Error initializing listener of type tcp: listen tcp 0.0.0.0:8200: bind: address already in use

If I try with -dev, -config, and the new -root-token-id it fails the same way on binding.

FYI, This behavior seems to be different than on OS X, which if given -dev and -config adds a second listener and binding.

So this is a problem for the docker scenario since vault needs to listen on a non-localhost only address so it can use docker networking.

Thoughts?

[jefferai]

Hi @grempe ,

I'm well aware of the PID 1 issue in Docker, but it seemed from your previous comments like you were not wanting to use an init system since you were saying that that would require pulling in cron and other dependencies (depending on which system you were using, of course) and that you had instead written a script to set things up.

Regarding the root token, my issue was never with specifying the root token, it was with using non-inmem backends in dev mode due to Vault's inability (really, unwillingness) to clean them out; and, if you are using persistent data across dev mode runs, you already know what your root token is.

As for the listener, the address "0.0.0.0" binds to all interfaces, including localhost. So when you already have 127.0.0.1 bound on port 8200, you can't bind 0.0.0.0, and vice versa. I really have no idea how you got the output you got above where it's showing that it's listening on both, because I tested it to try to reproduce that and in my testing it doesn't matter which order I try to bind to first -- either way it fails. I can add a command line switch to allow setting the address when running in dev mode.

[grempe]

A command line switch to specify the listen address and override the 127.0.0.1 binding should do the trick. Does -dev work combined with -config at all? Or only for some settings? It would be nice to be able to specify that using the 'normal' way in the config file or on the command line.

As I mentioned in my comments, below is the output with two listeners (127.0.0.1, 0.0.0.0) on OS X vault installed with homebrew.

$ vault -v
Vault v0.5.0

$ cat /Users/glenn/src/dockerfiles/vault/rootfs/etc/vault.hcl
#
# This is a sample dev server config.
#
# !!   IT IS INSECURE   !!
# !! DO NOT USE IN PROD !!
#

backend "inmem" {}

#backend "file" {
#  path = "/app"
#}

listener "tcp" {
 address = "0.0.0.0:8200"
 tls_disable = 1
}

disable_mlock = true

combining -dev with -config on OS X results in second listener

$ vault server -dev -config=/Users/glenn/src/dockerfiles/vault/rootfs/etc/vault.hcl
==> WARNING: Dev mode is enabled!

In this mode, Vault is completely in-memory and unsealed.
Vault is configured to only have a single unseal key. The root
token has already been authenticated with the CLI, so you can
immediately begin using the Vault CLI.

The only step you need to take is to set the following
environment variables:

    export VAULT_ADDR='http://127.0.0.1:8200'

The unseal key and root token are reproduced below in case you
want to seal/unseal the Vault or play with authentication.

Unseal Key: 107a3dbcb448c517abbdeeb0e628619f865570032b284142acb634b69f9dbb4c
Root Token: 6b61fc98-699e-1039-c1a3-cc93d6206e4d

==> Vault server configuration:

         Log Level: info
             Mlock: supported: false, enabled: false
           Backend: inmem
        Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
        Listener 2: tcp (addr: "0.0.0.0:8200", tls: "disabled")
           Version: Vault v0.5.0

==> Vault server started! Log data will stream in below:

2016/03/02 17:50:12 [INFO] core: security barrier initialized (shares: 1, threshold 1)
2016/03/02 17:50:12 [INFO] core: post-unseal setup starting
2016/03/02 17:50:12 [INFO] core: mounted backend of type generic at secret/
2016/03/02 17:50:12 [INFO] core: mounted backend of type cubbyhole at cubbyhole/
2016/03/02 17:50:12 [INFO] core: mounted backend of type system at sys/
2016/03/02 17:50:12 [INFO] rollback: starting rollback manager
2016/03/02 17:50:12 [INFO] core: post-unseal setup complete
2016/03/02 17:50:12 [INFO] core: root token generated
2016/03/02 17:50:12 [INFO] core: pre-seal teardown starting
2016/03/02 17:50:12 [INFO] rollback: stopping rollback manager
2016/03/02 17:50:12 [INFO] core: pre-seal teardown complete
2016/03/02 17:50:12 [INFO] core: vault is unsealed
2016/03/02 17:50:12 [INFO] core: post-unseal setup starting
2016/03/02 17:50:12 [INFO] core: mounted backend of type generic at secret/
2016/03/02 17:50:12 [INFO] core: mounted backend of type cubbyhole at cubbyhole/
2016/03/02 17:50:12 [INFO] core: mounted backend of type system at sys/
2016/03/02 17:50:12 [INFO] rollback: starting rollback manager
2016/03/02 17:50:12 [INFO] core: post-unseal setup complete

[grempe]

Looks great @jefferai I look forward to testing it out and using it in the next release. Thanks for being so responsive.

Did you figure out the second listener on OS X?

[jefferai]

I assume it's just a difference between Linux and OSX. Not really a big deal either way, at this point, since you can specify 0.0.0.0 for the dev address.

[grempe]

Testing the fix. Looking good so far running in a container. I tested with the both of the new command line flags, not the env vars. I was able to entirely remove my post vault start setup script with these new changes. The only thing I need to look at is loading dev related policies when the docker container is instantiated.

A nitpick. Should export VAULT_ADDR example in text output for -dev mode now reflect any user specified listen address? Could potentially be different than 127.0.0.1:8200 now. Can TLS be enabled in dev mode by using a config.hcl? If so, then scheme portion may vary also (http | https).

==> WARNING: Dev mode is enabled!

...

The only step you need to take is to set the following
environment variables:

    export VAULT_ADDR='http://127.0.0.1:8200'         <<<===  SHOULD CHANGE IF LISTEN ADDRESS:PORT WAS SET?

...
==> Vault server configuration:

         Log Level: info
             Mlock: supported: true, enabled: false
           Backend: inmem
        Listener 1: tcp (addr: "0.0.0.0:8200", tls: "disabled")
           Version: Vault v0.5.2-dev (f538393d24b50d5e833e740dd2cbbcbb29f376de)

==> Vault server started! Log data will stream in below:

[jefferai]

Should export VAULT_ADDR example in text output for -dev mode now reflect any user specified listen address?

Yes, it should -- I meant to update that and forgot. I'll do so.

Can TLS be enabled in dev mode by using a config.hcl? If so, then scheme portion may vary also (http | https).

No, it can't. So the scheme portion will stay the same.

[kelassar-zodis]

Thanks @grempe for the comprehensive description of the problem.
Seen a few entries but by far this is the only which attempts to answer the problem.
(https://github.com/hashicorp/vault/issues/441)

Experienced the same problem and resolved it by simply running Vault standalone (i.e. not inside a docker container). This might be related to docker-machine or docker on Windows/MacOSX implementations.

The binding error seems to be raging on: https://github.com/docker/docker/issues/8714.

[priyatam]

This issue is still open on vault 0.6.1, docker 1.12.3, OS X. Inspite of setting a config as described above and the VAULT_ADDR flag to http://127.0.0.1:8200 or http://0.0.0.1:8200, I get Error initializing listener of type tcp: listen tcp 0.0.0.0:8200: bind: address already in use.

The only solution (I used for four months) is to start a consul on docker, which forces me to unseal/seal several times a day.

Suggestions?

[yonidavidson]

Any update on loading secrets to vault dev mode on start, this would help emulate a dev mode which also checks the flow of reading secrets from vault container.

[Chrislevi]

@grempe @jefferai

Any news with this? It still raises with -dev
Error initializing listener of type tcp: listen tcp 0.0.0.0:8200: bind: address already in use

Vault v0.10.3 ('c69ae68faf2bf7fc1d78e3ec62655696a07454c7')

my .hcl

backend "consul" {
  address = "consul:8500"
  advertise_addr = "http://127.0.0.1:8200"
  path = "vault"
  scheme = "http"
}

listener "tcp" {
  address = "0.0.0.0:8200"
  tls_disable = 1
}

disable_mlock = true

[rislahadmin]

same

[Sonique]

Does we have ease way to initialize docker vault in dev mode?