1Password Environments Beta is awesome

Hi @ddlawson ,

Thanks for sharing your gracious thoughts and your feature requests as well!  

We will see to it that these get to the right hands internally.  Please feel free to reach out at any time.

Regards,
Phil & team

I just tried it out too and also find it pretty cool. Jumped on the forum to see if people are preferring it over the commands.

The positives:

• Easy to use and `.env` files "just work".
• Reduces attack surface to only `.env` files you're actively using.
• None of the quirks of running commands through `op run`.

The negatives:

• While it does reduce the attack surface, imo your secrets a lot more exposed compared to  `op run`.

And that last point is the reason why I probably won't use Environments.

• `op run` limits your secret access to the command you ran it on (like only your dev server).
• Environments do not limit secret access, once you allow an `.env` to be readable, anything running on your system can now read those secrets.

I imagine that's "good enough" for most people, but having lost a key I'm a bit too paranoid to allow API keys outside the specific process I grant it to.

But, with that said I enjoyed trying it out, `op run` is a pain on monorepos. One thing that could be improved:

• If your env files have "Secret References", 1Pass Environments doesn't seem to handle those. It just imports the reference as the value of the env variable, I would've expected it to replace the reference with the value. Or even better if it could just "link" the env value to a field via "Secret Reference" that would reduce the redundancy of having API keys in both Environments and as separate API credential entries.

I didn't know where else to vote or plus1 the suggestion, so I'm just commenting here...

Would really like to have the ability to "link" an environment variable's value to a field in a vault. I like to keep deployment info for each project I have in a separate vault. The vault will contain secrets that I would include in an environment, but also things that I would not (such as root passwords, service account tokens, etc). I don't want to duplicate values in both the vault and the environment. Using a "secret reference" as the value of the environment variable would be good enough for my usage.

Thanks for the consideration!