Couple questions

[Aetherinox]

This is a good app. Makes life easier.

Have question

First, normally when defining an env var in a file, you typically do

NAME_OF_VAR=VALUE

In your example, you mention storing the secret in BWS, and then using your bws-env to grab the env var. The question is, what is assigning the name of the env variable?

NAME_OF_VAR=VALUE
| -- ^^ --|

Do you have to store the secret in BWS as the name of the variable you need? Such as

And then your script uses that name as the name for the variable?

Sort of confused about how it knows what name to use, or if I'm missing something.

Say I add a new secret to bitwarden

Typically, you would define this in an env file as

ANOTHER_VAR=HELLO

But with your system, am I understanding that if you do the following in your docker-compose.yml

  get-bitwarden-secrets:
    image: alpine
    command: echo $ANOTHER_VAR

That the final variable name comes out as:

ANOTHER_VAR=HELLO

Because it's taking $ANOTHER_VAR and turning that into the env var name, and then assigning whatever the value was.

[tangowithfoxtrot]

Hey 👋 I'm glad you find this bws wrapper script helpful.

First, I want to mention that some similar, better fleshed-out functionality is being added to the bws CLI: https://github.com/bitwarden/sdk/commit/7a18777de48cae1454aae46fe434a9083868804a in the form of a bws run command. Once that releases, I'll probably archive this repo since the bws run command has some additional options and is generally more reliable than this wrapper script that I wrote.

---

Essentially, it works like this:

1. Have a secret saved in Bitwarden Secrets Manager with a POSIX-compliant environment variable name.
2. Execute the command that expects NAME_OF_VAR or ANOTHER_VAR environment variables like so: ./bws-env.sh 'docker compose up'
3. The alpine container should echo HELLO.

Do you have to store the secret in BWS as the name of the variable you need?

Yes. Ideally, use snake_case or SCREAMING_SNAKE_CASE for the secret names (as in your examples) so that they can be set as POSIX-compliant environment variables by the script. If you use key names that have spaces, or other special chars that shell languages would struggle with, the script will likely fail.

In the example you provided:

  get-bitwarden-secrets:
    image: alpine
    command: echo $ANOTHER_VAR

the container should output HELLO (not ANOTHER_VAR=HELLO). This particular example just uses Docker's interpolation syntax to take the environment variable (ANOTHER_VAR) that gets set in the subshell that bws-env.sh creates and inserts that into the container at runtime. You can run any other command that expects environment variables (something like `bws-env.sh 'npm run start').

For further insight into how bws-env.sh works, you can do something like ./bws-env.sh 'printenv' to dump your environment variables to see how the secrets get set. The printenv command will dump your secrets to stdout, so run it with caution.

[Aetherinox]

Awesome, super helpful. Appreciate it. Hopefully the bws run functionality works similar to this script. I've been running up and down the internet looking into an ungodly number of solutions for this. Everything from Hashicorp Vault, to having secrets hashed using a combination of Clevis and a tang server, and it was getting draining. Clevis worked alright, but it was restricted to Linux only. I could not update the secret unless I powered on my Linux machine.

At least with Bitwarden Secrets, I can change it from any OS.

Granted, this doesn't solve the issue about secrets being posted in the env vars and being visible via inspect, but it at least keeps them from just sitting inside a file. But this was the first solution to work without an ungodly complicated process like the others.