[devenjarvis]

Thanks for checking it out! The pain point for me has largely been during local development, especially in a team setting when secrets change or people onboard or roll off and those manually managed .env files get unwieldy.

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!

[firesteelrain]

The disadvantage to GitLab is to get the feature mentioned is you need to pay for the premium version. We host it ourselves and looking to buy the Enterprise version to get us the vault integrations (specifically AKV)

[devenjarvis]

Ahh, yup! The RunSecret CLI is completely free and open source.

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!

[firesteelrain]

Will monitor your progress

Also be interesting to see what trufflehog finds (should be false positive)

https://github.com/trufflesecurity/trufflehog

Where are you storing the creds to get the secret from the vault?

This is the secret zero problem and other platforms solve it in other ways such as HSM

[devenjarvis]

Yea that is a hard problem to solve. Right now RunSecret depends on the host system (your laptop, CI runner, or application container) having access to the secret vault(s) of choice that you reference. This can be through ENV VARS, OIDC, or IAM roles (in some cases) but currently there is no HSM support.

[firesteelrain]

No worries, interesting way to solve this problem!