cncf / cncf/maintainer-d

replace personal GitHub tokens with a CNCF-owned GitHub App for the sync workloads

Open
#156 0 comments 0 reactions 0 assignees View on GitHub
improvement operations
Dominant language
Go
Stars
9
Forks
10
Avg merge
16h 55m
Merged PRs (30d)
6

Description

#147 fixes the immediate openfga 403 with a fine-grained read-only PAT, but that token is still personal (hangs off one maintainer's account), expires after at most a year, and relies on everything the sync reads being public. The durable fix is a **GitHub App owned by the CNCF org/enterprise**.

**Why an App, and why our enterprise position makes it cheap:**

- **Immune to PAT policies by construction.** The openfga 403 comes from that org's "restrict personal access token access" setting. GitHub Apps aren't PATs, so no org's PAT policy — current or future — can break the sync.
- **Enterprise-central installation.** The orgs the sync monitors are part of the CNCF enterprise account, so the app can be installed across those orgs centrally by an enterprise owner — no per-org approval round-trips, which is normally the painful part of multi-org app adoption.
- **First-class access, not public-read access.** With the app installed on each monitored org, the sync no longer depends on repos being public; it keeps working across visibility changes.
- **Rate-limit headroom multiplies.** Installation tokens are per-org, each with its own budget (scaling on Enterprise Cloud), instead of one shared 5,000/hr pool — directly relevant to the PR-provenance feature's per-line blame/PR/review calls.
- **Institutional credential.** App private key held by the org; installation tokens auto-expire hourly and are minted per run. No personal account in the loop, no annual expiry cliff, no rotation calendar entry.

**Scope of work:**

1. Create the GitHub App under the CNCF org (or enterprise-owned), read-only permissions: Contents, Metadata, Pull requests. No write permissions.
2. Install it centrally on the orgs the sync monitors (enterprise owner action).
3. Code: construct the GitHub client per project org via app auth — resolve the installation for each `git_hub_org` and mint an installation token as the sync iterates (`go-github` apps API + `ghinstallation` transport). Contained to client construction; the sync already knows each project's org.
4. Secret shape changes from a token string to App ID + private key (PEM) — fold into the per-workload secrets layout from #148.
5. Pre-flight: verify GraphQL blame works under an installation token before the provenance path relies on it.
6. Migrate the other sync-family workloads (github-profile-sync, provenance/sanitize) onto the app as part of per-workload least-privilege cleanup.

**Known limitation:** installation tokens cannot use the Gist API, so web-bff gist publishing stays on its own token regardless (same caveat as the PAT plan — see #147).

**Sequencing:** #147's fine-grained PAT ships first as the explicitly interim fix; this app replaces it. When the app lands, close out #147's rotation reminder.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by tracing client construction in the sync workloads and how each project’s git_hub_org and per-workload secrets are supplied. Review the github-profile-sync and provenance/sanitize workloads, then verify GraphQL blame with an installation token before migrating them. Done means the CNCF-owned App is installed on monitored orgs, all applicable sync workloads use per-org installation tokens, and web-bff gist publishing remains on its separate token.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, go
Domain
authentication, backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.