How can I prevent to authenticate constantly to retrieve secrets ?

mikaellDid you ever figure this out?  Can you give some hints on how you implemented it?

I just started doing this myself, replacing hard-coded secrets in my .zshrc in macOS.  In my case, it's an API token I use regularly in shell functions which contain calls to `curl`.  For now, this is just a pilot.

I only have one call to the `op` v2 CLI tool, and it looks like this:

export TOKEN="$(op item get 'my API token' --fields label=credential)"

This works great by itself.  The problem I have is I have a fairly complex environment in my terminal emulator.  I rely on the tmux terminal multiplexer, and I make use of the tmux-resurrect plugin to automatically spin up my entire tmux environment if the tmux server isn't running (mostly, after reboot).

tmux-resurrect will spin up a number of sessions, each containing one or more windows, and several (not all) windows will have more than one pane.  In each pane will be a separate instance of zsh, and this is where I run into the problem.

When tmux is spinning up my environment, I appear to get prompted to authenticate every instance of zsh.  I use biometric/fingerprint authentication, so it's not a huge deal, but I have to click through several (10+) 1Password biometric authentication prompts before they're all authenticated.  Also, it's not unheard of for me to spin up another session, window or pane, and any new zsh instance also needs to be authenticated (even if others have already been authenticated recently).

I did see where I can disable app integration and use the session key in an environment variable, but that seems awfully hacky and not really what I'd want.  I'm thinking of maybe setting these `op` calls in a tmux environment variable instead, so the retrieval of my secrets will only happen once when the tmux server spins up. 

That will likely be my solution, but how did you do it?

Happy to help! 😄

Thanks Dayton_ag. Indeed, using op run in an alias, should be the easiest way to manage that issue. Thanks for pointing toward that direction.

Hey mickael, I wonder if 1Password Shell plugins would be a good fit? This allows you to reference credentials in 1Password when using command line tools - while we don't have a shell plugin for SendGrid yet, it's possible to build your own: Build your own shell plugins (beta) Developer

Outside of shell plugins, you can also load secrets into your environment using op run - this article discusses it a little further: Load secrets into the environment Developer

Let me know what you think! 😀

Hey 1P_Dave

Thanks for taking time to answer.

Yes, I have biometric support enabled.

My use case is simple, I replaced some secrets in env variables in my dotfiles with calls to op cli. For example, the SendGrid Auth API key can be stored in an ENV variable: https://docs.sendgrid.com/ui/account-and-settings/api-keys

But I guess, regardings 1password auth restrictions, I have to change the way to access that info. Hopefully, this is a script I manage personally, so I will embed the call to op directly in it.

But my question was more general, on the adequate way to replace ENV vars that store secrets with refereces to 1password entries.

Hello mickael! 👋

Thank you for the question! Being asked to authenticate in each new terminal session is part of the CLI integration's authorization model:

Each time you use a 1Password CLI command in a new terminal window or tab, you'll need to authorize your account again:

• On macOS and Linux, authorization is confined to a terminal session but extends to sub-shell processes in that window.
• On Windows, commands executed in a sub-shell require separate authorization.

You can read more here: 1Password app integration security Developer

Can you tell me a little more about the use case here? Are you regularly opening new terminal windows when using the CLI? Do you already have biometric unlock enabled to make it easier to unlock 1Password rather than typing in your account password each time?

-Dave