4 ms·
You can commit your secrets as an encrypted vault with this. Then decrypt it with a key where needed: locally, on CI, on prod, etc. This is basically a simplif
by daralthus 2y ago
You can commit your secrets as an encrypted vault with this. Then decrypt it with a key where needed: locally, on CI, on prod, etc.
This is basically a simplified version of Hashicorp's Vault, GCP key vault etc. with some less granularity on user authentication.
It solves the issues around .env.example and is perfect for gitops. You have all your secrets for all your envs ready, while you only need to set a single env var (the private encrpytion key) on your specific hosting environment.
You could even use separate keys per env, eg.: to give access to a developer to staging only.
Mozilla's https://github.com/getsops/sops https://github.com/getsops/sops is another contender but with a more complicated (and perhaps more flexible) key management.
- candiddevmike 2y agohttps://rotx.dev https://rotx.dev can also be used for a local password safe, and it supports environment variables injection into various scripts or workflows. (author of rot)
- daralthus 2y agoLooks great, however it is much easier to work with just files, rather than key rings stored somewhere third party.
- candiddevmike 2y agoThe keyrings are in jsonnet files stored locally, not sure what you mean.
- globular-toast 2y agoSo you have to make a commit when a key is compromised or simply rotated? What the hell.
- progx 2y agoIf something is compromissed you have a problem, whether with encrpyted key or something else. If your env-data is compromissed you have to set new in all services and restart your app / container. But the enc-env file could be shared in you team or published to server without any problem. In the past this was a problem, when publishing accidently with plain text passwords.