DM-49929: Load OP_CONNECT_TOKEN and VAULT_TOKEN from 1Password via env file #4486
Conversation
There was a problem hiding this comment.
The 1Password stuff is great, thank you!
PHALANX_ENV for the command-line tool makes me nervous because no matter how much you tell people to use env to set the environment variable for only that command, my experience is that some number of people don't listen to you and do export PHALANX_ENV=idfprod so that they can stop typing it each time. This then becomes a land mine and two days later they run phalanx secrets sync --delete in the same window and accidentally do production (for example).
I therefore feel like forcing people to explicitly name the environment on the command line is a bit of a safety feature, and am not sure getting rid of it is a good idea. It's still true that people can make aliases that accomplish the same thing and are dangerous in the same way, but that requires a bit more intentional effort that hopefully would be linked with a bit more caution.
|
Ok that sounds reasonable. So I'll drop |
These op/*.env file allows the OP_CONNECT_TOKEN and VAULT_TOKEN to be referenced directly from 1Password rather than being manually exported onto the admin's shell.
jonathansick
force-pushed
the
tickets/DM-49929
branch
from
9e7fcb3 to
15cfa37
Compare
|
@rra I've reworked the PR with individual env files for each Phalanx environment and also worked the method into our documentation (using tab sets) to show the op run methodology as an option. |
This PR takes advantage of the 1Password CLI's ability to load secrets referenced by their path in a .env file. With this change, admins no longer need to manually load the VAULT_TOKEN and OP_CONNECT_TOKEN into their shell environments to run phalanx commands like
phalanx secrets sync. An example usage is:Note that I've had the user set PHALANX_ENV, which is used to specify secret paths in
square.envspecific to that Phalanx environment. I've also modified the Phalanx CLI to acceptPHALANX_ENVas an environment variable instead of as a command-line argument.Note an alternative approach could be to have a separate
.envfile for each Phalanx environment. This would let us setPHALANX_ENVin that file, and make the resulting CL invocations shorter, at the small cost fo maintaining more.envfiles. E.g.op run --env-file="op/idfprod.env" -- phalanx secrets auditWhat do you think? Perhaps this second approach would provide a better user experience.