Generate SBOM and sign release artefacts

[richardcase]

/kind feature
/area release
/area security
/help
/priority important-soon
/triage accepted

Describe the solution you'd like
We should be generating a SBOM for CAPA and also signing this and any other release artefacts.

Anything else you would like to add:
We should probably use sigstore

Environment:

• Cluster-api-provider-aws version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

[k8s-ci-robot]

@richardcase:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/kind feature
/area release
/area security
/help
/priority important-soon
/triage accepted

Describe the solution you'd like
We should be generating a SBOM for CAPA and also signing this and any other release artefacts.

Anything else you would like to add:
We should probably use sigstore

Environment:

• Cluster-api-provider-aws version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

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.

[sedefsavas]

Do you have any example how other projects in Kubernetes ecosystem does this?

[richardcase]

We use it in FluxCD

[sedefsavas]

Relevant to this, there is an effort going on in K8s kubernetes/release#2383

Looks like sigstore is being used there: https://github.com/kubernetes/website/pull/31610/files

[sedefsavas]

Might worth to come up with a common workflow for cluster-api and other providers too.

[richardcase]

Might worth to come up with a common workflow for cluster-api and other providers too.

I agree @sedefsavas . We'll probably have to make changes to image-builder / the image promoter stuff which would touch all the providers (probably)

[sedefsavas]

There is a nice TGIK talk about what's being done in Kubernetes about this: https://www.youtube.com/watch?v=H1D0fk9sZ8I

[puerco]

Hey I just saw this issue referenced in SIG Release, I'm happy to help out!

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[richardcase]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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.

[richardcase]

This is important for the future, so

/reopen

[k8s-ci-robot]

@richardcase: Reopened this issue.

In response to this:

This is important for the future, so

/reopen

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.

[flxw]

Hi @richardcase ,
I could help with this one. Would you be ok with using the public sigstore?
That would allow you to have publicly verifiable signatures without key management.
How do you create your releases? I quickly checked the workflows, but couldn't find any dedicated workflow for that.

I'd like to split the SBOM generation ticket into a separate issue because we can take care of that easily once Sigstore is in place.
What do you think?

[sbueringer]

I wonder if there is already infrastructure in place in the kubernetes community that we can just use?

e.g. I noticed that our container images are already signed because signing was added to the Kubernetes image promotion process.

[flxw]

I wonder if there is already infrastructure in place in the kubernetes community that we can just use?

e.g. I noticed that our container images are already signed because signing was added to the Kubernetes image promotion process.

I think you are referring to this, right? That's the same mechanism I would love to use :)

[sbueringer]

Ah perfect. Thx for the info, I"m not really familar with how it works :)

[flxw]

/assign @flxw

[flxw]

@sedefsavas - I saw that your name is on most of the releases. Could you kindly give me context on how those are authored? I couldn't find a Github Actions workflow that created the release, so I am assuming it's manual?
My idea is to add a step for SBOM generation and upload into the Sigstore infrastructure into the release process.
Looking forward to your answer!

[richardcase]

@sedefsavas - I saw that your name is on most of the releases. Could you kindly give me context on how those are authored? I couldn't find a Github Actions workflow that created the release, so I am assuming it's manual? My idea is to add a step for SBOM generation and upload into the Sigstore infrastructure into the release process. Looking forward to your answer!

@flxw - we follow these steps when doing a release: https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/docs/book/src/development/releasing.md

So manual with some automation.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.

[richardcase]

/reopen

[k8s-ci-robot]

@richardcase: Reopened this issue.

In response to this:

/reopen

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.

[flxw]

Hi! My apologies for the long lead time, but I finally got around to making some time for this.
This exemplary commit integrates cosign into the Makefile, adding a separate release-signed step.
While it's totally possible to execute this manually on a local machine, I would recommend implementing this as a Github Action. These have an OIDC provider that gives us provenance information for free. This information will be engraved into Sigstore during the signing process.

c340edb

However, I've also seen that there is a larger movement for Kubernetes artifact signing underway:
kubernetes/enhancements#3031

I'll link up with the people on that issue, as I hope to solve this a bit more elegantly and with benefits for the other projects.
What do you think?

[richardcase]

Thanks for the update @flxw.

It would be good to be aligned with the wider Kubernetes community effort on artifact signing.

[furkatgofurov7]

Hey!

We have a similar tracking issue in CAPI to have this in place, and +1 from my side to have a common workflow for it. But going through the discussion quickly, it seems to me only the signing part of the SBoM was discussed, however how about the SBoM generation itself?
We had a quick chat earlier with @cpanato and got to know, the upstream k8s community uses https://github.com/kubernetes-sigs/bom to generate it, so perhaps that is the workflow we could follow for SBoM generation.

[richardcase]

@furkatgofurov7 - thanks for input and the link to the k8s community bom is really helpful.

[k8s-triage-robot]

This issue is labeled with priority/important-soon but has not been updated in over 90 days, and should be re-triaged.
Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Deprioritize it with /priority important-longterm or /priority backlog
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[furkatgofurov7]

This is still relevant, so

/triage accepted

@flxw hi!

However, I've also seen that there is a larger movement for Kubernetes artifact signing underway: kubernetes/enhancements#3031

I'll link up with the people on that issue, as I hope to solve this a bit more elegantly and with benefits for the other projects. What do you think?

Just wanted to check on the status of this work since this is needed not only in CAPA but in CAPI also.
As I checked kubernetes/enhancements#3031 is almost near finishing line (KEP + code + docs merged) and in the Beta status and not planned for graduating in 1.28 k8s release, but the only item open I see is kubernetes/release#2286 where the discussion is ongoing (TL;DR sign SBOM after generation with bom tool using cosign).

Would be great to hear your and others opinion on this one, and probably we can already start laying a foundation for the SBOM generation using the bom tool to start with and later improve it with cosign. Thoughts?

[richardcase]

@furkatgofurov7 - this would be good to discuss at the next CAPA office hours.

[richardcase]

/remove-lifecycle rotten

[furkatgofurov7]

@furkatgofurov7 - this would be good to discuss at the next CAPA office hours.

@richardcase sure, I will try to make it to the upcoming office hours.

[k8s-triage-robot]

This issue is labeled with priority/important-soon but has not been updated in over 90 days, and should be re-triaged.
Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Deprioritize it with /priority important-longterm or /priority backlog
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted