security: tighten cosign subject matchers at the image-verification layer #2815

Activity

1. devantler

   added the

   Security

   issue type on Jul 26, 2026
2. github-project-automation

   added this to 🌊 Project Boardon Jul 26, 2026
3. coderabbitai commented on Jul 26, 2026

   

   coderabbitaiBot

   on Jul 26, 2026 – with coderabbitai

   Contributor

   More actions

   🔗 Related PRs

   #2382 - fix(policies): accept the provider publish-workflow cosign identity in verify-app-images [merged]
   #2399 - feat: accept devantler-tech/actions cosign subjects during the publish-workflow repoint [merged]
   #2404 - fix: tenant artifact verification rejects the dual signing identities from #2399 [merged]
   #2457 - fix(talos): accept the actions publish-app identity at node image verification [merged]
   #2633 - fix(deploy): verify incoming image on Talos nodes [merged]

   ---

   📝 Issue Planner

   _{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

   • Create Plan

   ---

   🧪 Issue enrichment is currently in open beta.

   You can configure auto-planning by selecting labels in the issue_enrichment configuration.

   To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

   issue_enrichment:
     auto_enrich:
       enabled: false

   💬 Have feedback or questions? Drop into our discord!
4. devantler

   moved this to 📥 Backlog in 🌊 Project Boardon Jul 26, 2026
5. devantler

   self-assigned this

   on Jul 29, 2026
6. devantler

   marked this as blocked on Jul 29, 2026

   • First-party image pull verification does not block an unsigned first-party image #2856
7. devantler commented on Jul 29, 2026

   

   devantler

   on Jul 29, 2026

   ContributorAuthor

   More actions

   🤖 Generated by the Agentic Engineer

   Evidence gathered, and a blocker found — releasing this claim

   I picked this up, ran the evidence step, and am handing it back unstarted because step 1 cannot be completed with the access this host has, and because a finding surfaced that changes the premise.

   Which first-party images are actually running (five families):

   Family	Rule it matches	Current matcher
   ksail	ksail rule	already tight (cd.yaml@refs/tags/v.+)
   provider-upjet-unifi	provider rule	floating @.+
   wedding-app, ascoachingogvaner, doggy-countdown	catch-all	floating @.+ and the dead (actions|reusable-workflows) alternation

   Step 1 is blocked for two of the three app families. wedding-app and ascoachingogvaner are private packages: GHCR refuses an anonymous pull token, and this host's PAT has no read:packages, exactly as this issue predicted. Their signing certificates therefore cannot be read, so the per-image evidence acceptance criterion cannot be met for them. This is a credential-scope blocker, not a design question — the narrowing itself is straightforward once the evidence exists.

   And the premise needs re-checking first. The one app package that is public, doggy-countdown, turns out to carry no cosign signature at all while running normally — filed as #2856, now linked as blocking this issue. That matters here specifically: this issue's plan assumes every running first-party image satisfies the current rule and that the only question is how much to narrow it. For at least one family that assumption does not hold, so narrowing would tighten a rule whose enforcement is itself unconfirmed.

   Suggested sequencing, unchanged in substance from the plan above but with one step in front of it:

   1. First-party image pull verification does not block an unsigned first-party image #2856 — establish whether the rules enforce at all, and why an unsigned image pulls.
   2. Obtain read:packages (or run the evidence step somewhere that has it) for the private families.
   3. Then narrow, in the order this issue already sets out.

   Unassigning myself and deleting the claim branch so this is not parked behind a lease I am not working. The provider-upjet-unifi rule is the one family whose narrowing might be separable, since its signing workflow is per-repo — but it is a Crossplane package rather than an app, and its pinned-ref convention still needs confirming, which the same access limit blocks.
8. devantler

   removed their assignment

   on Jul 29, 2026
9. devantler commented on Aug 4, 2026

   

   devantler

   on Aug 4, 2026

   ContributorAuthor

   More actions

   🤖 Generated by the Agentic Engineer

   Re-verified this issue's blocker against live state rather than inheriting it, and it still stands.

   Criterion 3 (per-image evidence read from real signatures) is blocked on a token permission. The
   host credential cannot reach the packages API at all:

   GET /orgs/devantler-tech/packages?package_type=container
   403 Resource not accessible by personal access token
   

   So the GHCR-manifest → sigstore-bundle → openssl x509 route this issue specifies cannot be run from
   an unattended tick. Narrowing the matchers without that evidence is exactly what the issue forbids —
   and the in-file comment records that guessing here already caused ImagePullBackOff once.

   Criterion 4 (no workload enters ImagePullBackOff, checked live) additionally needs a watched
   window. A scheduled run is not one, for the same reason the probe activation on #2651 is held back:
   the failure mode is cluster-wide and needs someone watching it.

   Unblocking is a maintainer act — granting the host credential read:packages (or an equivalent
   fine-grained packages permission). I have not self-widened anything.

   Leaving this unassigned and actionable-once-unblocked rather than parking it silently.
10. devantler

    self-assigned this

    on Aug 5, 2026
11. github-project-automation

    moved this from 📥 Backlog to 👀 In Review in 🌊 Project Boardon Aug 5, 2026
12. devantler

    closed this as completedin #2964on Aug 5, 2026
13. github-project-automation

    moved this from 👀 In Review to ✅ Done in 🌊 Project Boardon Aug 5, 2026