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