How to maintain secrets files in the Repo

I realize that this is not an Elixir-specific thing, but I am currently working through this issue on my team, and I wanted to see what everyone else was doing.

We have a team working on several Elixir/Phoenix applications. We have been keeping the secrets (dev.secret.exs, et al.) files out of source code control, and hoping for the best (backchannel communication, mostly), but this has bitten us a few times.

How is everyone going about maintaining the integrity of these files? They don’t change often, but they do enough that we should consider streamlining our workflow.

My initial thought is PGP encryption, as long as each user can remember to encrypt the files they changed.

Does anyone else have any practical solutions?


1 Like

I think you are looking for something like this:

If you really want to store the file encrypted in the repo then you need to use git hooks to run the encryption for you:


Thanks! This is all the information i am looking for!

1 Like

When a reply solves your problem you can mark it has the solution :smiley:

1 Like

Right now we are doing the same, so we also have the desire to change that.

Plan is:

  • Put all secrets in
  • store just the bitwarden API-key as a secret in Github
  • in Github Actions get all the other keys from bitwarden using its API

Also there should be a script, that pulls all secrets that are needed for dev into the checked out repo.

Not sure yet, if this is a good idea, we’ll see.

My problem with this is that now you have to trust that Github will not leak your API key and you have to trust that bitwarden will never be compromised.

The major issue is that sometimes the compromises go one for months until they are revealed by some security researcher.

So, I am not saying for you to not do it, but be aware of the trade-offs.

A mitigation tactic is to store the secrets encrypted with any provider, thus if they are compromised will not affect you, because the key to decode them is elsewhere.

Another approach is that the secrets (when not encrypted) are not stored as one single record in the provider, for example if the secret is mysuperverystronglongishsecret you store mysuperverystr and onglongishsecret as separated keys with unrelated names, and then you join them when you need to use on your scripts. This approach mitigates the case were the secret provider gets compromised, but doesn’t mitigate the case were your code is the one leaked, or if your code is in a public repo.

No perfect solution exists, just try to find the one with less trade-offs and with the smallest chain of trust.

1 Like

Encrypting those secrets that are accessed only by code is a good point. So Bitwarden-API-Key and AES-key as Github secret, encrypted keys in Bitwarden. This should be as (in)secure as putting the secrets in Github directly. If Github leaks: bad. But Bitwarden does not bring extra risk.

Also the Bitwarden key in Github should only be allowed to access the secrets needed in CI/CD.

I do not see the benefit of splitting the keys. This will be obvious with just looking at the CI/CD-code which I assume is less save than a Github secret.

The split is only useful for when the remote secret provider is compromised in isolation, as I mentioned:

So, imagine that you store in bitwarden your AWS secrets, that allow you to create new instances, then if bitwarden is compromised in isolation the attacker can immediately use your AWS secrets so spin some crypto miners or whatever he wants and you will be the one paying the bill.

Sure, but it does not bring any additional benefits if the keys are encrypted anyway. As long as the AES-key is not on the same platform.

I mentioned that was another approach:

Sorry if I was not clear, but this other approach doesn’t assume encrypted secrets. I have updated my post to explicit tell that is for the case of when secrets are not encrypted.

1 Like