Access Control & Permissions

Access control in CI/CD is the discipline of defining who can trigger pipelines, who can approve deployments, who can modify workflow definitions, and what permissions the pipeline itself holds when it runs. It is the human and machine layer of security that sits above the pipeline's technical controls — governing not just what the pipeline can do, but who can instruct it to do anything at all. A pipeline secured at the technical level but accessible to anyone who can open a pull request is not a secure pipeline; it is a well-engineered attack surface with an unlocked front door.

Least Privilege as an Organisational Principle

The principle of least privilege states that every actor — human or machine — should have exactly the permissions required to perform its defined function, and no more. Applied to CI/CD, this means developers who write application code should not automatically have production deployment access. A pipeline job that runs tests should not hold credentials that allow it to push to the container registry. A new contributor should not be able to trigger a workflow that has access to production secrets on their first PR.

Least privilege is not a single setting — it is a continuous practice of auditing what access exists, why it exists, and whether it is still needed. Access accumulates over time: a developer who needed temporary production access for an incident three months ago may still hold that access today. A service account created for a deprecated pipeline may still have live credentials. Regular access reviews — at least quarterly for production systems — are the mechanism that prevents privilege accumulation from becoming a standing vulnerability.

Repository Roles and Team Structure

GitHub organises repository access through five roles, each granting a different set of permissions. The correct assignment of roles — and the discipline of not granting higher roles than necessary — is the first line of access control for any CI/CD system that lives in GitHub.

The most common access control mistake in growing teams is granting Admin or Write roles broadly to avoid having to think about permissions per person. Every developer with Admin access to a repository can modify branch protection rules, change environment secrets, and bypass every pipeline gate. Admin access should be restricted to a small number of named individuals with a documented reason for each grant.

Token Permissions — Scoping the Pipeline's Own Access

Every GitHub Actions workflow run receives a GITHUB_TOKEN — an automatically generated credential scoped to the repository that runs the workflow. By default, this token has broad permissions: it can read and write repository contents, create issues, manage pull requests, write packages, and trigger other workflows. For most pipeline jobs, the vast majority of these permissions are unnecessary.

Declaring minimal permissions at the workflow level and granting additional permissions only to the specific jobs that need them is one of the most impactful access control changes a team can make. A test job that needs to read the repository and nothing else should declare exactly that. A job that publishes a Docker image needs packages: write. A job that creates a release needs contents: write. Everything else gets read or is omitted entirely.

name: CI Pipeline

permissions:                             # Workflow-level default — applies to all jobs
  contents: read                         # Read repository code only
  # All other permissions default to none

jobs:
  test:
    runs-on: ubuntu-latest
    # Inherits workflow-level permissions — contents: read only
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

  publish-image:
    needs: test
    runs-on: ubuntu-latest
    permissions:                         # Job-level override — only this job gets write access
      contents: read
      packages: write                    # Needed to push to GitHub Container Registry
      id-token: write                    # Needed for OIDC token request
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t ghcr.io/myorg/app:${{ github.sha }} .
      - run: docker push ghcr.io/myorg/app:${{ github.sha }}

  create-release:
    needs: publish-image
    runs-on: ubuntu-latest
    permissions:
      contents: write                    # Needed to create a GitHub Release
    steps:
      - uses: actions/github-script@v7
        with:
          script: |
            await github.rest.repos.createRelease({
              owner: context.repo.owner,
              repo: context.repo.repo,
              tag_name: `v${process.env.VERSION}`,
              name: `Release v${process.env.VERSION}`
            })

Environment Protection Rules and Deployment Approvals

GitHub environment protection rules are the access control layer for deployments. A protected environment — typically production — can require that specific named individuals or teams review and approve a deployment before it runs. The pipeline pauses at the deployment job, sends a notification to the required reviewers, and only proceeds when the approval is granted. No code change is required to pause a deployment — the control sits at the infrastructure level.

Beyond manual approval, environment protection rules support additional controls: a wait timer that forces a minimum soak period between approval and deployment, deployment branch filters that restrict which branches can deploy to which environments, and required status checks that must pass before any deployment to that environment is permitted. Together these controls form a deployment governance layer that operates independently of the pipeline code — meaning even a fully automated pipeline can be governed by humans at the environment boundary without changing a single line of YAML.

Practice Questions

Answer in your own words — then check against the expected answer.

Lesson Quiz