I work with Ruby on Rails on a daily basis and use 1Password for password management. In our Rails app we use the dotenv gem and it's always bothered me that we go to all the trouble of being secure, using 1Password with two factor authentication, and yet we have credentials sitting in a text file. Often if any of the credentials are needed by other devs they end up in two places, shared from 1Password and in a .env.local file on their machine.
With 1Password developer tools there is a better way.
First open 1Password settings, select 'Developer' and turn on the CLI option.
Follow any instructions to finish setting up the CLI integration. To check that you've installed the CLI correctly you can run op -v in the terminal.
Create a vault in 1Password where you'll store any credentials you want to use for your environment. We'll give a service account access to this vault and only keep the secrets we need for our use case in this vault. I've called mine workdev.
Follow the instruction on 1Password to set up a service account and give it access to the new vault.
Web access for setting up a service account can be found at https://my.1password.com/developer-tools/directory
In your Rails app rename your .env.local file to .env.local.erb.
Add the following to the top of .env.local.erb with the token you created above.
<%= $(export OP_SERVICE_ACCOUNT_TOKEN="your-service-token") %>
Reference a password in 1Password
Use the reference in .env.local.erb
AWS_ACCESS_KEY_ID=$(op read "output_from_the_reference" -n)
Now when you run your app it will be referencing the 1Password values. If you have separate .env files for testing you'll want to rename the file and apply the same steps above and you can re-use the same service token.
1Password is a great way to store credentials and a major benefit of this approach is when upgrading to a new computer you can copy the .env file to a shared directory without worrying about exposing a secret and you also get a history of the values when you change them.
If you want to take this a step further you can explore using 1Password in GitHub Actions, I've used this without issue in a personal project.
Top comments (2)
If you use the CLI without a service account, it will actually prompt you to unlock the app using biometric auth, plus you wont need to have your service account token sitting around in plain text.
Also, you might like DMNO - full disclosure, I am the author. It's a full featured toolkit for dealing with config. It can pull secrets from 1password and other places using plugins, and it also gives you validation, coercion, and a whole lot more. It's a JS tool, but meant to be used in polyglot repos with any language.
Interesting! I will have to check dmno.dev/ out, thanks for sharing.
The reason I ended up using a service account was every time I ran my tests or ran multiple processes the fingerprint auth got annoying for me. Using the app's biometric unlock is also a great option though if constantly auth-ing isn't an issue for you.