feat: add container image provenance attestation to shared workflow

[Varadraj75]

Overview

Adds actions/attest-build-provenance to the shared incluster-comp-pr-merged.yaml workflow so all components using it get SLSA provenance attestation on every release. This is the follow-up to kubescape/kubescape#2346 which added binary attestation to the CLI release workflow.

Components covered by this single change:

• operator
• kubevuln
• storage
• node-agent
• synchronizer
• http-request
• prometheus-exporter

The image digest is captured from the build-push step and attested using subject-digest for accurate per-digest attestation. The attestation is pushed to the registry alongside the image.

Users can verify any released image with:

gh attestation verify --owner kubescape oci://quay.io/kubescape/<component>:<tag>

Additional Information

Also adds attestations: write permission to the docker-build job as required by the action.

Related issues/PRs

• Part of #1033 (kubescape/kubescape)
• Follow-up to feat: add SLSA build provenance attestation to release workflow kubescape#2346

Checklist before requesting a review

• My code follows the style guidelines of this project
• I have commented on my code, particularly in hard-to-understand areas
• I have performed a self-review of my code
• New and existing unit tests pass locally with my changes

Summary by CodeRabbit

• Chores
  • CI Docker build/push now publishes image provenance attestations to the registry, tying attestations to the built image and enabling registry-side verification before signing. Permissions and workflow steps were updated to support attestation publishing, improving artifact verification and supply-chain security.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: c19a5f14-c673-45f7-8183-0e0d9598678e

📥 Commits

Reviewing files that changed from the base of the PR and between 1a97874 and 8d057e5.

📒 Files selected for processing (1)

• .github/workflows/incluster-comp-pr-merged.yaml

🚧 Files skipped from review as they are similar to previous changes (1)

• .github/workflows/incluster-comp-pr-merged.yaml

---

📝 Walkthrough

Walkthrough

The workflow grants attestations: write to the docker-build job, assigns id: build to the Docker build/push step to expose its digest output, and adds an actions/attest step that publishes a provenance attestation to the registry using that digest.

Changes

Image Provenance Attestation

Layer / File(s)	Summary
Image provenance attestation setup .github/workflows/incluster-comp-pr-merged.yaml	The docker-build job receives attestations: write permission, the build-and-push step is assigned id: build to expose its outputs.digest, and a new step using actions/attest publishes image provenance to the registry with subject-digest sourced from the build step output.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Suggested reviewers

• Naor-Armo

Poem

🐰 A tiny hop, a digest found,
I trace the build from ground to ground,
An attestation stitched in place,
The registry knows each little trace,
Hooray — provenance leaves a happy trace!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: adding container image provenance attestation functionality to a shared workflow.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR updates the GitHub Actions workflow that builds and pushes the container image to also generate and publish a build provenance attestation for the produced image.

Changes:

• Adds attestations: write workflow permission to allow publishing build attestations.
• Adds a step id: build so the image digest output can be referenced later.
• Adds an “Attest image provenance” step using actions/attest-build-provenance.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[matthyx]

Reviewed the provenance-attestation change. The approach (capture digest from build-push, attest per-digest, push to registry) is sound and the action is correctly SHA-pinned. I found one blocking issue and one thing to verify before this can be merged/run — details inline.

[matthyx]

Blocker: subject-name must not include a tag when push-to-registry: true.

With push-to-registry: true, the attest-build-provenance docs are explicit:

it is important that the subject-name specify the fully-qualified image name (e.g. ghcr.io/user/app). Do NOT include a tag as part of the image name — the specific image being attested is identified by the supplied digest.

Here subject-name is ${{ inputs.IMAGE_NAME }}:${{ steps.image-prerelease-tag.outputs.IMAGE_TAG_PRERELEASE }}, which appends the -prerelease tag. The action will fail when it tries to push the attestation to the registry (the OCI reference is built from subject-name + the digest, and a tagged name is rejected).

Fix:

subject-name: ${{ inputs.IMAGE_NAME }}

The digest in subject-digest already uniquely identifies the image, so dropping the tag is correct.

[Varadraj75]

Fixed, removed the tag from subject-name. The digest in subject-digest already uniquely identifies the image so the tag is not needed.

[matthyx]

Verify caller permissions — attestations: write may not take effect here.

This is a reusable workflow (workflow_call). For reusable workflows the GITHUB_TOKEN permissions are capped by the caller: a permissions: block in the called workflow can only narrow what the caller grants, never widen it. So adding attestations: write here only has an effect if every caller (operator, kubevuln, storage, node-agent, synchronizer, http-request, prometheus-exporter) also grants attestations: write on the job that does uses: this workflow.

If a caller doesn't grant it, the attest step fails with a 403 when persisting the attestation to the GitHub attestations API — and it would only surface on a real release-labeled run, not in this PR's checks.

Please confirm the callers already grant attestations: write (same way they must already grant id-token: write for keyless cosign), or update them alongside this change.

[Varadraj75]

Checked all 7 callers, none of them currently grant attestations: write. Will add it to all of them. Also noticed node-agent uses a local copy of the workflow instead of the shared one so it will need a separate update. Should I open separate PRs per repo or is there a preferred way to batch them?

[matthyx]

Should I open separate PRs per repo or is there a preferred way to batch them?

I don't think there's a way... just open separate PRs in each repo as needed. Thanks.

[matthyx]

Thanks for the fix — the subject-name blocker is resolved in bca2019 (now ${{ inputs.IMAGE_NAME }} with no tag, which is correct for push-to-registry: true). No code blockers remain in this file.

One thing still worth confirming before a release run (following up on my earlier inline note): since this is a reusable (workflow_call) workflow, the new attestations: write permission only takes effect if each caller also grants it. Reusable-workflow token permissions are capped by the caller — a permissions: block here can only narrow, never widen, what the calling workflow provides.

So please verify the workflows that call this one (operator, kubevuln, storage, node-agent, synchronizer, http-request, prometheus-exporter) grant attestations: write on the job that does uses: this workflow — same as they must already grant id-token: write for keyless signing. If a caller doesn't, the attest step will 403 when persisting the attestation, and it would only surface on a real release-labeled run rather than in this PR's checks.

[Varadraj75]

Confirmed, none of the 7 callers currently grant attestations: write. Will open separate PRs for each repo to add it.

[Varadraj75]

Updated to actions/attest@v4.1.0 (SHA-pinned) as suggested by @scop , attest-build-provenance v4+ delegates to actions/attest anyway so this uses the correct action directly.