I am trying to use
op to set environment variable for my active shell session. Instead of hardcoding something like
export MYSECRET=sosecret, I would rather populate the environment variable through
op. Ideally, I can set multiple env variables this way.
I have seen
op run, but while more secure, it injects the variables only into the currently active process.
Basically, I am trying to replace direnv with
1Password Version: 8.7.0
Extension Version: Not Provided
OS Version: macOS 12.3
I did find a way to use direnv to set the variables: https://1password.community/discussion/comment/634363#Comment_634363. This is probably good enough for my needs and since the variables are unloaded the moment I exit the directory, it is somewhat secure.
Hey @dnsstaiger, thank you for reaching out to us!
We are currently working on some native way to achieve this with the CLI, so stay tuned for the next releases!
In the meantime, there is a workaround for this: you can move your
direnvenvironment variables to a
.envfile, replace their values with secret references, and start a privileged session, with access to these secrets, using
op run --env-file .env -- $SHELL. Please do mind that you'll need to explicitly terminate this session (
exit) at the end of it, in order to de-populate the environment.
Another possibility is using direnv in conjunction with
op run: adding envvars with secret references in your
.envrc, and starting a privileged session from within the directory. In this case there would be no need for a
.envfile, since the envvars in question are in your session environment:
op run -- $SHELL. Once again, please do proceed with caution and exit the privileged shell once access to the secrets is no longer needed.
Please let us know if this helps. This process is a bit cumbersome at the moment, so we hope you'll try the native CLI approach, once it comes out.
We're looking forward to hearing from you!
Hi @Horia.Culea_1P. Thanks a lot for the insight. Besides the security aspect, I found that my approach is quite slow when loading 10 to 20 secrets that way. This is most likely the case because of running
opfor each secret separately, so your suggestion with using a priviledged shell session might make things more performant.
I am happy to try the improved process once it becomes available.
No worries, let us know if we can help with anything else!
It might also be worth checking out this third-party integration developed by one of our customers: https://github.com/tmatilai/direnv-1password
See the entire discussion here: https://1password.community/discussion/126437/16-17-20-37-38-support-for-both-versions-in-scripts
@Horia.Culea_1P I have been keeping an eye on the latest
opcli releases since you mentioned a feature coming up to simplify this type of integration:
Has this feature landed yet? If so, can you point me into the right direction? Really looking forward to a slick integration with
direnv(or an alternative approach which does not require
direnvto safely set
envvars for a directory/session).
Hey @dnsstaiger, thank you for reaching out!
Not yet! This project is still with our Product team, considering the use-cases and potential areas where such a feature would benefit the workflows of our users.
We'll keep this thread updated, when we have news about this.
Sounds great, @Horia.Culea_1P. Thanks for the insight
My pleasure. Let us know if we can help with anything else. :)