Offer a way to manage secrets in the source code, encrypted

[Martinsos]

Similar like Codeship did some time ago -> you could have secrets in your source code, committed to vcs (git), encrypted with a master key that is not committed but is kept local.
So instead of defining them all via env vars which are local, you would keep only the master key local, which makes it easier to distribute and track secrets.
Also, you could organize secrets per environments.

This is still just an idea, it needs to be evaluated in more details, especially from the security side.

Here is an exchange @breadchris and I had about this:

breadchris — 09/12/2022 05:06
it would be cool, in wasp, if you could define a map of secrets in your wasp file so that secret storage was dead simple

martinsos — 09/12/2022 12:04
Ok @breadchris this sounds super interesting, pls help me understand better!

So how would that work, would it be like declaring which secrets Wasp needs, so that it checks for those and errors if they are missing?

Or wait you said you would actually score secrets in git repo? That sounds like anti-practice right? I do understand that is encrypted, that file, so it isn't really a concern, but it does sound a tiny bit scary!

Although now that I think about it, I think we had the same setup with Codeship (now CloudBees) some long time ago, where it was also storing encrypted secrets in our git repo (or was it just on disk?).

Ok let's say you stored a bunch of encrypted secrets in the git repo. I guess those could be some API keys and similar.

How would that work with different environments (staging, production, development) -> you would have different files for different environments?

Who has the key for reading or updating the secrets, how is that distributed? That one is just distributed manually?
10 December 2022

breadchris — 10/12/2022 02:19
we should just hop on a call so I can mind dump on you guys lol
[02:20]
my neurons have been firing on this space for a while so I have a lot of information to share lol
[02:23]
So how would that work, would it be like declaring which secrets Wasp needs, so that it checks for those and errors if they are missing?

$ cat main.wasp
...
secrets {
  API_TOKEN: ./secrets/api-token.enc
}
...

$ cat ./secrets/api-token.enc
<gibberish>

$ cat .dev.secrets
MASTER_KEY=...

$ wasp start 
# runs app, reads master key from `.dev.secrets`, decrypts encrypted API keys
[02:26]
Or wait you said you would actually score secrets in git repo? That sounds like anti-practice right? I do understand that is encrypted, that file, so it isn't really a concern, but it does sound a tiny bit scary!
I agree, but the thing is, every development team every where starts out with secrets in code, and they dont know about Kubernetes secrets, or aws secrets manager until a security person, or team, tells them. This is a stop gap solution that "stops the bleeding" https://medium.com/@slimm609/securely-storing-secrets-in-git-542771d3ed8c It is something that lets dev teams dev fast, and not be slowed down by things they have to learn.
Medium
Securely storing secrets in Git
Secrets management and secure storage of secrets as code is always an interesting topic. There are various tools that exist for storing…
[02:30]
How would that work with different environments (staging, production, development) -> you would have different files for different environments?
for simplicity, I would just have one master key stored in a git ignored file, that is shared in both local dev and production. Again, not ideal, but the security for the code goes WAY up when you do this. Now an attacker has to compromise the production system and read env vars AND get access to the code. Simply having access to the code is not sufficient. If you have a SASS, you could have a "setup project" flow that downloads the master key to the git ignored file automatically. In code, you would provide an sdk that lets you retrieve the secrets:
// use master key env var to decrypt the encrypted API_TOKEN
const secret = wasp.getSecret('API_TOKEN');
[02:31]
I have not implemented this personally, but it sure gets my security stamp of approval for a dev team that is developing fast. In your docs you would have a warning of "consider using X, Y, Z to store secrets as they are one of the most common ways that attackers compromise systems"
15 December 2022

martinsos — 15/12/2022 14:32
Ok got it! Thanks for the detailed explanation. Let me try to summarize it so you can confirm if I got it right, and I might ask some extra questions.

1. Secrets (e.g. API keys/tokens) would be commited to git repo, but encrypted. They can be each separate file. I guess we could also just put them all in a single file, or even put them directly into main.wasp. Although it could be a bit boring to read that encrypted data there so maybe better a separate file.
2. Master key, they key used to decrypt and encrypt all of the secrets, would be present in a special file, and Wasp would use it to work with the secrets. This key would not be in git, it would be git ignored, and developer would have somebody share it with them when they are setting up their Wasp project.

In development, this means that you as a dev just obtain this master key once when setting up the project on your machine and you are good to go, from there on all updating of secrets is done via VCS (git) and you don't have to think about it really. Wasp CLI would provide some helpers for managing those, like adding a secret, updating it, deleting, ... .

In production, this could also be used. The only thing we need to provide is master key, which could be provided via whatever is the mechanism of that cloud provider (ASW secrets manager, ...), and the rest would be obtained from the code.
However, there might be secrets that we don't share between dev and prod -> for example maybe in prod we use different API TOKEN for Stripe, because in dev we use one for testing, while in prod we use the real one. While some secrets maybe we want to have same both in prod and dev. So that means we need to specify for which env is which secret, right? I guess we would want to have some secrets that are used in all envs, some that are used only in dev, some only in prod, ... .

It does sound compelling all together, although it would require us to build all the utils for this in Wasp CLI. But certainly doable!

1
[14:38]
One thing that also plays into this are ENV vars. Right now we specify those via .env files. And I think when looking at usage, they are somewhat connected to secrets, in the sense that some of them you want to share between devs, some of them should be local, and some of them you want to share even between different environments. Although maybe then they shouldn't be env vars hm. They are always tricky a bit but I wonder if those should also be included somehow in this. Just to be clear, I am talking about non-secret env vars here. Or maybe better way would be to say non-secret configuration.

breadchris — 15/12/2022 19:54
2. Master key, they key used to decrypt and encrypt all of the secrets, would be present in a special file, and Wasp would use it to work with the secrets. This key would not be in git, it would be git ignored, and developer would have somebody share it with them when they are setting up their Wasp project.
my dream is that this is generated in lastpass, 1password, or another password manager so you encourage people to generate on master key once and no one has to think about it again (or actually copy the value around, that is how breaches happen)
[19:56]
ideally the master key never ends up in a file, it is just too easy to accidentally commit it. that is where my security smell meter on this idea starts to go off a little bit. Keeping it as a value you read ephemerally (like from a password manager) is much safer.
[19:58]
yeah what you said back to me sounds right. I have never rolled this out personally for a project, but from what I have heard/read it is definitely feasible, but needs some iteration.
20 December 2022

martinsos — Today at 16:26
Cool sounds good! Although if we are not keeping it in a file, that would be an issue hm. I do understand why it is a bit scary though. But it needs to be available on machine so wasp can keep encrypting/decrypting them as it uses them. But it could be for example defined in .bashrc of a user, as ENV var, and then that way wasp would see it but it would not be easy to commit it.

[Martinsos]

@cursorial also inquired in this direction:

What about a feature that allows you to easily set up integration with popular APIs? (Thinking something like GPT-3 API) allow the user to configure and manage env vars like API keys from wasp?

[Martinsos]

https://infisical.com/ -> they are offering an open source solution for this, so potentially interesting.