GitLab Runner config.toml Executor Tuning Prompt

You are an SRE who operates a fleet of self-managed GitLab Runners and has hand-tuned config.toml for throughput, cost, and security across docker and kubernetes executors.

I will provide:
- Our current config.toml (redacted) and runner version
- Where runners live (VMs, Kubernetes, autoscaling)
- Pipeline pain points (queueing, slow image pulls, cache misses, noisy-neighbor)
- Our GitLab version (to confirm runner auth token vs. deprecated registration token)

Your job:

1. **Registration modernization** — confirm we are using runner authentication tokens (created in the UI/API, used with `gitlab-runner register --token glrt-...`), not the deprecated registration-token flow. Explain the migration if we are still on the old path.

2. **Concurrency** — explain global `concurrent` vs. per-runner `limit` vs. `request_concurrency`, and how to set them against actual CPU/memory so we maximize utilization without OOM-killing jobs.

3. **Executor choice** — opinionated guidance on docker vs. kubernetes vs. shell vs. docker-autoscaler for our workload, with the tradeoffs (isolation, startup latency, cost).

4. **Image & pull policy** — set `pull_policy` (`always`/`if-not-present`/`never`) correctly, use `allowed_pull_policies`, and explain how a misconfigured policy lets one project run a stale or untrusted image.

5. **Cache backend** — wire distributed cache (S3/GCS) in `[runners.cache]` so caching survives ephemeral runners, instead of useless local cache on autoscaled hosts.

6. **Kubernetes executor specifics** (if relevant) — resource requests/limits, `[runners.kubernetes]` namespace isolation, service-account scoping, and node selectors/tolerations.

7. **Security hardening** — disable privileged mode unless DinD truly needs it, restrict the docker socket, and isolate runners that build untrusted MR code.

Output as: (a) an annotated config.toml diff, (b) a concurrency-sizing calculation from our CPU/mem, (c) the distributed-cache block, (d) a security hardening checklist, (e) a validation plan (queue time, cache hit rate, OOM count before/after).

Bias toward: distributed cache for ephemeral runners, least-privilege containers, concurrency sized to real resources.