how to set process.env.SOME_SECRET_KEY to be used in worker? (environment variables)

[joonhocho]

Is there any way to set some environment variables for use in workers? I've read documentations and cannot find any examples. It seems some examples are hard coding keys, but everyone knows that's not safe. I can store to KV, but getting the key is asynchronous. Any solutions?

[xtuc]

If you are using a project of type webpack, you can use a plugin that will inline you values from your env, see https://webpack.js.org/plugins/environment-plugin/.

I can create an example of that next week.

[xtuc]

Here's an example https://github.com/xtuc/wrangler-env-demo and https://that-test.site/webpack-demo.

[EverlastingBugstopper]

@xtuc Is this pattern something we want to encourage? If so we should document it. I don’t think that’s what we want, though. If you bundle this secret into your worker it will not be encrypted at rest. KV is encrypted at rest and can safely be used to store secrets. While key retrieval is asynchronous, if you are worried about compromising your secret key, you should use KV.

[joonhocho]

It would be cool if wrangler can create or delete KV key value pairs

[xtuc]

If it sensitive data @EverlastingBugstopper is right, that said inlining env variables will still be useful for other data.

[EverlastingBugstopper]

@joonhocho we are actively working on KV support in wrangler —> #92

[AustinGil]

I have an app that uses env variables to connect to one of our services. The variables are not checked into version control, and they contain access credentials, so I'm wondering what is the best way to use them? Normally, I've used dotenv to set up the variables at build or run time, but the comments above suggest this may not be secure? KV looks secure, but it's async. Is that an issue?

[EverlastingBugstopper]

Hi @Stegosource! I would recommend putting your access credentials in KV as the values stored there are encrypted at rest. The workers runtime does not have access to environment variables, so any build process using environment variables would end with your credentials being stored in plaintext within your script.

I'm not quite sure what issues you would run into w/KV being async. If you are not reading your values from KV very frequently, you may notice that it is a bit slow as it is optimized for high volume reads.

Please let me know if anything is unclear or if you run into issues with whatever approach you decide is appropriate for your use case!

[AustinGil]

Hey @EverlastingBugstopper, that helps a lot. It's not so much that I have an issue with KV being async, I'm just trying to understand the different approaches and their pros/cons. It sounds like KV is the more secure approach, however, I guess I'm not sure why the plain text in the workers runtime is an issue. This may be a silly question, but do other people have the ability to view the scripts?

[EverlastingBugstopper]

Generally speaking, no, other people don't have the ability to view your scripts. That being said, regardless of whether or not other people have access, you do want sensitive data to be encrypted at rest. That's not our rule, it's just good data hygiene! This is the same reasoning that calls for the use of a password manager for your passwords over something like a text document or an Excel spreadsheet.

[AustinGil]

Yeah, that makes sense and was more or less along the lines that I was thinking. I'll move forward with KV then.

For education purposes, could you explain the scenario where my scripts could become compromised? I know with a central server, it's a matter of someone gaining access to my server. Is it the same with CF Workers? I guess someone would need to gain access to one of CF's datacenters?

[gr2m]

The problem I have with using the Key/Value store is that now I have to keep my script in sync with an external data source. There is a static relation between the code and the specific secrets it needs.

The KV store might be more approachable if you offered a UI similar to GitHub's repository secrets. These secrets could be stored in KV, but that would only be an internal implementation detail, you would make the keys accessible at runtime. If encryption is what you worry about, that would be the better approach from a developer experience perspective, I think

[gr2m]

I've setup another example to continuously deploy a Cloudflare Worker from a GitHub repository using the new GitHub Actions. It replaces process.env.* strings in the code with secrets defined in the repository:

https://github.com/gr2m/cloudflare-worker-github-oauth-login

[AustinGil]

@gr2m As I understand it, the reason for using KV over something like process env is not to do with storing the sensitive info in a git repo, it's to obfuscate that data at runtime. KV values are encrypted and therefore even after the project is built, they cannot be seen. If I understand correctly, your example would replace the env variables at buildtime, but they would be plainly visible at runtime.

[gr2m]

That’s correct, but it works for me :) people can’t see the source code of the worker and it’s not very sensitive information anyway.

I wish workers had a way to define secrets but that’s what we have today. I’m still not convinced about using KV for environment variables, it feels like KV is for data, and end variables are not

[AustinGil]

Yea, if it's not super sensitive data then that makes sense. But why put it in env vars at all then? Why not just a config file?

I felt the same way about KV at first but ultimately it went with it. There's nothing really wrong with using it that way.

[gr2m]

It looks like KV is a paid feature and for tiny little side projects that need to store two values, I'm not willing to pay $60 / year

[xtuc]

Uh, I forgot that KV wasn't free. KV can offer an end-to-end encryption binding, but I'm unsure how publicly sharable it is.

@gr2m would you like to jump on a call with us? Storing encrypted secrets in GitHub repositories is something peoples already do using some service to decrypt them when needed. Maybe we could figure out something specifically for GitHub (actions)?

[ashleymichal]

secrets and environment variables are here! closing this.