mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-04-26 09:46:00 +03:00
[GH-ISSUE #862] Docker swarm secrets support #610
Labels
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vaultwarden#610
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ociotec on GitHub (Feb 14, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/862
Hi,
I've read the wiki and issue list but I did not find any reference to Docker swarm secrets support:
https://docs.docker.com/engine/swarm/secrets/
I did also take a look to the entrypoint scripts just in case, but nothing was found.
Is there support for this? Writing the ENV variables (or env files) with SMTP credentials or ADMIN TOKEN is dangerous... Any other recommended way to do this? Maybe a configuration file (to use at least docker swarm config files feature).
Thanks in advance!
@mprasil commented on GitHub (Feb 14, 2020):
Hi, I think you can sort of make
bitwarden_rsuse the secrets using the.envfile. You'd have to format your secret by adapting the template so that it contains all variables that you want to expose this way. Then you'd just mount it in the root directory wherebitwarden_rsreads it by default:(note that this requires Docker 17.06 or higher, previous versions didn't support specifying absolute paths using
target)@Zerwin commented on GitHub (Feb 16, 2020):
Hey, I am having the same problem as OP, wanted to use secrets for some env variables. I am using docker-compose for most of my stuff so I tried to use what you (@mprasil ) posted but I'm not sure what I would actually have to do.
Do you mean I have to mount .env in bitwarden_rs's root folder ? Because that gives me an error in bitwarden_rs container then:
thread 'main' panicked at 'Can't connect to DB: BadConnection("Unable to open the database file")', src/main.rs:160:30Overall I am a bit confused how this is supposed to work. From what I found the .env is only used to provide enviroment variables for use in the compose-file. Did you mean a env_file ?
And my secret has to be in the format of e.g.
YUBICO_SECRET_KEY=AAAAAAAAAAAAAAAAAAAAAAAAand then needs to target /.env ?
Hope you can help me with this.
@mprasil commented on GitHub (Feb 16, 2020):
@Zerwin full disclosure: I've never used Docker Swarm for anything, just going by the documentation. But you seem to be using swarm and probably know also how secrets are managed there, so I'm hoping I don't have to explain that part, because I honestly don't know.
As for the
.envfile - yes I meant to mount it in the root folder.bitwarden_rsis using dotenv crate to load file named.envin the current working directory, which is root directory for the officialbitwarden_rsimage. What that file does is it provides variables as if they were specified by environment variables.So the plan would be to create single secret that will contain all secrets in it. Something like:
Hope you get the idea. They will be all in one file and you then upload that file as single secret. Reading the documentation, you do that with:
env_secretin the above example is a file you created with all the secrets in it as per previous example.Then you can use the secret and mount it following my previous comment:
(I'm skipping the other params you normally use to create service with
..., if you use docker compose you'll need to adapt the above example to compose file.)Does that help?
@ociotec commented on GitHub (Feb 17, 2020):
Ummm, thank you for all the ideas. Finally I've created a docker swarm config with the 3 "secret" variables (admin token, email user & password), then deploy that as expected json config file.
Put secrets in environment variables is a very dangerous idea because environment variables could be exposes quite easily (sometimes even by accident), for instance just running
envinside the container or in logs...I think this is the best approach until proper secret feature is implemented. Please consider this as a way to make more secure this container, I think bitwarden application does worth it :)
Thank you and good job!
@Zerwin commented on GitHub (Feb 17, 2020):
Didn't have time to test it yet, but it definatly made thing clearer, thank you @mprasil .
As for a proper secret implementation, is there any thread or feature request (except this thread) yet for that ? I don't think I saw it in the Meta Feature Request thread. If not I can post there so it gets added to the list.
@Zerwin commented on GitHub (Feb 29, 2020):
Finally managed to squeeze in some time, sorry for the long wait. So I tried pretty much step by step what you posted but can't seem to get it to work. I will use a safe to share variable to explain it.
I created a file called
env_secretwithROCKET_PORT=1025inside. (I also tried with single quotes and double quotes around the number, but no luck either way).Run
sudo docker secret create bitwardenrs_secret env_secret. I can see the secret being created and it shows up in portainer (so it should be available in the entire swarm).Run
(You can ignore the constraint, it's just something I use in my swarm)
Result: Taken directly from the logs:
[2020-02-29 00:03:50][start][INFO] Rocket has launched from http://0.0.0.0:80Hope I didn't overlook anything and you can still help me @mprasil
@mprasil commented on GitHub (Feb 29, 2020):
What's the version of docker? Maybe it's not new enough to support target parameter? Also can you try something like
ADMIN_TOKEN- something that's not Rocket related as that might not work for different reasons? (Also exec into the container and see if the file is there as expected)@ociotec commented on GitHub (Feb 29, 2020):
@Zerwin the target for the secret should be
/data/config.jsonAdditionally, this file is JSON, write something like this:
@Zerwin commented on GitHub (Feb 29, 2020):
I finally got it to work. Making the secret a json and putting it at
/data/config.jsonworked foradmin_token(only had to be careful about the comma, if there is one at the end but no next line it won't recognize it).But when I tried the same for
YUBICO_CLIENT_IDandYUBICO_SECRET_KEYit just didn't want to. Took me a while I had to write them in lower case to get it to work.Thanks for all the help @ociotec and @mprasil
@mprasil commented on GitHub (Feb 29, 2020):
This might work, but keep in mind, that
/data/config.jsonneeds to be injsonformat. Also that file will be overwritten from admin interface if you make any changes there, which will seemingly work, but I assume docker will reset that file on restart, so there might be some nasty surprise down the road. So keep that in mind.I'm still confused why the
.envfile didn't work, it would certainly be much better solution.@dani-garcia commented on GitHub (Apr 8, 2020):
This is solved now, you should be able to use either the .env file in the root directory or the /data/config.json file, note that any changes in the admin page are going to overwrite the json file though.
I also don't think there's any need for a special secrets feature, as long as the env variables are set only for the container, they are never printed in the logs anywhere, and if someone has access to run commands inside the container there are bigger problems at hand.
@lamka02sk commented on GitHub (Nov 19, 2020):
I can confirm that setting ROCKET_PORT in .env file has no effect. Other settings are applied properly.
@BlackDex commented on GitHub (Nov 19, 2020):
@lamka02sk this is an old closed ticket.
But, setting the port works just fine via the .env file.
It could be that you have an error in your .env file which causes the parsing of the rest of the file to fail. (Something which in the master/testing version will produce an error and emits a warning).
Could you try to put that env to the top of your .env file and check again.