Implementation for file signing verification.

[matglas]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Implementing the VerifyFile mechanism to be used by SignFile to validate if the signing of a file was successful and
to verify signed files in the future independently.

Which issue(s) this PR fixes:

Fixes #30

Things done:

• Adjust interface for VerifyFileInternal as it need more options to be
  usable.
• Wrap FindTLogEntriesByPayload from cosign to be able to mock it.
  Removed some options as they are not needed. Up for discussion if its
  wise to do.
• Implementation of VerifyFileInternal.
• Implementation of VerifyFile using the impl.
• Added a copy of the helper from cosign for getting payloadBytes.
• Added a helper to retrieve the sha256 from the path to the file that is signed.
• Simple IsFileSigned to start the verification with. Checking the
  existence of uuids for the specific file blob.

Special notes for your reviewer:

1. The FindTLogEntriesByPayload is now a partial wrapper around same method in cosign. I stripped some arguments as we don't need it. But it might be valuable to keep them to not adjust the interface more later. Like to hear others thoughts on this.

We created a wrapper to allow us to easily test finding results from Rekor.

2. To verify correctly we need the OutputCertificatePath and the OutputSignaturePath. Do we know if those are being created and stored when the signing happens. And where are those stored after the signing ceremony. Because now it seems we can only verify during our Signing.

After a conversation with @saschagrunert we decided that the paths would be auto set to <file path>.sig and <file path>.cert. But the user that implements the signing can choose to adjust the output paths.

Special note: If one relies on SignedObject there is a breaking change. It is refactored to hold Image and File object depending on the type of signing that happens.

@kubernetes/release-managers

TODO:

• This PR needs tests.
• Rework after feedback.

[k8s-ci-robot]

Welcome @matglas!

It looks like this is your first PR to kubernetes-sigs/release-sdk 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/release-sdk has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @matglas. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[matglas]

For testing signed a dummy file myself.

# Random input file.
echo $RANDOM > test-blob.txt

# test-blob.sig is the resulting signature.
# test-blob.cert is the temporary cert that signed.
# test-blob.out is the output for future reference during debugging.
COSIGN_EXPERIMENTAL=1 cosign --timeout 90s sign-blob \
    --output-signature test-blob.txt.sig \
    test-blob.txt > test-blob.out

To verify use the test-blob.sig and the original test-blob.txt.

COSIGN_EXPERIMENTAL=1 cosign verify-blob \
    --signature test-blob.txt.sig \
    test-blob.txt

Get result from Rekor

rekor-cli search --artifact=test-blob.txt --format=json

Use the uuid from the search to get the results.

rekor-cli get --uuid=<uuid>

You can validate the content of the test-blob.txt.sig with the signature and
the test-blob.cert with the publicKey.content part of the get.

[saschagrunert]

Awesome, thank you for working on this one! I left a few review comments 👇

[saschagrunert]

/ok-to-test

[matglas]

I need to review the test cases and come back. I know that some will not work anymore. Also I'm thinking about changing the SignedObject used in the return of VerifyFile to include a UUID and TLog entry from Rekor. Or create a new SignedFileObject that holds that data.

Probably something along the lines of:

• sha
• tlog
• uuid
• signature

[matglas]

Had to rebase and force push because my commits where not signed yet.

[saschagrunert]

@matglas please rebase again :)

[matglas]

No problem. Planning to continue working on it on Monday.

[matglas]

Some decisions from a thread I had with @saschagrunert

• By default we will use output cert and signature path that are the file path of the file that is being signed suffixed with .sig and .cert.
• In the TestCases we add options to allow for setting the OutputCertificatePath and OutputSignaturePath to allow the API user to decide an alternative location and test for those cases.
• The SignedObject struct will be refactored to embed Image and File type to create a seamless usage experience but adjust for the different types of Signing data.

Example from @saschagrunert from the Slack thread.

type SignedObject struct {
	*Image
	*File
}

type Image struct {
	reference string
	digest    string
	signature string
}

type File struct {
	signaturePath   string
	certificatePath string
}

[matglas]

I am not satisfied with the wording in error messages if there are suggestions I am open for that. Problem is they feel not consice with the other messages and sometimes done convey what the error could be about.

[saschagrunert]

Great work, I just have a bunch of comments 👇

[saschagrunert]

@matglas is this still WIP?

[matglas]

No not anymore. Its going into active testing now and getting feedback on the design. I will remove wip.

[matglas]

I have to create a test to validate identity token to work for keyless signing with this implementation. Is that possible with the way that the integration job runs? Can we get an identity token in that env?

[saschagrunert]

Hm, I know GitHub actions supports keyless signing, maybe we have to switch to that for the integration tests.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: matglas, saschagrunert

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [saschagrunert]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment