vapor-ware / sctl

SCTL is not End2End encryption, instead SCTL is more of an envelope, in which you store secrets until they are needed, and those secrets should only remain available in plain text while the operation that needs them is active.
GNU General Public License v3.0
8 stars 2 forks source link

Condense `--key` flag to allow for abbreviated keys #6

Closed marcoceppi closed 5 years ago

marcoceppi commented 5 years ago

Currently you need to pass --key=projects/production-217413/locations/us/keyRings/operations-keyring/cryptoKeys/vapor-operations however, a lot of that is data which can be inferred:

--key=production-217413/us/operations-keyring/vapor-operations

which will afford some space in expansion

lazypower commented 5 years ago

you dont actually have to pass the --key argument. This is provided as a convenience to override the value you set in ENV. ENV is then passed down as the KEY val so you can safely omit it under most circumstances so long as you have set the SCTL_KEY env var.

Did this address the issue or did I misunderstand? My thought process being, if we start subbing things in the path, that tightly binds this to gcloud's IAM structure, though I'm not aware of any other KMS services outside of azure/aws at this time, and neither of those use URI's that are compatible with one another, so maybe its fine. :man_shrugging:

lazypower commented 4 years ago

To address this, as of 1.2.0 we've started embedding the key in the state file, so --key is now technically optional save for first run.

Hopefully this helps cut down on the annoyance of punching in a super long key multiple-times per workflow