You can already put op:// references in .env and read them with `op run`.
1P will conceal the value if asked to print to output.
I combine this with a 1P service account that only has access to a vault that contains my development secrets. Prod secrets are inaccessible. Reading dev secrets doesn't require my fingerprint; prod secrets does, so that'd be a red flag if it ever happened.
In the 1P web console I've removed 'read' access from my own account to the vault that contains my prod keys. So they're not even on this laptop. (I can still 'manage' which allows me to re-add 'read' access, as required. From the web console, not the local app.)
I'm sure it isn't technically 'perfect' but I feel it'd have to be a sophisticated, dedicated attack that managed to exfiltrate my prod keys.
alt Hacker News
You can already put op:// references in .env and read them with `op run`.
1P will conceal the value if asked to print to output.
I combine this with a 1P service account that only has access to a vault that contains my development secrets. Prod secrets are inaccessible. Reading dev secrets doesn't require my fingerprint; prod secrets does, so that'd be a red flag if it ever happened.
In the 1P web console I've removed 'read' access from my own account to the vault that contains my prod keys. So they're not even on this laptop. (I can still 'manage' which allows me to re-add 'read' access, as required. From the web console, not the local app.)
I'm sure it isn't technically 'perfect' but I feel it'd have to be a sophisticated, dedicated attack that managed to exfiltrate my prod keys.