[GH-ISSUE #862] Docker swarm secrets support #610

Closed
opened 2026-03-03 02:01:19 +03:00 by kerem · 13 comments
Owner

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!

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!
kerem closed this issue 2026-03-03 02:01:19 +03:00
Author
Owner

@mprasil commented on GitHub (Feb 14, 2020):

Hi, I think you can sort of make bitwarden_rs use the secrets using the .env file. 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 where bitwarden_rs reads it by default:

docker service create \
    ...
    --secret source=bitwardenrs_secret,target=/.env \
    ...

(note that this requires Docker 17.06 or higher, previous versions didn't support specifying absolute paths using target)

<!-- gh-comment-id:586319828 --> @mprasil commented on GitHub (Feb 14, 2020): Hi, I think you can sort of make `bitwarden_rs` use the secrets using the `.env` file. You'd have to format your secret by adapting the [template](https://github.com/dani-garcia/bitwarden_rs/blob/master/.env.template) so that it contains all variables that you want to expose this way. Then you'd just mount it in the root directory where `bitwarden_rs` [reads it by default](https://github.com/dani-garcia/bitwarden_rs/blob/8867626de898bb8416ed8319806b1c220d57dcb1/src/config.rs#L49): ```bash docker service create \ ... --secret source=bitwardenrs_secret,target=/.env \ ... ``` (note that this requires Docker 17.06 or higher, previous versions didn't support specifying absolute paths using `target`)
Author
Owner

@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:30

Overall 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=AAAAAAAAAAAAAAAAAAAAAAAA
and then needs to target /.env ?

Hope you can help me with this.

<!-- gh-comment-id:586736373 --> @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:30` Overall 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=AAAAAAAAAAAAAAAAAAAAAAAA` and then needs to target /.env ? Hope you can help me with this.
Author
Owner

@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 .env file - yes I meant to mount it in the root folder. bitwarden_rs is using dotenv crate to load file named .env in the current working directory, which is root directory for the official bitwarden_rs image. 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:

YUBICO_SECRET_KEY=AAAAAAAAAAAAAAAAAAAAAAAA
ADMIN_TOKEN=BBBBBBBBBBBBBBBBBBBBB

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:

docker secret create bitwardenrs_secret env_secret

env_secret in 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:

docker service create \
    ...
    --secret source=bitwardenrs_secret,target=/.env \
    ...

(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?

<!-- gh-comment-id:586743487 --> @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 `.env` file - yes I meant to mount it in the root folder. `bitwarden_rs` is using [dotenv crate](https://docs.rs/dotenv/) to load file named `.env` in the current working directory, which is root directory for the official `bitwarden_rs` image. 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: ``` YUBICO_SECRET_KEY=AAAAAAAAAAAAAAAAAAAAAAAA ADMIN_TOKEN=BBBBBBBBBBBBBBBBBBBBB ``` 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: ```bash docker secret create bitwardenrs_secret env_secret ``` `env_secret` in 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: ```bash docker service create \ ... --secret source=bitwardenrs_secret,target=/.env \ ... ``` (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?
Author
Owner

@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 env inside 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!

<!-- gh-comment-id:587183552 --> @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 `env` inside 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!
Author
Owner

@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.

<!-- gh-comment-id:587207989 --> @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.
Author
Owner

@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.

  1. I created a file called env_secret with ROCKET_PORT=1025 inside. (I also tried with single quotes and double quotes around the number, but no luck either way).

  2. 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).

  3. Run

sudo docker service create --name test \
--replicas=1 \
--publish 4321:1025 \
--constraint node.labels.arc==x64 \
--secret source=bitwardenrs_secret,target=/.env \
bitwardenrs/server 

(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:80

Hope I didn't overlook anything and you can still help me @mprasil

<!-- gh-comment-id:592785736 --> @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. 1. I created a file called `env_secret` with `ROCKET_PORT=1025` inside. (I also tried with single quotes and double quotes around the number, but no luck either way). 2. 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). 3. Run ``` sudo docker service create --name test \ --replicas=1 \ --publish 4321:1025 \ --constraint node.labels.arc==x64 \ --secret source=bitwardenrs_secret,target=/.env \ bitwardenrs/server ``` (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:80` Hope I didn't overlook anything and you can still help me @mprasil
Author
Owner

@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)

<!-- gh-comment-id:592921011 --> @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)
Author
Owner

@ociotec commented on GitHub (Feb 29, 2020):

@Zerwin the target for the secret should be /data/config.json

Additionally, this file is JSON, write something like this:

{
  "admin_token": "***********",
  "smtp_username": "user@email.com",
  "smtp_password": "**********"
}
<!-- gh-comment-id:592946621 --> @ociotec commented on GitHub (Feb 29, 2020): @Zerwin the target for the secret should be `/data/config.json` Additionally, this file is JSON, write something like this: ``` { "admin_token": "***********", "smtp_username": "user@email.com", "smtp_password": "**********" } ```
Author
Owner

@Zerwin commented on GitHub (Feb 29, 2020):

I finally got it to work. Making the secret a json and putting it at /data/config.json worked for admin_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_ID and YUBICO_SECRET_KEY it 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

<!-- gh-comment-id:592959014 --> @Zerwin commented on GitHub (Feb 29, 2020): I finally got it to work. Making the secret a json and putting it at `/data/config.json` worked for `admin_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_ID` and `YUBICO_SECRET_KEY` it 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
Author
Owner

@mprasil commented on GitHub (Feb 29, 2020):

This might work, but keep in mind, that /data/config.json needs to be in json format. 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 .env file didn't work, it would certainly be much better solution.

<!-- gh-comment-id:592963196 --> @mprasil commented on GitHub (Feb 29, 2020): This might work, but keep in mind, that `/data/config.json` needs to be in `json` format. 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 `.env` file didn't work, it would certainly be much better solution.
Author
Owner

@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.

<!-- gh-comment-id:610959704 --> @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.
Author
Owner

@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.

<!-- gh-comment-id:730491434 --> @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.
Author
Owner

@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.

<!-- gh-comment-id:730659361 --> @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.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vaultwarden#610
No description provided.