GitLab Runner is the agent that obtains CI/CD jobs and executes them through an executor. A reliable setup requires more than installation: the host, registration workflow, executor, tags, permissions, network access, and maintenance policy define the runner’s security boundary.
Choose the runner scope and executor
| Decision | Options | Key tradeoff |
|---|---|---|
| Scope | Project, group, or instance | How broadly jobs can use the runner |
| Executor | Shell, Docker, Kubernetes, or another supported type | Isolation, reproducibility, and operational complexity |
| Trust | Protected or general workloads | Whether secrets and deployment access may be exposed |
A shell executor runs commands directly on the Ubuntu host and should be reserved for highly trusted workloads. Container-based execution improves repeatability but still requires image governance, limited privileges, and careful volume and socket access.
Prepare Ubuntu safely
- Use a supported Ubuntu release and install current security updates.
- Create dedicated storage and monitor free disk space.
- Limit inbound access and outbound destinations.
- Synchronize time and configure centralized logs.
- Avoid co-locating unrelated sensitive services on the runner.
- Plan how runner packages and executors will be upgraded.
Install and register
Use GitLab’s current package instructions for the Ubuntu version, then register through the workflow provided by the target GitLab instance. Treat registration material as sensitive, assign descriptive tags, disable untagged-job handling unless intended, and lock the runner to the correct scope when appropriate.
Validate with a harmless job
- Confirm the runner service is active.
- Verify the runner appears online in GitLab.
- Run a job that prints tool versions without secrets.
- Check that tags route the job to the intended runner.
- Confirm artifacts and logs are returned correctly.
- Test job timeout, cancellation, and cleanup behavior.
Hardening priorities
- Do not expose the container-engine socket to untrusted jobs.
- Avoid privileged containers unless the threat model explicitly permits them.
- Separate protected deployment runners from merge-request runners.
- Use ephemeral cloud credentials and narrow job-token permissions.
- Patch the host, runner, executor, and base images.
- Remove stale runners and rotate credentials after compromise.
Troubleshooting
| Symptom | Check |
|---|---|
| Runner offline | Service status, registration state, GitLab reachability |
| Job remains pending | Tags, scope, protection rules, available concurrency |
| Container job fails | Executor configuration, image access, DNS, storage |
| Disk fills repeatedly | Build directories, cache, images, artifact behavior |
| Secrets unavailable | Protected branch context and variable restrictions |
Join the discussion
0 CommentsAsk questions, add context, or share what worked.
More from Melochip Editorial
Learn what Playwright testing is, why modern QA teams use it, how testers can get started, and the major types...
7 min read · Sep 19, 2026
Learn how Kubernetes Deployments and ReplicaSets work with practical YAML, scaling, self-healing, rolling upda...
7 min read · Sep 17, 2026
Learn Kubernetes security best practices with RBAC, Secrets, ServiceAccounts, Pod securityContext, NetworkPoli...
6 min read · Sep 17, 2026Related articles
Learn what Playwright testing is, why modern QA teams use it, how testers can get started, and the major types...
7 min read · Sep 19, 2026
Learn how Kubernetes Deployments and ReplicaSets work with practical YAML, scaling, self-healing, rolling upda...
7 min read · Sep 17, 2026
Learn Kubernetes security best practices with RBAC, Secrets, ServiceAccounts, Pod securityContext, NetworkPoli...
6 min read · Sep 17, 2026
Learn Kubernetes monitoring and logs with kubectl logs, events, metrics-server, top commands, Prometheus, Graf...
5 min read · Sep 17, 2026Stay in the loop. Get new Melochip articles
Receive Melochip article updates when new articles are available. Explicit opt-in only.
No comments yet. Start the discussion.