Does Convex have recommended processes for securing secrets / a secret key management feature?
I'm a hobbyist starting a Convex projects. I haven't seen anything in the documentation that explicitly addresses how secrets should be managed in a Convex backend, although I do see an example "MY_SECRET" environment variable in the docs (https://docs.convex.dev/production/environment-variables)
Are Environment Variables the recommended way to store sensitive secret values such as private keys?
Are there ways to limit the scope of a secret to only be usable by certain actions / functions / etc?
---
For some context, I'm thinking about the Convex Auth Password authentication. I like the elegance of using OpenID Connect configuration and publishing the public keys through a Convex HTTP handler. But if I am understanding this right, this requires a
JWT_PRIVATE_KEY environment variable containing the private key, which will be ambiently available to all Convex backend code, which is a much riskier scope than just a few authorization APIs...
Does Convex have on its roadmap some kind of Key-Management-System?
It would be nice to be able to guarantee that encryption/signing keys cannot be exfiltrated, so that you could have relatively high confidence in the integrity of your keys, and it would also help with the DX of having to securely generate and then upload the sensitive key material6 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
This sort of thing is planned with components, where you'll have some isolation. But could you say more about this, are there systems similar to this you're thinking of? The current model is just like a Node.js server, either all of your code is secure or none of it is; are you thinking of the risk of using npm libraries?
I can both see how this would be required and useful at a certain level, and am also surprised you want it.
You can encrypt the value and decrypt it just where you use it using a value stored in the function code, and only include that function code in files where you use it (the level of isolate here is modules though, not functions)
I think any big cloud provider has a key management service; AWS has Key Management Service, GCP has Key Management, Azure has Key Vault and Managed HSM and others
It's important for defense-in-depth, though my risk tolerance is probably a lot lower than typical because of my previous experience in fintech companies
For example, if you want to generate a key pair and use it to generate signatures in Convex, here's all of the things that could go wrong that would result in the private key being breached (some of these being more paranoid than others):
* the developer could (either maliciously or accidentally) fail to generate the key with secure parameters
* e.g., a buggy crypto library version, insufficient entropy, re-using entropy
* the developer could (either maliciously or accidentally) fail to delete the key, or expose the key (e.g., in terminal logs, in laptop backups, or cloud storage like Google Drive, or screensharing/presenting, or through a virus, ...)
* the key could be captured by a buggy or malicious browser extension
* the key could be accidentally or maliciously saved in a password manager etc by a browser
Once it's installed as an environment variable,
* the key could be accidentally or maliciously exposed by a change to application code
* the key could be accidentally or maliciously exposed by someone at Convex (e.g., accidental logging is not uncommon!)
* the key could be accidentally or maliciously exposed by a code dependency
* the key can be viewed at any time on the Convex Environment Variables panel
and all of these are completely undetectable; i.e., you can never actually be sure that at any point in the process the key hasn't be accidentally or maliciously divulged
If instead the key is generated within a Hardware Security Module, you don't have to trust anyone or anything except the manufacturer of the HSM / the due diligence of the provider hosting it (❤️ :convex:)
* developers cannot do anything to divulge the key, neither accidentally nor maliciously, because it never leaves the HSM
* Code dependencies cannot access the key because it never leaves the HSM
* Convex cannot even do anything to divulge the key even maliciously, because it can't be (non-destructively) extracted from the HSM
This still does require that you trust that the HSM is only going to perform sensitive operations (e.g., signature generation, decryption) for authorized clients, but in order to do those operations you need to get in contact with the HSM, so you can't exfiltrate the key and then go dark but still forge signatures, etc; so basically the trust is reduced to trusting the audit log of the encryption service
It looks like Firestore doesn't have a full key management system built in, but it does have "secrets" which are separate from environment variables:
https://firebase.google.com/docs/functions/config-env?gen=2nd#secret_parameters
and which are loaded from GCP Secret Manager
Great overview, yeah we're familiar with a lot of this from running production systems here and and previous companies.
The threat model of your deployment running malicious code is difficult, but that's what the isolation of components will help with. For the threats you're describing, makes sense. Re viewing keys in the environment variables pane on the dashboard, in the short term we could add more permissions here — we avoided hiding these because if you can deploy + run code, you have the ability to intercept calls or read the secrets already.
This kind of thing is on the horizon, we know we'll need it from using cloud providers ourselves but interop with existing providers like AWS or Dopppler could happen first.
Yeah I think it's a big feature
I've been thinking about this... Instead of expecting a full KMS solution from Convex (which is a big ask), it would be sufficient to have some kind of way to securely identify a Convex app as the client for an existing cloud KMS
Which could just be done by providing actions/mutations/etc a JWT that was signed by Convex explaining what the action is (claims including code deploy id, which query/mutation/actione/tc, which convex app, etc)