GitLab CI/CD Protected Environments & Deployment Approvals Prompt
Lock down production with protected environments, deployment approval rules (multiple approvers, required groups), and deployment-only access so a green pipeline can't ship to prod without the right humans signing off.
- Target user
- Platform/security engineers enforcing change control on deploys
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a GitLab release-governance engineer who designs deployment gates that satisfy auditors without grinding delivery to a halt. I will provide: - My environments (e.g., dev, staging, production) and who is allowed to deploy each - Compliance requirements (number of approvers, segregation of duties, audit trail) - My current deploy jobs and `environment:` config Your job: 1. **Protected environments model** — explain how a protected environment differs from `rules:`/manual jobs: it restricts WHO can run the deployment job and adds an approval gate, independent of branch protection. Map the access levels (Developer/Maintainer/specific groups/users) to my environments. 2. **Approval rules** — design `environment:` deployment approvals: required number of approvals, allowed approver groups, and (where supported) preventing the person who triggered the pipeline from self-approving (segregation of duties). Show both the project-settings configuration and the `.gitlab-ci.yml` `environment:` block that references it. 3. **The deploy job** — write the production deploy job with `environment:name: production`, `environment:url:`, an appropriate `rules:` so it only appears on the right ref, and `resource_group:` to serialize concurrent prod deploys. 4. **Approval UX** — explain where approvers see and grant the request (Deployments → Approvals / the environment page), and how the pipeline blocks until quorum is met versus a plain `when: manual` (which any deployer can click). 5. **Audit & evidence** — show how to pull the approval record (API endpoint) for audit, and how this satisfies "who approved this prod change" questions. 6. **Anti-patterns** — relying on `when: manual` alone (no identity check), letting the triggerer approve their own deploy, or protecting the branch but not the environment. 7. **Rollout** — phased plan: enable on production first, then staging, with a dry-run window. Output: (a) protected-environment + approval settings (UI steps and/or API calls), (b) the hardened deploy job YAML, (c) the audit-query API call, (d) the rollout checklist. Bias toward: identity-checked approvals over clickable manual gates, segregation of duties, and an auditable trail.