I’m trying to embody the experience of a JackBox game into a Scrum ceremony that should be lightweight but is often painful and tedious. I’ve also gotten to learn a lot about Cloudflare Durable Objects building this and have been delighted with how easy they (and PartyKit) make building multiplayer apps like this.

It’s completely free (I plan to keep it that way) and full of easter eggs and delightful jokes at the expense of Jira and modern software development, of course. If your team is following Scrum and could use a bit more joy in the process you should check it out!

Comments URL: https://news.ycombinator.com/item?id=44288705

Points: 1

# Comments: 0

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!

Comments URL: https://news.ycombinator.com/item?id=44041053

Points: 2

# Comments: 0

I agree RunSecret adds a level of indirection at this stage that op doesn’t (if you are using 1pass). This is something I plan to polish up once more vaults are supported. You’ve given me some ideas on how to do that here.

And thanks for the advice on doing a Show HN, planning to do so once a few more rough edges are smoothed out.

Azure KeyVault support is in progress and should land soon. I will notate it in the release changelog once it’s ready, but I’m also happy to reply here or let you know another way if you are interested!

Gitlab Secrets looks cool, but that hits at another reason I think RunSecret is valuable even for CI - we don’t use GitLab at my day job so it’s not an option for me! I think GitLab and 1password have interesting proprietary solutions that definitely have inspired RunSecret, but I’d love to see an open source, universal solution here - which I’m hoping RunSecret can be!

An easier and more secure way to work with secrets during local development. It’s open source, cloud/vault agnostic, and doesn’t require a single line of code change to use. I call it RunSecret.

RunSecret is a CLI that replaces your static secrets with “secret references” in your ENV VARs (or .env files). These references are then replaced when your application starts up by reaching out to your secret vault of choice - making your .env safe to share across your whole team and removing a slew of gotchas when you use git ignored env files. Even better RunSecret redacts any instance of these secrets from your application output, reducing your chances for accidental leaks.

The approach is inspired by the 1password CLI, but built for the rest of us. I’ve got AWS Secrets Manager support pretty well baked, but the goal is to support all major secret vaults within the next couple of months (Azure KeyVault is already in progress).

Comments URL: https://news.ycombinator.com/item?id=39678857

Points: 41

# Comments: 2