add krel sign blobs and images commands

[cpanato]

What type of PR is this?

/kind feature

What this PR does / why we need it:

• add krel sign command to sign artifacts

/assign @saschagrunert @puerco @xmudrii @jeremyrickard

Which issue(s) this PR fixes:

Fixes #2618

Special notes for your reviewer:

Does this PR introduce a user-facing change?

add krel sign blobs and images commands

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[cpanato]

opening as draft to collect early feedback

[cpanato]

/test all

[saschagrunert]

Great start!

[cpanato]

/test all

[cpanato]

Great start!

If I see it correctly, then we need in addition to that:

• A cloudbuild job running krel sign
• The boilerplate in anago to copy the artifacts around

Is krel sign something release managers have to execute manually or do we want to rely on some automation?

I think the idea is to use it as part of the pipeline for the release, maybe @puerco can comment as well, but this was my understanding

Also, I am having trouble using the lib to use in keyless mode, there is anything we need to do? or does that only work if we set up a GCP service account?

also:

• having some trouble to understand what kind of cloudbuild job we need
• and the boilerplate in anago as well

[saschagrunert]

Is krel sign something release managers have to execute manually or do we want to rely on some automation?

I think the idea is to use it as part of the pipeline for the release, maybe @puerco can comment as well, but this was my understanding

So I assume it has to be run manually in the same way we do it with krel stage/release.

Also, I am having trouble using the lib to use in keyless mode, there is anything we need to do? or does that only work if we set up a GCP service account?

Hm, yeah this could be tested via cloudbuild.yaml.

also:

• having some trouble to understand what kind of cloudbuild job we need

Assuming that we run it side by side to krel stage/release, then we have to create a new cloudbuild job in https://github.com/kubernetes/release/tree/master/gcb

• and the boilerplate in anago as well

That's tricky, but we can iterate on it. Krel decides based on the flags if it should submit a cloudbuild job or run the actual logic:

release/cmd/krel/cmd/stage.go

Lines 136 to 143 in ae9fe36

	func runStage(options *anago.StageOptions) error {
	options.NoMock = rootOpts.nomock
	stage := anago.NewStage(options)
	if submitJob {
	return stage.Submit(stream)
	}
	return stage.Run()
	}

[puerco]

@saschagrunert :

So I assume it has to be run manually in the same way we do it with krel stage/release.

No I think we don't need to have it triggered by a release manager, I agree with @cpanato that we should add it as part of the existing pipeline:

the idea is to use it as part of the pipeline for the release

My thinking is that we should sign everything in a step inside the release GCB job. Specifically, I think we should insert it here:

https://github.com/kubernetes/release/blob/master/gcb/release/cloudbuild.yaml#L44

[saschagrunert]

My thinking is that we should sign everything in a step inside the release GCB job. Specifically, I think we should insert it here:

https://github.com/kubernetes/release/blob/master/gcb/release/cloudbuild.yaml#L44

Sounds good, let's do it that way to keep things simple.

[saschagrunert]

@cpanato do you have any update on this change?

[xmudrii]

Great job, @cpanato!!
/lgtm
/approve
/hold
if @saschagrunert wants to take a look, otherwise unhold

[saschagrunert]

Just two nits, otherwise LGTM

[saschagrunert]

/unhold

Thank you @cpanato!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cpanato, saschagrunert, xmudrii

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 [cpanato,saschagrunert,xmudrii]

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

[saschagrunert]

@cpanato do we wanna give this a test run ahead of the next RC?

[cpanato]

yes, can you kick a mock one?

also, i will implement the sign images as a follow up

[saschagrunert]

@cpanato sure

Stage

> go run ./cmd/krel stage --type rc --branch=release-1.26

✔️ https://console.cloud.google.com/cloud-build/builds/3016c99d-2552-47c9-b117-f79cd8927cab?project=648026197307

Release

> go run ./cmd/krel release --type=rc --branch=release-1.26 --build-version=v1.26.0-rc.0.63+f5b5dcadb2b5d4

✔️ https://console.cloud.google.com/cloud-build/builds/f8e81706-f136-4455-a171-9444d37ab446?project=648026197307

Got some errors, fixing them in:

• Fix sign double quotation marks #2776
• Remove _KUBERNETES_GCS_BUCKET from build tags #2777
• Fix missing v for version string in GCS bucket #2778
• Do not sign SHA512SUMS #2779
• fix the len should be of the number of files and not in the arguments passed #2781