Add new signing and storage features#245
Conversation
|
Hi @rgreinho. Thanks for your PR. I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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. |
priyawadhwa
left a comment
There was a problem hiding this comment.
Thanks for opening the draft PR! This is a great start. WDYT of creating a Verifier interface analogous to the Signer interface we already have?
I'm kinda imagining something like this, but haven't fully thought through if it would be easier to implement this or do like a TaskRunSignerVerifier type thing instead :)
type Verifier interface {
VerifyTaskRun(ctx context.Context, tr *v1beta1.TaskRun) error)
}
type TaskRunVerifier struct {
// use this to read the configmap and get details for the signer&storage backend
KubeClient kubernetes.Interface
// looks like we need this for getting signers
SecretPath string
}067e209 to
f63379a
Compare
|
@priyawadhwa I think I am on a good track here. I turned the signer into a I added functions to the various supported backends to allow retrieving the payload and the signature. However for OCI backend I don't think we can implement these features right now because we do not store the information of the target image, mostly the digest which is computed for the upload then forgotten. Please correct me if I am mistaken, in which case a few pointers would be appreciated. I am going to try to use what I created in the CLI (tektoncd/cli#1440) in order to move forward with this PR as well and bring more testing/validation to theses new features. |
priyawadhwa
left a comment
There was a problem hiding this comment.
This is looking really good! Just left a couple small comments.
I think we can actually use this code in our integration tests as well, which would be nice because it should simplify the test & we can make sure this works correctly!
For each test we do manual verification -- would it be easy to use this interface to verify instead? e.g. we could replace this code with your verification code:
Lines 92 to 107 in 231a880
| SecretPath string | ||
| } | ||
|
|
||
| type Verifier interface { |
There was a problem hiding this comment.
could we move all verification code to pkg/chains/verify.go? might just make it easier to find
There was a problem hiding this comment.
This is looking really good! Just left a couple small comments.
I think we can actually use this code in our integration tests as well, which would be nice because it should simplify the test & we can make sure this works correctly!
For each test we do manual verification -- would it be easy to use this interface to verify instead? e.g. we could replace this code with your verification code:
I like the sound of it 😃
However I am facing the same problem as in the CLI, thus I am glad you brought this up.
In order to do what you described above, I need to create a new backend. I attempted to do create one using the storage.InitializeBackends() function, but I am not sure what the parameters are and how to get them, especially ps versioned.Interface, kc kubernetes.Interface and cfg config.Config. I already had the TaskRun, so this parameter was fine, and for the logger, I just created a new Zap SugarLogger. Could you provide some pointers regarding the rest?
There was a problem hiding this comment.
could we move all verification code to
pkg/chains/verify.go? might just make it easier to find
Absolutely 👍
There was a problem hiding this comment.
For sure! So to verify I believe all we should need are:
cfg config.Configkc kubernetes.Interface, which we'll use to actually read the ConfigMap intocfg
We can use kc to get the ConfigMap object from the cluster, and then we can pass the data into NewConfigFromConfigMap to get cfg. Once we have cfg, I believe that's everything we need for verification.
I don't think we need the PipelineClientset for anything, just the kubernetes Client should be sufficient.
Does this make sense?
|
Yes it does! Thank you for the pointers, So I updated a few tests. I actually needed the Side question: when are the e2e tests being executed? For instance I could not test the GCS implementation as it requires an account, so being able to see it run in a CI somewhere would have been fantastic. |
priyawadhwa
left a comment
There was a problem hiding this comment.
left a few comments :)
LGTM!
Ah yes, so the e2e tests are executed on an ephemeral k8s cluster created by prow. we acutally don't run the GCS tests at the moment bc that cluster doesn't have the required auth. you can skip testing it for now, i can manually run the test once this is merged! |
|
Alright, all the comments are addressed. I also used this change in tektoncd/cli#1440 to see how it would look, and I think it reads pretty well (e.g.: https://github.com/tektoncd/cli/blob/16aa1f2da2b9ae697d76b4ebf91a7163a5f36a52/pkg/cmd/chains/payload.go). |
|
Awesome! This is looking pretty good to me, let's try and run the tests and hopefully they're happy 🤞🏽 |
|
/ok-to-test |
|
The following is the coverage report on the affected files.
|
|
The following is the coverage report on the affected files.
|
|
The following is the coverage report on the affected files.
|
|
OK, looks like I got it right after a few tries 😅 Do you need me to squash the commits? Also, side note for now, but it will become important soon, if I import the chains module into tekton cli, the CLI does not build anymore: @vdemeester fixed some dependencies and replacements in tektoncd/cli@f44ccbd, so we may have to do something similar here as well. |
|
@rgreinho Noob request: would you mind adding a PR description listing the changes/improvements that are going in :) ? |
|
Absolutely:
@priyawadhwa there is no changelog file for this project, should we start one? |
Yah I think the commits will need to be squashed for prow to merge :)
Hmm if it's just a matter of updating our deps that should be easy enough! I can look into it more if it's not that simple.
Sure! Thanks :) |
Not necessarily needed. I think tektoncd/chains can support all github merge ways and doesn't require commits to be squashed. But usually it is prefered 😝 .
On other tekton project, so far we rely on a release-note "special preformatted paragraph" to build the release-note/changelog of a release (https://github.com/tektoncd/pipeline/releases/tag/v0.28.0 is mostly generated automatically). Not sure if chains wants to adopt this or not, just thought it was worth mentionning 😉 |
e87c85d to
e39fc3e
Compare
|
The following is the coverage report on the affected files.
|
|
We could try updating the |
That sounds really good! I'll look into it :) |
I moved this problem to another issue: #269 |
Adds a set of new features to the signing and storage packages to allow extracting chains information and verify the signature. Adds implementations andi for the following backends: * Tekton * DocDB * GCS The unit and end to end tests have been updated accordingly.
e39fc3e to
2c6b266
Compare
|
I cleaned up the PR and it is now ready for the final review 🤗 |
|
The following is the coverage report on the affected files.
|
priyawadhwa
left a comment
There was a problem hiding this comment.
lgtm! thanks @rgreinho 🎉 🔥
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: priyawadhwa The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/ok-to-test |
|
/lgtm |
|
The following is the coverage report on the affected files.
|
Adds a set of new features to the signing and storage packages to allow
extracting chains information and verify the signature.