Secret reference syntax usable by direnv?

jc00ke
jc00ke
Community Member

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

Comments

  • dnsstaiger
    dnsstaiger
    Community Member

    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
    dnsstaiger
    Community Member
    edited March 2022

    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

  • 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

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

  • jc00ke
    jc00ke
    Community Member

    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!

  • 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
    jc00ke
    Community Member

    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

  • 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
    coreyti
    Community Member
    edited October 2022

    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
    jc00ke
    Community Member

    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! 👏👏👏

  • Super happy to see our customers collaborating! Thanks!

This discussion has been closed.