I’m excited to share RunSecret (aka: rsec), an open source CLI I built to make working with secrets during local development easier and more secure.
If your experience is anything like mine, your team probably has secrets they need to use during local development (ex: API Keys, JWT Signing Secrets, DB credentials, etc) and you may have solved that problem with a git-ignored .env file, like many of my past teams have. If this sounds familiar then you may have also experienced my pain of securely bootstrapping secrets for every new team member, accidental commits when the .env file gets renamed to .env_tmp (yes, that actually happened), tripping over rotating secrets on every local machine, and explaining to your security team that everybody who offboards has all those secrets in plaintext on the laptop they just took with them. If you’ve felt any of this pain, then you know why I built RunSecret!
The core idea behind RunSecret is based on secret references: URL-like addresses that point to a secret in your team’s vault of choice. These references can be generated by RunSecret and used to replace instances of that secret currently stored in .env files or ENV VARS. When you run any command with RunSecret those references will be loaded and replaced with the real deal - but only during runtime, and only for that command! This means two, pretty-cool things:
1. .env files are safe to commit and share across your team again. This means access to secrets is controlled by your vault, and onboarding, rotation and offboarding access to these secrets is all automated now. (Big plus, your security team is also happier!) 2. If you are already using env vars to pass secrets into your application, you can use RunSecret without changing a single line of code.
RunSecret is built to be vault agnostic, and current supports AWS Secrets Manager, Azure Key Vault, and HashiCorp Vault (with more on the way). I’ve also built in some bells and whistles, like automatic redaction of any referenced secret in your application's stdout/stderr to reduce the chance of leaks. It’s still early days, and there’s a lot more I want to build out for RunSecret, but the core functionality is there and I’d love to start getting feedback from others and their use cases.
If you are interested you can check it out on GitHub here: https://github.com/runsecret/rsec
I’d be remiss if I didn’t credit the original inspiration for RunSecret. If you’ve ever used 1Password’s very well done CLI, `op` , this all probably looks familiar to you. RunSecret was an itch I had to scratch after working on a team that used 1Password as its team vault, and then dealing with withdrawals when I switched to an org that used AWS Secrets Manager instead. For anyone who has or currently uses `op` , and misses that functionality with other secret vaults you work with, RunSecret might be interesting to you!
I hope you enjoy RunSecret, and would love any and all feedback you have to make this better. Thanks for checking out my project!