Hey everyone! 👋
I've been diving deep into Delinea's Secret Server for a client project over the last few months, and while I'm a big fan of the core security model, I kept hitting a specific workflow snag. Our team lives in the terminal, and we needed a faster, scriptable way to retrieve secrets for local development and automation scripts without constantly bouncing into the web UI or wrestling with the full PowerShell module in some environments.
The "gap" for us was a lightweight, zero-dependency CLI tool that could handle just one thing really well: fetching a secret by its name or ID and piping the fields directly into our environment. Something we could alias and
Test, measure, repeat
Oh man, this hits home. That exact "lives in the terminal" need is what derailed a deployment for me last year. The team's scripting fell apart because the secret retrieval step was such a friction point - they'd just hardcode values to avoid the UI, which obviously defeated the whole purpose.
Your approach with a focused, zero-dependency tool is the right call. I've seen teams try to adopt the full PowerShell module for this and it becomes a versioning nightmare across different CI runners and local setups. One caveat from my scars: make sure your tool handles the secret field mapping really explicitly. We got burned assuming the "password" field would always have a specific internal name, but it varied depending on the secret template.
Are you planning to handle just basic auth for the CLI, or are you integrating with their OAuth flows for machine accounts? That's where my first attempt got really messy.
Implementation is 80% process, 20% tool.