Add Support for Docker Secrets to Self-Host Project

Feature Requests Password Manager
, ,
1

Hello!

I’d like to request that support for Docker Secrets be added to the self-host project. I think that this is essential to secure sensitive settings, such as database user/password/name and SSL certs/keys.

While I am not an expert on Docker, it’s my understanding that settings can still be accessed should some malicious entity gain access to your running containers, but that secrets have an additional layer of security preventing the exposure of their values. This seems particularly important with a service like BitWarden that manages so much sensitive data.

An example of this is already located in the official postgres image’s docker-entrypoint.sh.

It uses the file_env() method to read in variables that may be stored in files (references that can be pointed to docker secrets).

While the postgres image uses _FILE at the end of settings to indicate that it should be read from a file, I would suggest that _SECRET might be better, indicating that it would be best to use a secret to pass in those settings with sensitive information.

I wouldn’t mind coding this myself, but I am only familiar with the basics of shell scripting and docker (still googling and learning), and I didn’t want to wait to suggest this. Additionally, I wanted to make sure that this would be a good idea that would be welcomed.

Thank you!

1 Like
2

Is there any news about this? I’d like to see this feature, too :star_struck:

Since the server is a .NET app, a good first step could also be to enable the .NET Key-per-file configuration provider. This way, one could dig into the underlying .NET config POCOs and inject them accordingly. I’m doing this in several of my own .NET apps and it works smoothly :ok_hand:t2:

3

I quickly checked the Bitwarden Server source code. Indeed, it seems that adding config.AddKeyPerFile("/run/secrets", optional: true, reloadOnChange: true); could do the job. With this change, using Docker Compose Secrets should work like this:

services:
  bitwarden:
    image: bitwarden/self-host:beta
    volumes:
      - ./data:/etc/bitwarden
    ports:
      - "8080:8080"
    environment:
      - BW_ENABLE_SSL=false
      - BW_DB_PROVIDER=sqlite
      - BW_DOMAIN=my.app.domain
    secrets:
      - GlobalSettings__Installation__Id
      - GlobalSettings__Installation__Key
secrets:
  GlobalSettings__Installation__Id:
    file: ./installation_id.txt
  GlobalSettings__Installation__Key:
    file: ./installation_key.txt

I’ve already added the same functionality to .NET Aspire (see here) and one of my private projects (see here).

I would be more than happy to provide a PR as this would be a feasible workaround for my needs :slightly_smiling_face: although the idea provided by @ben.dev is definitely the more user-friendly and common one.

However, since I’m new to Bitwarden Server’s codebase, I think it would be a good idea to discuss this with someone from the Bitwarden Server dev team. For example, I’m not sure whether the virtual nature of several properties here somehow breaks/conflicts with my approach.
@cksapp: maybe you could bring me and one of your devs together?

4

@gtran: maybe you can help? :slightly_smiling_face:

5

@mu88 @ben.dev You two are talking about the Bitwarden Secrets Manager, right?

6

I cannot clearly distinguish between Secrets and Password Manager, to be honest. But I’m talking about the Docker image bitwarden/self-host:beta - I think that’s the Secret Manager :thinking:

7

@Nail1684 We’re talking about this: Install and Deploy - Unified (Beta) | Bitwarden Help Center

@mu88 Heck, maybe it’s both? I think might even be the whole bitwarden offering. Also, I do like your idea there! That’s a cool way to do it! Not super familar with docker myself, but I do understand the basics. And I think that while my suggestion might be more common, I don’t know that it’s more user-friendly. I think you are on to something there!

1 Like
8

Thx @ben.dev :slightly_smiling_face: in the meanwhile, I filed a PR in the Bitwarden repo - let’s see whether it makes it into the product :crossed_fingers:t2:

9

@ben.dev Thanks for clarification. I asked, because this feature request was in the category “Secrets Manager”. But I think I changed that, after @mu88 's response a few days ago - and obviously I forgot to make a note to that change… So, I just wanted to make sure, the request is in the right category. :+1: