Least-privilege `GITHUB_TOKEN` permissions

[atimin]

Tracking parent: https://github.com/reductstore/security/issues/16
Migrated from: https://github.com/reductstore/security/issues/25

Scope

Apply least-privilege GITHUB_TOKEN permissions in this repository's GitHub Actions workflows.

Actions

• Inventory all workflow files under .github/workflows/ and identify jobs that require write or OIDC access.
• Set workflow-level default permissions to read-only (read-all or contents: read).
• Remove broad top-level permissions (id-token: write, contents: write) unless strictly required.
• Add per-job permissions: only where needed:
  • release/publish jobs: minimum required writes (for example contents: write)
  • OIDC jobs only: id-token: write
  • test/build/lint jobs: read-only token
• Validate that PR/test workflows still pass and release/publish flows still work.

Evidence

• Link PR(s) that implement the change.
• Brief before/after summary of permissions scope in workflow files.

Done when

• GITHUB_TOKEN scope is least-privilege by default and elevated only in required jobs.
• Parent tracking issue includes link to implementation PR(s).

[mother-6000]

Implementation plan drafted — please review:
@reductstore/maintainers @reductstore/devops

Summary

Issue #121 requests least-privilege GITHUB_TOKEN permissions across this repo’s GitHub Actions workflows. The target state is read-only defaults with scoped write/OIDC permissions only for jobs that truly require them.

Scope

In scope

• .github/workflows/*.yml permissions hardening
• Workflow/job-level permissions: alignment with actual job responsibilities
• Validation that CI and release workflows still function under tightened permissions

Out of scope

• Non-permissions workflow redesign
• Secrets rotation or environment/repository settings changes outside workflow YAML
• Changes in other repositories (tracked separately)

Proposed changes

1. Inventory all workflow files under .github/workflows/ and classify each job by required token access (read-only, write, OIDC).
2. Set conservative workflow-level defaults (permissions: read-all or minimal equivalent).
3. Remove broad top-level write/OIDC permissions where not strictly needed.
4. Add explicit per-job permissions: for exceptions only:
   • release/publish/upload jobs: minimum writes (for example contents: write only when needed)
   • OIDC-authenticated jobs: id-token: write only
   • test/lint/build jobs: read-only token permissions
5. Verify reusable/composite-action interactions still have required scopes.
6. Prepare a before/after summary of permission reductions for PR description and issue follow-up.

Testing strategy

• Run formatting/lint checks required by repo conventions.
• Run automated tests/CI workflows affected by permissions changes.
• For release-oriented workflows, validate syntax and required scopes (and dry-run where practical) to ensure no missing permission regressions.
• Confirm PR checks execute successfully with least-privilege defaults.

Risks & mitigations

• Risk: Over-tightening breaks release or automation jobs.
  Mitigation: Audit each job capability before change; grant narrowly scoped per-job permissions only where required.
• Risk: Hidden permission dependencies in third-party actions.
  Mitigation: Review action docs and CI failures; adjust with minimal additional scopes.
• Risk: Inconsistent permission style across workflows.
  Mitigation: Apply one consistent baseline and document rationale in PR notes.

Timeline / checkpoints

• Audit + plan confirmation: complete.
• Workflow permission edits: ~30–60 minutes.
• Validation and PR prep: ~30–45 minutes.

If approved, I’ll proceed with implementation on a fresh branch from the latest default branch commit and open a PR linked back to this plan.

[mother-6000]

Gentle follow-up on the implementation plan above — could someone confirm approval when convenient so I can proceed?\n\n@reductstore/maintainers @reductstore/devops

[mother-6000]

Second follow-up on the implementation plan above — still awaiting explicit approval before I start coding, per workflow.

If the plan looks good, please reply with approval (or apply a plan-approved/ready-for-dev label), and I’ll proceed immediately.

@reductstore/maintainers @reductstore/devops

[atimin]

approved