Skip to content

Conversation

@lukpueh
Copy link
Collaborator

@lukpueh lukpueh commented Jun 4, 2024

Changes key loading helpers used by admin ceremony and metadata update commands to provide an option to the user to load a public key from HashiCorp Vault into TUF metadata.

TODO:

  • update to securesystemslib 1.0.0 to use VaultSigner (this will require a major sweep through the code base)
  • adopt change in existing metadata update and sign tests (currently, only helper tests are updated)
  • add new tests
  • re-think "ambient" config needed by HashiCorp client. options are:
    1. tell user to provide config out-of-band, e.g. via rc file, env vars, etc. as expected by securesystemslib
    2. prompt user for config, and re-export in a form supported by securesystemslib

tuf-on-ci does the former (see "Prepare your local environment" in its docs/ONLINE-SIGNING-SETUP.md (cc @jku, who might be willing to share some wisdom )

Lukas Puehringer added 4 commits June 4, 2024 16:18
In preparation for supporting multiple online key types, this helper
is changed to return the key and a uri to access the corresponding
signer.

Since the helper is still used for online and offline key configuration,
via a common intermediary helper `_load_key_prompt`, the returned uri is
not yet used.

Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Prompts for key name in vault and return uri and key.

Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Rename _load_key_prompt to _load_offline_key_prompt. This stays the
same and currently only supports loading a key from file.

Add new _load_online_key_prompt to load key from either file, or
hashicorp vault.

Change _configure_online_key_prompt to use _load_online_key_prompt,
which return the key already with the uri included.

Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
@jku
Copy link

jku commented Jun 5, 2024

tuf-on-ci does the former (see "Prepare your local environment" in its docs/ONLINE-SIGNING-SETUP.md (cc @jku, who might be willing to share some wisdom )

I'm still not sure if that was the best idea:

  • on one hand once the KMS access is setup it works really smoothly, is not much code in the signing tool itself, and is very reliable (less chance for copy-pasting mistakes)
  • on the other hand getting the KMS permissions and authenticating can be a hassle for the user: maybe copy pasting data from the KMS web UI would be overall easier for user?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants