Who can unlock prod? A deploy approvals checklist

26.08.20263 min readAtalaia team

Ask a team who can deploy to production and the answer is usually "only through the pipeline, with approval". Ask who can approve, who can change the pipeline and who can reach the production credentials without it, and the answer gets longer.

A deploy approval is a control only if it cannot be skipped and the approver is independent of the change. This checklist uses GitHub environments as the example, but the questions apply to any CI/CD system.

The principle: separation of duties

Separation of duties means no single person can take a change from idea to production alone. In a pipeline that comes down to three separations:

1. WriteAn engineer authors the change and opens a pull request.
2. ReviewA different engineer approves the code before it merges.
3. ReleaseA required reviewer, other than the person who triggered the run, approves the production deployment.
4. DeployThe pipeline, not a person, uses credentials that only exist inside the production environment.

If any one person can perform two of those steps alone, or skip one, the approval is ceremony. The checklist is about finding where that happens.

This is not only an audit concern. Separation of duties also limits what a single compromised account can do. If a phished laptop or a leaked personal token can push, merge and release on its own, the attacker inherits the whole path to production in one step.

Environments in GitHub Actions

A GitHub environment attaches protection rules and secrets to the jobs that reference it. A job that targets production pauses until the rules are met:

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://app.example.com
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@<full-length-commit-sha>
      - name: Deploy
        run: ./scripts/deploy.sh production

In the environment settings you configure required reviewers, whether the person who triggered the run may approve it, which branches or tags may deploy, and the secrets or variables that only this environment can read. Using OIDC to your cloud provider, with a trust policy bound to the production environment claim, means there is no long-lived deploy key to leak.

The checklist

Where the gaps usually are

• The break-glass that became the door. An emergency admin bypass that is used every week is the real deploy process.
• The old workflow. A legacy deploy job that predates environments and still holds a repository secret.
• The tiny team. With two engineers, separation is hard. Make the second person approve, and log every exception rather than turning the rule off.
• The workflow edit. If anyone can change the workflow on a branch that is allowed to deploy, they can remove the environment line. Branch restrictions and code owner review on workflow files close this.

Run it in 30 minutes

1. List every workflow that can reach production. Search for deploy scripts, cloud credentials and environment names.
2. For each one, answer the ten questions with the repository settings open on screen.
3. Mark any "no" or "not sure" as a ticket with an owner.
4. Fix the bypasses first: stray secrets, missing environment lines, admin overrides.
5. Repeat whenever a new deploy target is added. It is the last gate on the line, so it is worth checking twice.

Where this sits on the line

In the tower (in development):