GloriousFlywheel

Security Model

This document describes the security boundaries and access controls for the runner infrastructure.

Privilege Boundary

Only the dind runner operates in privileged mode. This is required for the Docker daemon sidecar and cannot be avoided for Docker-in-Docker builds. All other runner types (docker, rocky8, rocky9, nix) run as unprivileged containers.

For container builds that do not require a full Docker daemon, consider using Kaniko on the unprivileged docker runner instead. See Docker Builds for details.

Namespace Isolation

All runners are deployed into a dedicated namespace: {org}-runners. This isolates runner workloads from application services and other infrastructure components.

RBAC

Runners have minimal RBAC permissions scoped to their own namespace. They cannot create, modify, or delete resources outside {org}-runners. The GitLab Runner Helm chart creates a ServiceAccount with only the permissions needed to manage job pods within the namespace.

Secrets Management

Network Access

Container Images

Runner job pods pull images from public registries (Docker Hub, GitLab Container Registry). The runners themselves do not have push access to any registry. Image provenance is determined by the base image specified in the runner configuration (Alpine, Rocky Linux, NixOS).