[Feature Request] Encryption support

[dougg0k]

Description

Add encryption support could end up making other ways viable to work with variables. While also making it more secure.

Motivation

No response

Proposed Solution

No response

Alternatives

• https://dev.to/silentwatcher_95/you-should-encrypt-your-environment-variables-n4h
• https://dotenvx.com/
• https://infisical.com/docs/sdks/languages/node

Additional Information

No response

[philmillman]

thanks @dougg0k, it's certainly on our roadmap, we have a similar option with dmno (https://dmno.dev/docs/plugins/encrypted-vault/)

[dougg0k]

cool, is there a roadmap page somewhere?

[philmillman]

cool, is there a roadmap page somewhere?

Not a public one currently, give us a bit of time and we'll get that up

[theoephraim]

@dougg0k - thanks for the suggestion. Definitely been on our minds for a while. I'd love to share what my current thinking is and see if you have any feedback/ideas.

There are many subtle differences in how it could be implemented. We could potentially have multiple strategies available as individual plugins - or they could just be options on a larger single plugin. In the end, whether or not this ends up being built into the varlock core, or is installed as a plugin would likely depend on if there are additional dependencies required.

Overall the larger questions are:

• single key or keypair
• are keys exchanged directly or via some kind of centralized saas
• are encrypted values stored within the repo or just pointers to remote storage

There are tradeoffs for all of these things... The basic version though is a single key, exchanged directly (and we may build some tools to help), and encrypted values stored within git. For the sake of discussion we can talk it through this simplified version.

This would likely be implemented as a combination of a root decorator for configuration, some CLI commands, and a new resolver function.

# root decorator configures the vault, mostly just pointing to the key
# @initEncryptedVault(key=$ENCRYPTED_VAULT_KEY)
# ---

# @type=encryptedVaultKey # could be a custom type, but doesnt necessarily have to be
# @sensitive
ENCRYPTED_VAULT_KEY=

# @sensitive
ENCRYPTED_ITEM1=encrypted(abc123xyzzzzzzz=) # < encrypted value

If you had multiple vaults / keys being used, you can imagine using names/ids to identify them.

# @initEncryptedVault(id=dev, key=$ENCRYPTED_VAULT_KEY_DEV)
# @initEncryptedVault(id=prod, key=$ENCRYPTED_VAULT_KEY_PROD)
# ---
ENCRYPTED_VAULT_KEY_PROD=
ENCRYPTED_VAULT_KEY_DEV=

# you could also have prod stuff in a `.env.prod` file
ENCRYPTED_ITEM1=if(forEnv(prod), encrypted(prod, qwe789xyzzzzzzz=), encrypted(dev, abc123xyzzzzzzz=)

You'd likely need CLI commands to help with migrating items into the encrypted vault, updating values, etc. Interestingly the reason this becomes a bit challenging is because varlock is so flexible. Unlike dotenvx/sops where you are encrypting decrypting a single file at a time, you may have a complex web of files, and multiple vaults, so just making it simple for the user to express what they want to do can be a bit tricky.

As for storing the key itself, especially locally, we can imagine feeding it in from .env.local, and ideally using our upcoming keyring plugin, that stores values on your os keychain.

We've also talked about making some of this encryption stuff a bit simpler for the "just for me" case, so you're not explicitly managing or thinking about a key at all, but this obviously has more limited utility. Going the saas route also opens up some possibilities to simplify, but would like to provide a free/simple option too.

[dougg0k]

In a quick read, it seems you are already following what you do for all other things in varlock, I suppose you got it figured out. I dont have much to add at this point.

A single file at a time, it is still a decent option to have though. As dotenvx does.

Most devs probably wont have the need for a lot of flexibility.

You could provide a single key, though I dont see much use in that. However if you are talking about having a way to choose which keys to encrypt, then it's something else.

I suppose remotely or in repo, can be useful to have as options.