Secret reference syntax usable by direnv?

jc00ke

I see on docs/cli/secrets-environment-variables that I can op run -- myapp start but what if I wanted to load secret values via direnv? I don't see anything in the direnv-stdlib and was wondering if anyone had a solution.

Thanks!

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided

dnsstaiger

I am having the same question. Also tried some shell foo to integrate op with direnv, but have not been successful so far. Anybody has an idea?

dnsstaiger

Actually, I found that adding the passwords to .envrc like so works: export BAR="$(op read op://vault/item/[section/]field)". A bit verbose, but it's a start

Horia.Culea_1P

Hey both!

Nice workaround, @dnsstaiger! Indeed, that should be the closest we can get right now to an integration with direnv.
We actually have something in the oven that should help with this, so stay tuned for the future releases!
In the meantime, I think the workaround above is a pretty good one. If you're not comfortable with op read-ing multiple times in your .envrc, there is another way to achieve this, using op run, as I described here: https://1password.community/discussion/128381/populate-environment-variable-for-active-shell-session#latest

Let me know if this help, @jc00ke! We're looking forward to hearing from you!

Best,
Horia

Horia.Culea_1P

It might also be worth checking out this third-party integration developed by one of our customers: https://github.com/tmatilai/direnv-1password

Horia.Culea_1P

See the entire discussion here https://1password.community/discussion/126437/16-17-20-37-38-support-for-both-versions-in-scripts

jc00ke

Hi @Horia.Culea_1P

I don't have access to see https://1password.community/discussion/126437/16-17-20-37-38-support-for-both-versions-in-scripts

Thanks for posting https://github.com/tmatilai/direnv-1password that looks like a good alternative.

I'm not quite following what you posted here. Could you whip up a gist or something as to how this would work?

Thanks!

Horia.Culea_1P

Hey @jc00ke, terribly sorry for the late reply. Let me elaborate a bit on the alternatives described there:

You can move your direnv environment variables to a .env file, 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.

Let's assume your .envrc contains something like this:

export FOO=BAR
export BAZ=XYZ

You can save the BAR and BAZ values in 1Password and replace then in your .envrc with the corresponding secret references. .envrc becomes:

export FOO=op://path/to/bar
export BAZ=op://path/to/xyz

Now, running op run --env-file .envrc -- $SHELL will start a privileged session, where you have the resolved FOO and BAZ in your environment. You will need to explicitly type exit, in order to terminate this session.

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 .env file, 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.

Same scenario as above, let's assume you've replaced your envvars values with secret references. This is your .envrc:

export FOO=op://path/to/bar
export BAZ=op://path/to/xyz

You can now run direnv allow . and these envvars with secret references will be exported in your environment. You can just simply run op run -- $SHELL and they will be resolved. At the end of this session, you should once again explictly type exit.

I hope this clears this up a bit.

Don't hesitate to ask any additional questions, if need be.
Looking forward to hearing from you!

Best,
Horia

jc00ke

Thanks @Horia.Culea_1P, I appreciate the insightful reply! Unfortunately neither of those will do it for my workflow. The privileged session is a different shell, or so it seems, as it's definitely not the fish shell that I use. Taking me out of fish is a deal-breaker.

I opted for op inject -i .envrc.tpl -o .envrc and that'll do it for now.

Thanks again for the help!
Jesse

Horia.Culea_1P

Hey @jc00ke , terribly sorry for the late response. If you have a preference for a specific shell, you can very well replace $SHELL with fish.

op run --env-file .envrc -- fish

should open a fish privileged session. Let me know if this helps.

Best,
Horia

coreyti

This might not be exactly what you were looking for, @jc00ke, but it may be adjacent and potentially useful.

Given a "secure note" in 1password, named "Example - Direnv", stored in a vault named "Private", and with the following content:

export DIRENV_OVER_1PASSWORD="success"

and a .envrc file in a project, with the following content:

$(op item get 'Example - Direnv' --fields label=text | xargs echo)

or:

$(op read 'op://Private/Example - Direnv/text')

I found that, assuming you've already done a eval $(op signin), the following works:

$ echo $DIRENV_OVER_1PASSWORD
"success"

Also, hi Jesse!

jc00ke

Hi @coreyti, thanks for that suggestion! I like it! I've settled on the op inject method and it's working out well. We don't add/change secrets often, so I'd rather incur the cost of reading from 1Password only once in a while. I appreciate your solution though! 👏👏👏

andi.t_1P

Super happy to see our customers collaborating! Thanks!