Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

CI runner isolation: treat repository code as untrusted

Last updated: 5 Oct 20266 min read
tutorial
IntermediateBy AITrove Editorial

A CI runner executes repository-controlled code. A persistent self-hosted runner may retain files, processes, tokens, or network access between jobs. The trust boundary includes who can trigger a workflow and which repositories share a runner group. An environment approval gate does not make a compromised host clean.

Operational decision

For a claims platform, run external pull-request tests on isolated hosted workers with read-only permissions. Put deployment jobs on a separate runner group that accepts only protected repository workflows. If self-hosting is necessary, use one-job ephemeral instances and destroy the underlying workspace after each job; deregistration alone does not erase secrets from reused hardware. Restrict access to cloud metadata endpoints and internal networks. Pin third-party actions and keep the deployer's OIDC trust policy scoped to the production environment. The YAML fragment shows a job boundary, not a complete security policy. Audit the actual branch, workflow-file, runner-group, and cloud-role permissions together; a narrow job token cannot compensate for a runner that already holds a long-lived administrator key.

yaml
jobs:
  verify:
    runs-on: ubuntu-latest
    permissions: {contents: read}
    steps:
      - run: make test
  promote:
    needs: verify
    runs-on: [self-hosted, isolated-release]
    environment: production
    permissions: {contents: read, id-token: write}
    steps:
      - run: ./release/promote-verified-digest.sh

Cost and verification

Ephemeral runners require provisioning time, image maintenance, and centralized logs. Those costs buy a cleaner boundary; a persistent runner can be cheaper per job while creating a large compromise path. The fragment omits checkout and identity exchange, so it cannot run as a complete workflow. Review which people can change runner labels and assign jobs. A label is a scheduler selector, not an access-control guarantee by itself.

Common Mistakes

  • Do not give untrusted pull-request jobs access to a deployer runner.
  • Do not assume deregistration wipes reused hardware.
  • Do not treat a runner label as the only security boundary.

Connected lessons

devops
operations
Storage details