apache / apache/airflow

Gate release-process and secret-using workflows via a protected "release" deployment environment

Open
#69,460 0 comments 0 reactions 1 assignee Claimed by @potiuk View on GitHub
area:CI kind:feature
Dominant language
Python
Stars
46.9k
Forks
17.8k
Avg merge
2d 9h
Merged PRs (30d)
472

Description

### Problem

Manual, release-process-related workflows currently restrict who can trigger them by duplicating a hardcoded release-manager allowlist as an `if:` condition on the first job, e.g.:

```yaml
if: contains(fromJSON('[ "ashb", "bugraoz93", "eladkal", ... ]'), github.event.sender.login)
```

This pattern is spread across several workflows (prod image release, single prod image release, publish docs to S3, and now the constraints-refresh workflow — see #69457). It has real downsides:

- The RM handle list drifts and must be updated in many files independently.
- It only gates the *actor*; it does not scope the *secrets* those workflows consume.
- It is easy to forget on a new workflow, or to get the `event_name` guard subtly wrong.

### Proposal

Introduce a dedicated GitHub Actions **deployment environment** (e.g. `release`) and:

1. Configure it — via `.asf.yaml` (rulesets / environment configuration now supported by ASF INFRA) — so that only release managers can run jobs that reference it, and scope the release/publishing secrets to that environment.
2. Convert **all** workflows that manually dispatch release-process-related workflows, and **all** secret-using workflows, to reference `environment: release`.
3. Remove the per-workflow `if: contains(fromJSON('[...]'), github.event.sender.login)` allowlists — the environment's protection rules become the single source of truth for "who may run this."

### Benefits

- Centralized, auditable access control instead of copy-pasted handle lists.
- Secrets scoped to the environment rather than available to any job in the repo.
- New release workflows opt in with one line (`environment: release`) instead of re-deriving the guard.
- Lets us re-enable zizmor's `secrets-outside-env` audit. It is currently disabled in `.github/zizmor.yml` (`secrets-outside-env: disable: true`) precisely because our secret-using workflows do not run under an environment. Once every secret lives only in the `release` environment, that exclusion can be removed and zizmor will enforce the pattern for all future workflows.

### Scope / acceptance criteria

- [ ] Confirm with ASF INFRA what `.asf.yaml` can express for environment protection rules / required reviewers / actor restrictions.
- [ ] Define and configure the `release` environment (RM-only) and move release/publishing secrets into it.
- [ ] Enumerate and migrate affected workflows: `release_dockerhub_image.yml`, `release_single_dockerhub_image.yml`, `publish-docs-to-s3.yml`, `update-constraints-on-push.yml`, plus any other secret-consuming workflows.
- [ ] Replace the manual `if:` actor allowlists with the environment gate.
- [ ] Remove the `secrets-outside-env: disable: true` exclusion from `.github/zizmor.yml` once all secret-using workflows reference the `release` environment, so the audit enforces it going forward.
- [ ] Document the model in the dev docs.

Prompted by #69457, which had to add yet another manual RM `if:` allowlist that this environment-based approach would replace.

---
Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.