You can implement this same logic in your own shell function or customize it as you wish. Note, also, that we can choose to export our secret into several different environment variables, as needed.įor example, at Gruntwork we prefer to use GITHUB_OAUTH_TOKEN whenever our scripts or tools need access to GitHub’s API, but the GitHub command line tool, gh, expects GITHUB_TOKEN for the same purpose. Immediately after running the load_github shell function and entering the BitWarden password, the GitHub token stored in BitWarden as a secure note is exported into environment variables and available for use.
Here’s a quick demo to show you exactly what this looks like.ĭemo of the workflow when using BitWarden CLI as your secrets storeĪs you can see, initially the user’s shell has no GitHub token environment variables set.
This is the first in a series of posts where we’ll walk you through the why and how of: Introducing the super secure shell secret series In this blog post, I’ll show you how I leverage BitWarden CLI and shell functions to create a simple workflow that allows you to unlock your secrets into environment variables whenever needed, without requiring you to hardcode secrets into your dotfiles. How can one balance these two tensions between ease of use and security? I never want a secret I’ve been entrusted with to leak accidentally, yet I also need fast access to my secrets during development and debugging. How to securely store secrets in BitWarden CLI and load them into your ZSH shell when neededĪs a developer, I need to manage many pieces of sensitive information securely.
0 kommentar(er)
