-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Google Cloud KMS signing capability #442
Conversation
2f3fc8f
to
f9b8380
Compare
The discussion that maybe makes sense at this point is private key abstraction in general: I have a dispatch/factory method in KMSSigner but maybe that should be in Signer itself? See full details in #445 (comment) |
securesystemslib/kms_signer.py
Outdated
if key["keytype"] == "ed25519" and key["scheme"] == "ed25519": | ||
# specification default is sha-512 | ||
return "sha512" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure where I got this impression from...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, the spec defines sha512 and the identity function as the prehash options. Using identity (i.e. no hashing) in this case would indeed be silly (we want to send something small over the network)...
However, spec uses "ed25519" to mean the identity prehashed scheme, and "ed25519ph" as the SHA512 prehashed scheme: It's entrirely possible that our current implementation does the former and then we would have to add a new scheme to the ed25519 keytype to signify the prehashed scheme.
Considering that GCP KMS does not even support ed25519, I think I'll just remove this if-clause
So after a bit of consideration, I think this makes sense:
|
ba9ffbf
to
b1b260f
Compare
Oops. I thought I had figured out a way to allow running KMS tests on PRs safely but hit a very practical issue: authenticating to GCP requires the OIDC token from GitHub which understandably isn't given to PRs that come from forks. So I don't think we can run the KMS test on PRs safely. We can run it on pushes or cron but that's not as nice :( |
OK, tests now only run on push, not on PRs. Here is the test run on my repo https://github.com/jku/securesystemslib/actions/runs/3384917757/jobs/5622619919 (the GCP setup currently accepts requests from both "jku/securesystemslib" and "secure-systems-lab/securesystemslib") |
Ok, final change: added issue filing on failure (otherwise no-one notices when this fails since it does not run on PRs from forks). Setting non-draft now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is super cool and I have nothing to add, except some very minor nits. Feel free to address or ignore as you see fit. Also, let me know if you want to defer merging until after #456.
I was thinking no need ... but since I'm now going to suggest splitting the code to internal submodules maybe that is indeed a good idea -- let's see how "easy" 456 looks to merge once I get a non-draft version ready |
4fd174c
to
ae52e1d
Compare
this is now waiting for #456 merge |
This does not change API but makes it easier to implement Signers/Keys in multiple files.
A bare bones Signer for Google Cloud KMS: Private keys live in KMS, signing happens in KMS (although payload hashing happens in Signer). Key creation or import is not supported at this point. A test is added with a few caveats: * dependencies are not added to requirements.txt: this would more than triple the size of requirements-pinned.txt... There is a separate requirements file: this is not ideal but best I could come up with. * Test only works on GitHub (because of the GCP authentication), and only on branches within the upstream repo: not on PRs from forks * Test is run only once: it's a smoke test, not an exhaustive matrix test.
Since the tests run on push, it's not easy to notice a failure. File an issue if it happens.
The GCPSigner that was added is not tested in the standard test run, only when check_kms_signers is explicitly ran. This is because the test will fail everywhere except the projects Github CI. Lower required coverage as a workaround.
Changes since the first review:
Can I ask you to have another look @lukpueh? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found one more non-blocking nit. Re-approving...
Add support for Google Cloud KMS signing. The use case for this is TUF repositories with online keys. Removing the private key material from the repository software is a good thing for security: a compromise of the repository software will then only allow signing during the compromise but won't allow stealing the private keys.
The included Google implementation depends on implicit authentication: the runtime environment should contain authentication credentials that google.cloud.kms library is able to find.
Example of a test run: https://github.com/jku/securesystemslib/actions/runs/3384917757/jobs/5622619919
This uses
google-github-actions/auth
to authenticate to Google Cloud (this is the implicit authentication part): the github project token is configured to have Signer/Verifier permissions in Google KMS.The usability should improve if #447 or something like it gets implemented:
gcpkms://projects/python-tuf-kms/locations/global/keyRings/securesystemslib-tests/cryptoKeys/ecdsa-sha2-nistp256/cryptoKeyVersions/1
Key.get_payload_hash_algorithm()
would be helpful at that point (needed by signer but it doesn't have to be public)Please verify and check that the pull request fulfils the following requirements: