search

kubewarden / kubewarden-controller

Manage admission policies in your Kubernetes cluster with ease
https://kubewarden.io
Apache License 2.0
195 stars 33 forks source link

SPIKE: Ensure SLSA lvl 3 for policies #910

Closed viccuad closed 4 weeks ago

viccuad commented 1 month ago

Acceptance criteria

  1. Make sure SLSA Lvl 3 is needed.
  2. Implement if so.
  3. Understand and document how many changes are needed to kubewarden/github-actions reusable workflows, as refactoring these means changing the build and release process of our policy repositories.
viccuad commented 4 weeks ago

To achieve this card we need:

1. Add permissions.attestations: write to all policy workflows

This is so they can use the attestations on the reusable workflows. E.g: here.

2. All the workflows and GHA need to be uniquely identified

This is done by digest pinning of the versions of GH actions. We can achieve this for 3rd party actions. For our own actions in kubewarden/github-actions, it isn't as easy.

Problem is, that all the GH actions that we use should have the correct digest pinned before we tag. This is impossible as we can't know the commit sha that the release should point to because it would be the commit that changes the release pointers on the actions.

Using branches for release management https://docs.github.com/en/actions/sharing-automations/creating-actions/about-custom-actions#using-a-commits-sha-for-release-management solves the problem partially. Yet I wonder how renovatebot behaves, as I think it would try to continuously update the pin of the GHA by opening PRs. The moment one merges the PR into the branch, renovatebot would open PRs to update the pins again.

One solution here would be to not reuse actions, and only provide flattened reusable workflows.

Note: some GHA are not consuming checked binaries. For example, the "Install tinygo" step that downloads tinygo, which is provided as-si without signatures.

3. The build artifact needs to be uniquely identified

In this case, since we push the artifact to the OCI registry, that means we need to ahve the digest of the pushed policy. This can be done by refactoring and including the policy-release action into the reusable workflow, since kwctl push prints the digest.

viccuad commented 4 weeks ago

First approach at https://github.com/kubewarden/github-actions/compare/main...viccuad:github-actions:slsa.

flavio commented 4 weeks ago

Thanks for the research, we need to spend some time discussing how to move forward with that. It's nice to know we don't have to make all our policies SLSA L3 yet

viccuad commented 4 weeks ago

I'm closing the spike as done.