Forum Discussion

integralist's avatar
integralist
New Contributor
4 months ago
Solved

Why does the 1P CLI not access the local 1P store?

👋 I have a shell script with lots of "secret references"... export EXAMPLE1_API_KEY=$(op read "op://<VAULT_NAME>/<ENTRY_NAME>/<SECTION_NAME>/<FIELD_NAME>") export EXAMPLE2_API_KEY=$(op read "op:/...
CLI
  • integralist's avatar
    integralist
    13 days ago

    Thanks theo​ I didn't realise that `op inject` did a bulk fetch. That actually means I can completely drop my other work-around in favour of doing this...

    In a `~/.localrc` I have:

    export EXAMPLE_API_KEY={{ op://VaultName/SecretName/SectionName/TokenName }}
export ANOTHER_API_KEY={{ op://VaultName/SecretName/SectionName/TokenName }}

    I can then source via `op inject` from my `~/.zshrc`:

    # Configuration you don't want as part of your main .zshrc
# For me, this is a template file that includes 1Password secret references.
# Meaning, I need to source the file via `op inject` so I can interpolate my secrets.
#
if [ -f "$HOME/.localrc" ]; then
	if command -v op >/dev/null; then
		op signin --account my.1password.com
		source <(op inject -i $HOME/.localrc)
	fi
fi

    This loads much faster now, even when I open a new shell instance I just get a single OS popup asking me to authorize the shell to access 1Password (and I don't need my password as it has that already and so it just needs me to press a button, which I'm fine with -- see screenshot).

     

theo's avatar
theo
New Contributor
13 days ago

Definitely would be nice if the SDKs and CLI had a way to relying on the local app cache. Here is the related issue (https://github.com/1Password/onepassword-sdk-js/issues/111) I opened for the js sdk.

Short of that, at least fetching items in bulk, is a good first step. When we build the dmno 1password plugin (https://dmno.dev/docs/plugins/1password/). Because we want to rely on the CLI for auth during local dev, we used `op inject` (https://developer.1password.com/docs/cli/reference/commands/inject/) which will fetch items in bulk. I imagine you could use this to set many vars at once.

In our plugin we also have some caching logic, will process the items and only fetch those that are needed, and a way to store those items (encrypted). Your script does make sense, and the caching is nice, but one downside is your cache then becomes a potential vulnerability.

integralist's avatar
integralist
New Contributor
13 days ago

Thanks theo​ I didn't realise that `op inject` did a bulk fetch. That actually means I can completely drop my other work-around in favour of doing this...

In a `~/.localrc` I have:

export EXAMPLE_API_KEY={{ op://VaultName/SecretName/SectionName/TokenName }}
export ANOTHER_API_KEY={{ op://VaultName/SecretName/SectionName/TokenName }}

I can then source via `op inject` from my `~/.zshrc`:

# Configuration you don't want as part of your main .zshrc
# For me, this is a template file that includes 1Password secret references.
# Meaning, I need to source the file via `op inject` so I can interpolate my secrets.
#
if [ -f "$HOME/.localrc" ]; then
	if command -v op >/dev/null; then
		op signin --account my.1password.com
		source <(op inject -i $HOME/.localrc)
	fi
fi

This loads much faster now, even when I open a new shell instance I just get a single OS popup asking me to authorize the shell to access 1Password (and I don't need my password as it has that already and so it just needs me to press a button, which I'm fine with -- see screenshot).