Use 1Password to Manage Secrets and Environments

Several years ago, we wrote about “Managing Secrets and Environments with 1Password,” but a lot has changed since then.

The newer versions of 1Password have brought some very developer-friendly improvements including:

more ways to authenticate and log into the command line tool,
new and improved ways to add secrets to your environments; and
more options to quickly move between environments.

We’ll be using version 2.1.0 of the op command for this post.

Let’s dive in and see what’s new!

Legible outputs

The first improvement you’ll notice is that the command’s output is human-readable by default. (The original version defaulted to JSON output.) Some examples are shown below.

If you want or need JSON for any reason, you can pass --format json when running the command or export OP_FORMAT=json to make this the default. As a bonus, the JSON output is automatically highlighted, so you no longer need to pipe it through bat or something similar.

More ways to authenticate

The basic login process remains the same:

$ eval $(op signin --account sixfeetup.1password.com)

However, there is one major improvement. If you’ve allowed 1Password to be unlocked with TouchID or Apple Watch, you can use these methods to authenticate the command line tool as well.

Syntax changes

The syntax for some basic operations has changed. For example, this is how you list items in a vault named “Developers:"

$ op item list --vault Developers

To show the details for a specific item in the list, you can pass either the name of the item or its ID.

$ op item get 'AWS (Nice Client)'
ID:          hdlzmqagfnf5bk5yxdgmyvamvq
Title:       AWS (Nice Client)
Vault:       Private (f5izso4ucrdlhnkhpydyvy5ts4)
Created:     3 minutes ago
Updated:     3 minutes ago by Rob McBroom
Favorite:    false
Tags:        Six Feet Up
Version:     1
Category:    LOGIN
Fields:
  username:      rob
  password:      not my pet’s name
  :              en_US
  Account ID:    niceclient
  API Access:
    Access Key ID:        AKIAIOSFODNN7EXAMPLE
    Secret Access Key:    wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
URLs:
  website:                 https://niceclient.signin.aws.amazon.com/ (primary)
Additional Information:    rob

This was possible in later 1.x versions of the tool, but just to call attention to it, you can directly request specific fields (avoiding the need for parsing the output with jq) and store those values to an environment variable if desired:

$ op item get Item --field password
$ export MY_SECRET=$(op item get Item --field password)

Using this, the example from our previous post can be simplified:

BEFORE:

awsenv() {
    $(op --format json --no-color item get $1 | jq -r '.fields[]|select(.label|startswith("AWS_"))|.label+"="+.value' | gsed -z 's/^/export /; s/\n/ /g')
}

AFTER:

awsenv() { export API_KEY=$( op item get $1 --field API_KEY ) export API_SECRET=$( op item get $1 --field API_SECRET ) }

But, wait! Before you go adding secrets to your environment that way, you should know about a new alternative. 1Password CLI lets you use secret references to insert secrets without editing the environment file or commands that you usually use to deploy your application. At runtime, secret references are replaced by the contents of the field that they reference in your 1Password account.

The command-line tool has a new run sub-command that makes variables available to your app in a limited context.

Using a special syntax to define your variables, you can avoid storing the secrets themselves. The basic format is op://vault/item/[section/]field. For example, to use the Access Key ID from the item above, you can set variables like this:

$ export API_KEY="op://Private/hdlzmqagfnf5bk5yxdgmyvamvq/API Access/Access Key ID" $ export API_SECRET="op://Private/hdlzmqagfnf5bk5yxdgmyvamvq/API Access/Secret Access Key"

You can use the item’s name in most cases, but because our example item’s name contains a special character, we need to use the ID instead.

To make the actual values available to a command like aws, use op run:

$ op run -- aws s3 ls

If you find yourself doing that frequently, you might want to create an alias:

$ alias aws="op run -- $( which aws )"

More ways to switch environments

If you find yourself switching AWS environments frequently like we do at Six Feet Up, there are a couple of options to streamline the process.

Create a different function or script specific to each environment.

Create a shell function like awsenv() that takes the item’s name or ID and populates the variables with the new op:// style values.

Use a tool like direnv to automate setting variables based on your working directory. (This is what I recommend, but won’t be detailed here. We’ll cover direnv in a separate post.)

Use 1Password to Manage Secrets and Environments

Legible outputs

More ways to authenticate

Syntax changes

More ways to switch environments

Contact Us

HEAR FROM US