Provision GH Bot secret for SIG Node KEP-board sync Prow job

[alimaazamat]

Overview

Asking for sig-k8s-infra to provision a new Kubernetes Secret named sig-node-kep-wrangler-github-token
in the test-pods namespace of the k8s-infra-prow-build-trusted cluster,
populated with a PAT scoped to public_repo, read:org, project
for the kubernetes org with label group: sig-node.

We'd like the PAT minted from @k8s-infra-ci-robot, matching the existing
pattern used by SIG Release's project-board sync (details below).

Why: reduce KEP-wrangler double-tracking

SIG Node is the largest contributor of KEPs each release cycle. 73% of KEPs for v1.36 were SIG Node KEPs. The
SIG Node KEP Wrangler Program tracks KEPs across two GitHub project boards:

• SIG Release Enhancements Tracking —
  v1.37 Release Tracking (v1.37). Source of truth for release-gate progression (e.g. "Tracked for code freeze", "Removed from milestone").
• SIG Node KEP planning — SIG Node 1.37 KEPs planning (v1.37). SIG-internal board where wranglers self-assign KEPs (theWranglers column) and source the weekly status reports defined in the program's Reporting section.

At SIG Node's KEP volume, wranglers mirror Status, PRR Status, and Stage from SIG Release's board onto SIG Node's board by hand for ~30+ KEPs every week of the cycle. The eventual Prow job this secret is for will automate that mirroring on a 6h cadence. First step is gaining the right authentication for this process.

Why this approach (Prow + per-board PAT secret)

I am copying the pattern SIG Release already uses for the equivalent type of job

Board	Per-board Kubernetes Secret (mounted by Prow job)	Bot identity (linked evidence)
264 — Enhancements Tracking	k8s-release-enhancements-triage-github-token — mounted by periodic-sync-enhancements-github-project-1-37	k8s-infra-ci-robot — AddedToProjectV2Event actor on kubernetes/enhancements#5808
80 — Bug Triage	k8s-release-bug-triage-github-token — mounted by periodic-sync-bug-triage-github-project-beta-1-36	k8s-infra-ci-robot — AddedToProjectV2Event actor on kubernetes/kubernetes#111925
265 — SIG Node KEPs (requested)	sig-node-kep-wrangler-github-token	k8s-infra-ci-robot (proposed)

So a comment on the issues show "k8s-ci-robot removed this from the v1.34 milestone on Sep 19, 2025" and "k8s-infra-ci-robot
added this to [sig-release] Bug Triageon Sep 19, 2023" which proves the bot identity

The 264 sync is wired up here:
https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/sig-k8s-infra/trusted/sig-release-release-team-jobs/release-team-periodics.yaml#L30-L37

So we're asking to be another instance of the above, where sig-k8s-infra's bot k8s-infra-ci-robot will include SIG Node's board. This way each SIG has its own isolation and scope and upholds this existing pattern.

Future direction

This ask for the future prow job is intentionally minimal for right now. Current plans for the prow job is a one-way sync of three fields (Status, PRR Status, Stage) from 264 (v1.37 Release Tracking) → 265 (SIG Node 1.37 KEPs planning). The future next steps are:

1. Cross-field validation, not just mirroring. Detect KEPs where SIG
   Node's view and SIG Release's view have drifted in ways the mirror doesn't catch, like an issue is in "In Progress" on 265 but "Removed from milestone" on 264. Maybe this would be some sort of notification (issue comment) rather than an auto-edit.

2. Additional metadata fields. The current mapping covers just the three fields wranglers ask about most.

3. Possible Bi-directional sync. If there are signals SIG Node can provide the release team. We can discuss after first prow job version goes out.

4. SIG generalization. Other SIGs that maintain their own KEP-tracking boards (SIG Auth, SIG Network, SIG Storage all have similar) could adopt the same job .

None of these are in scope for the this current issue, it is just added so reviewers have context on where this is headed and so the secret-naming choice (sig-node-kep-wrangler-github-token, scoped to the wrangler usecase rather than to one job) makes sense for the future direction.

PTAL and let SIG Node know if this request could go through so we can implement the prow job for this.

Afterwards, a SIG Node lead with admin on SIG Node 1.37 KEPs planning will add @k8s-infra-ci-robot as a project admin so the periodic can write the field values.

Related

• SIG Node KEP Wrangler Program: https://github.com/kubernetes/community/blob/master/sig-node/sig-node-kep-wrangler-program.md
• Most relevant prev issue: REQUEST: Generate a new GITHUB_TOKEN for Prow tasks running on the GitHub Project Beta board.  org#3558
• SIG Node KEP-board sync job PR: TBD based on this request
• Slack discussion (#sig-release): https://kubernetes.slack.com/archives/C2C40FMNF/p1779227104399409
• sig-release k8s-infra-ci-robot source REQUEST: Generate a new GITHUB_TOKEN for Prow tasks running on the GitHub Project Beta board.  org#3558 (comment)

cc @haircommander @SergeyKanzhelev (SIG Node leads)

[alimaazamat]

/sig k8s-infra
/sig node
/area prow
/kind feature

[alimaazamat]

If I get feedback that this is the right direction I am willing to open PR for the terraform or help with any other components (other than the manual PAT for whoever has access to the k8s-infra-ci-robot).

[alimaazamat]

/assign

[haircommander]

I like this direction and I'm excited about the potential! good work @alimaazamat

[ameukam]

👋🏾
We probably to want to get those PAT from a different bot (k8s-triage-robot ?) rather than use @k8s-infra-ci-robot. I'll look into what can be done.

[alimaazamat]

@ameukam I see in kubernetes/org#3558 that there was a discussion to move to github actions rather than Prow + PAT. But currently today its still PAT: the secret is still synced into the trusted cluster and mounted into the active Prow job, and k8s-infra-ci-robot is still the actor on recent project events

Is this the correct approach still?

[alimaazamat]

Okay after this discussion: https://kubernetes.slack.com/archives/C01672LSZL0/p1780618698683699
I think we are good to go with the PAT+Prow route.
A bot mints PAT which is backed into a k8s secret read in prow job as a GITHUB_TOKEN.
So need to discuss which bot to use and if a new secret is needed or if we should reuse. If we reuse a secret, the token behind it needs to have Project access for 264 read (sig release) and 265 write (sig node).