ci: move secrets to dedicated GitHub environments

[vdemeester]

Problem

zizmor reports 12 instances of secrets-outside-env across our GitHub Actions workflows. Secrets are accessed without a dedicated GitHub environment, which means any workflow run can access them without additional protection gates.

What GitHub environments bring

Using dedicated environments provides several security layers that repository-level secrets don't:

• Required reviewers — a designated set of people must manually approve before a job can access the environment's secrets. This creates a human gate before sensitive credentials (e.g. OCI keys, GHCR tokens) are exposed to a workflow run.
• Wait timer — configurable delay (1 min to 30 days) before a job proceeds, giving time to review or cancel unexpected runs.
• Deployment branch/tag restrictions — limit which branches can access secrets. For example, release secrets could be restricted to main and release-* branches only, preventing feature branches or forks from ever accessing production credentials.
• Environment-scoped secrets — secrets are only available to jobs that explicitly declare environment: <name>. This means a compromised or misconfigured workflow that doesn't target the right environment simply cannot access those secrets.
• Audit trail — GitHub tracks deployment history per environment, providing visibility into which runs accessed which credentials and when.

Without environments, all repository-level secrets are available to every workflow run on every branch, which is a broader attack surface than necessary.

Affected workflows and secrets

Workflow	Secret(s)	Suggested environment
e2e-matrix-extras.yaml	CHATOPS_TOKEN (x2)	ci
go-coverage.yml	CHATOPS_TOKEN	ci
slash.yml	CHATOPS_TOKEN	ci
nightly-builds.yaml	GHCR_TOKEN (x2), OCI_API_KEY, OCI_FINGERPRINT, OCI_TENANCY_OCID, OCI_USER_OCID, OCI_REGION	release
scorecard.yml	SCORECARD_TOKEN	ci

Proposed solution

1. Create GitHub environments (e.g. ci, release) in the repo settings
2. Move the respective secrets to those environments
3. Add environment: to the jobs that use them:

jobs:
  build:
    environment: release
    runs-on: ubuntu-latest
    steps: ...

4. Configure protection rules:
   • ci: no required reviewers, branch restrictions as appropriate
   • release: no required reviewers (see note below), restrict to main and release-* branches

Note on nightly builds

The nightly-builds.yaml workflow runs on a schedule trigger (cron, 03:00 UTC daily). Adding required reviewers to the release environment would block these automated runs since there's nobody to approve at that time, and GitHub doesn't support conditional protection rules per trigger type.

The release environment should therefore be configured without required reviewers. The security value is still significant: secrets are scoped to the environment (not available to all workflows), branch restrictions ensure only main can access them, and the audit trail provides visibility into which runs accessed credentials.

Context

This was identified by running zizmor v1.23.1 static analysis. The auto-fixable findings are addressed in #9667. This issue tracks the remaining secrets-outside-env findings which require repo admin access and org-level coordination.

/kind cleanup