Authorize protected release and channel writes with native OIDC #96
No reviewers
Labels
No labels
app-migration
bug
ci-cd
cluster
Documentation
duplicate
enhancement
gpu
invalid
networking
question
security
Storage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Homelab/workflows!96
Loading…
Reference in a new issue
No description provided.
Delete branch "kiyi/protected-tag-oidc"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Protected tag rules reject the automatic Actions token: release run 624 attempt 2 failed with HTTP 422 for v1.36.1. Release publication and stable-v1 promotion now use separate native Forgejo Authorized Integrations with short-lived, masked OIDC JWTs, restricted to the owning repository. The automatic token remains limited to read-only preflight operations in these publishers. Refs #93.
Both publishers require an approved first-attempt manual dispatch on current protected main. JWT claims bind the exact workflow, repository, ref, source SHA, actor and run. Git uses repository-specific Bearer headers with trusted TLS, redirects/traces disabled and credential helpers cleared; API requests use the existing no-redirect credential transport. Tokens stay in memory and renew before expiry. Existing workflow/job/check names are preserved. The obsolete release urllib mitigation is removed along with its former call site.
The runbook specifies two account-owned integrations, write:repository for Homelab/workflows only, exact workflow filenames/main/workflow_dispatch restrictions, public WORKFLOW_RELEASE_AUDIENCE and WORKFLOW_CHANNEL_AUDIENCE repository variables, and verification that kiyi is permitted by every matching tag rule. Creating these integrations is a separate operator-approved setup step; no account settings, protections, release tags or stable channel were changed by this PR.
Validation: 378 source tests passed (one existing local native Trivy skip), scaffold YAML/Bash checks and 16 mocked scanner cases passed, focused integration/release tests and Ruff passed, native staged Gitleaks 8.30.1 passed. Native Git URL matching used synthetic credentials and no network. Hosted protected writes, canary/promotion/rollback and consumer adoption remain pending.
Source review of
080ffdcfee: the release and channel workflows opt into OIDC but retain the automatic token only for read-only preflight; privileged API/Git operations require distinct repository-scoped Authorized Integrations. The implementation checks manual first-attempt protected-main context, exact JWT job claims, owning-repository push grant, narrow API write paths, HTTPS Git remote and masked in-memory credential renewal. Release publication checks current main and an unused immutable tag; channel publication retains leased atomic stable/audit writes and canary/smoke gates. Added tests cover claim/grant rejection, renewal, remote header matching, release ordering and dispatch transport; the runbook explicitly defers operator grant creation and hosted protected-write acceptance. This is a source-only approval: PR checks were pending at review time, and integration setup, real protected tag writes, promotion/rollback and consumer adoption remain unverified. Do not merge or publish until required exact-head checks and separate operational acceptance pass.CI at submission: pending. This is a source-review approval, not a scan verdict; required checks still block merge.
New commits pushed, approval review dismissed automatically according to repository settings
Inspected kiyi's Authorized Integrations and prepared both restricted local-Actions grant forms without saving. Each draft selects Homelab/workflows as its source and sole permitted repository, exact publish-release.yml or promote-channel.yml, refs/heads/main, workflow_dispatch only, and write:repository only. Existing GitchAlerts integration is untouched; no audience variables or new grants have been saved.
Additional prerequisite verified in the live Bots team UI: kiyi is a member, with Code Write but Releases Read and Actions Read across all repositories. The repository UI exposes no release-creation or manual-dispatch control for kiyi. Native grants authenticate as their owner and need the corresponding unit permissions. Commit
780e09e325documents an operator-owned workflow-publishers team containing only kiyi, limited to Homelab/workflows, with Code/Releases/Actions Write and no admin grant. Existing Bots permissions and tag rules can remain unchanged.gitchegumi can continue dispatching through the existing DEPLOY_ACTORS allowlist; the write credential uses kiyi while provenance retains the human dispatcher. Grant creation awaits explicit access-change confirmation, and team access remains an organization-owner action. The follow-up commit is documentation only: diff checks and native staged Gitleaks passed; the earlier 378-test source validation is unchanged. The PR currently displays failed hosted checks; their logs were not inspected during this settings task.
Source-only review of
780e09e325. Relative to the previously reviewed080ffdcf, this commit changes only docs/workflow-channel.md (+28 lines): it distinguishes the human dispatch actor from the kiyi integration owner and explicitly requires narrowly scoped Code/Releases/Actions Write for that owner, separate from the two workflow- and repository-scoped integration grants. I re-inspected the exact-head publisher workflows, integration code, release/channel paths and tests; no new source or security defect found. This is NOT a CI/security acceptance: all three required exact-head jobs failed before checkout because the runner could not create its pinned job image ('No such image'). Restore/restart the affected runner through an authorized operator and rerun exact-head checks; then investigate any subsequent source/security findings. Integration creation/permissions, protected release writes, canary, promotion/rollback, and consumer adoption are still operationally unverified. Do not merge/publish until required checks and separate operational acceptance pass.CI at submission: failure. This is a source-review approval, not a scan verdict; required checks still block merge.
New commits pushed, approval review dismissed automatically according to repository settings
The owner has now explicitly granted shared Bots Releases Write and Actions Write. I rechecked the live team page: kiyi is a member and Code/Releases/Actions all show Write. This resolves the unit-access prerequisite; a separate publisher team is no longer needed under the owner's chosen arrangement. Commit
73b2380updates the runbook accordingly. Diff checks and staged Gitleaks passed; this is documentation only.Both native integration forms remain prepared but unsaved, restricted separately to publish-release.yml and promote-channel.yml, refs/heads/main, workflow_dispatch, and write:repository for Homelab/workflows only. No new grant, audience variable, tag move or workflow dispatch has occurred. gitchegumi remains an eligible human dispatcher under DEPLOY_ACTORS. Grant creation still awaits explicit confirmation of the final access change.
Source-only review of
73b238046c. I inspected the exact-head changed publisher workflows, integration client, release/channel write paths, tests and runbook. The current runbook replaces the prior proposal for a separate publisher team with the owner-selected shared Bots Code/Releases/Actions Write arrangement, while keeping the two intended Authorized Integrations restricted independently to the exact workflow, protected main, workflow_dispatch, write:repository and Homelab/workflows. The distinct human dispatch actor and kiyi write identity remain explicit. The code retains protected first-attempt dispatch and exact-job JWT checks, read-only automatic-token preflight, constrained Bearer transport, immutable release checks, and leased atomic channel/audit promotion after canary. I found no new source-blocking defect in this head. This is not operational or CI acceptance: exact-head acceptance, security, and library checks are pending; the two integrations and audience variables are not saved, and protected writes, canary, promotion/rollback, and consumer adoption remain unverified. Required checks and separately approved operational setup remain gates; do not merge or publish on this approval alone.CI at submission: pending. This is a source-review approval, not a scan verdict; required checks still block merge.
Operator-approved setup completed on 2026-10-13: saved workflow-release-v1 and workflow-channel-v1 under kiyi. The saved edit pages confirm Homelab/workflows as source and sole permitted repository, exact publish-release.yml / promote-channel.yml, refs/heads/main, workflow_dispatch only, and write:repository only. The integration list shows both entries; the existing GitchAlerts integration is untouched. Bots Code/Releases/Actions Write was already verified after the owner's change.
The generated audiences are PUBLIC configuration, not credentials. Add these as repository Actions variables in Homelab/workflows Settings > Actions > Variables:
Repository Settings are not exposed to kiyi in the UI, so these variables remain an owner step. No standing token, CI secret, tag-rule change, numbered release, channel move or workflow dispatch was created by this setup. gitchegumi can continue dispatching under DEPLOY_ACTORS. After the variables are configured and this PR is reviewed/merged with successful protected-main checks, start fresh publisher/promotion dispatches rather than reruns. Hosted protected writes and channel acceptance remain unverified.