Cloud

Quick recap for those joining late. Spelunk started as a Go library to fetch secrets from any Source using a URI-like Coordinates system (intro). Then I added support for various cloud Secret Managers and a heap of Modifiers (v1.2.0 + v1.3.0). And after that I tore the repo apart into isolated modules/plugins, so you would only compile the third-party SDKs you actually needed (v2.0.0). And now, time to tick another box! Spelunk is a CLI now 💲 I ended the very first post with a little TODO list, and one of the points was: “Build a spelunk binary, so to embed it in shell scripts”. That’s what v2.2.* is about: ...

I just released Spelunk v2.0.0, a major architectural redesign of the library to dig up secrets from various sources, for Golang. If you have read previous posts about Spelunk, you know that the project started with a simple mission: to provide a single, clean, URI-based interface (scheme://location?modifier=arg) to fetch secrets across any storage backend—whether it is local files, environment variables, Kubernetes, HashiCorp Vault, AWS, Azure, or GCP. With v2.0.0, I have re-designed Spelunk to solve dependency bloat and make the core library exceptionally lean. ...

If you read my previous post introducing Spelunk, you already know: fetching secret from any source should be easy, especially for your users. Reading them from HashiCorp Vault, Kubernetes or whatever should be easy to. If they where JSON objects, extracting specific fields should be easy. Switching between a secret providers should (repeat with me!) easy! Well, since the initial announcement, my pickaxe has been swinging non-stop in the Spelunk caves, and I unearthed two updates: v1.2.0 and v1.3.0! 🎉 ...

If your Team, Organization or Company is serious about where to keep credentials used by services (or to interact with them), they are likely in Kubernetes Secrets, Hashicorp Vault, one of the various cloud-based Secrets Managers, 1Password, etc. Then, when running locally, they might be in your Environment Variables, in a .env, in a file or just in plaintext in a script (naughty!). This might lead to services and tools written to deal with those different “secret provision scenarios”. Or tricky/brittle local setups. ...