Tech debt: minimise permissions on `ui-plugin-examples` github workflows

[aalves08]

Is your feature request related to a problem? Please describe.

As a measure of security hardening, minimise permissions on ui-plugin-examples github workflows

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[github-actions]

🎯 Agentic Issue Triage

Summary: This is a security hardening tech-debt task to apply the principle of least privilege to the GitHub Actions workflows in the rancher/ui-plugin-examples repository, reducing their default overly-broad permissions.

---

📋 Issue Analysis

Field	Value
Type	Tech debt / Security hardening
Area	Extensions (ui-plugin-examples)
Priority	1 (High)
Related Issue	#17506 — same task for ui-plugin-charts workflows

GitHub Actions workflows default to GITHUB_TOKEN permissions that may be broader than necessary. Without explicit permissions: declarations, workflows may have write access to contents, pull requests, issues, etc. that they don't actually need — which is a supply-chain attack risk.

🔍 Related Issues & Context

• Tech debt: Minimise permissions on ui-plugin-charts github workflows #17506 — Tech debt: Minimise permissions on ui-plugin-charts github workflows (same effort, different repo — already has a triage comment worth referencing for approach consistency)

This appears to be part of a broader security hardening initiative across the Rancher extensions ecosystem, targeting multiple repos (ui-plugin-charts, ui-plugin-examples, and potentially others).

🛠️ Implementation Guidance

Approach

1. Audit existing workflows in rancher/ui-plugin-examples/.github/workflows/ to list all workflows and their current (implicit) permissions.

2. Determine minimum required permissions for each workflow:

   • Workflows that only read code → contents: read
   • Workflows that publish releases/packages → contents: write (only for those jobs)
   • Workflows that comment on PRs → pull-requests: write
   • Workflows that push to registries → packages: write
   • Workflows that deploy pages → pages: write, id-token: write

3. Add top-level defaults to each workflow file:

   permissions: read-all

   Then add job-level overrides with only the permissions that specific job actually needs.

4. Use job-level scoping where different jobs need different permissions, rather than granting broad permissions at the workflow level.

Key GitHub Docs

• Workflow syntax: permissions
• Automatic token authentication
• Security hardening for GitHub Actions

✅ Sub-task Checklist

• List all workflow files in rancher/ui-plugin-examples/.github/workflows/
• For each workflow, identify all actions/steps that use GITHUB_TOKEN
• Map each usage to the minimum required permission scope
• Add permissions: read-all at the workflow top-level as a default
• Add job-level permissions: overrides where write access is needed
• Verify workflows still pass after permission changes (no unexpected 403s)
• Ensure consistency with the approach used in Tech debt: Minimise permissions on ui-plugin-charts github workflows #17506 (ui-plugin-charts)

💡 Tips & Pitfalls

• Setting any permissions key at the top level (even for just one scope) sets all other scopes to none — be thorough.
• The actions: read permission is often needed for workflows that download artifacts from other workflows.
• id-token: write is required for OIDC-based cloud deployments (e.g., AWS, GCP, Azure).
• Review both push and pull_request triggered workflows — PR workflows from forks already run with limited permissions, but explicit declarations are still good practice.
• Use StepSecurity's Harden-Runner or Scorecard for automated auditing.

Generated by Agentic Triage for issue #17507 · ● 190.7K · ◷