GitLab Runner Tags, Protected & Job Isolation Hardening Prompt

You are a CI security engineer whose job is to ensure a fork or feature-branch MR can never run on a runner that holds production credentials.

I will provide:
- My runner inventory (shared/group/project, executors, what creds each can reach)
- Which jobs are trusted (default-branch deploys) vs untrusted (MR, fork)
- Current tagging discipline (often "none")

Your job:

1. **Map a trust model** — classify runners into tiers: public/untrusted (build & test MRs, no secrets), privileged/protected (deploys, signing, prod creds) — and assert that no runner serves two tiers.

2. **Tag strategy** — assign meaningful tags (`build`, `deploy-prod`, `signing`, `arm64`) and use `tags:` on jobs to route deliberately; decide per runner whether "Run untagged jobs" is allowed (usually OFF for privileged runners) so an untagged job can't land on them.

3. **Protected runners** — set privileged runners as "Protected" so they only run jobs on protected branches/tags; verify an MR pipeline physically cannot use them, and pair with protected CI/CD variables.

4. **Assignment scope** — when to use a project-specific or group runner over a shared instance runner, and disabling shared runners on sensitive projects.

5. **Executor isolation** — for the untrusted tier, prefer ephemeral executors (Kubernetes/Docker autoscaler) that destroy the VM/pod after each job; never `shell` executor for MRs; disable Docker socket mounts / privileged mode unless an isolated builder requires it.

6. **Fork-MR exposure** — explain how forked-MR pipelines run and why they must never reach protected runners or secrets, plus the "approve pipeline for fork" gate.

7. **Audit** — a checklist/script to flag runners that allow untagged jobs AND hold secrets, unprotected runners on prod-capable hosts, and overly broad shared-runner access.

Output: (a) the runner trust-tier table (tier → tags → protected? → untagged? → secrets reachable), (b) example `tags:` per job class, (c) the runner registration/settings per tier, (d) the fork-MR safeguard, (e) the audit checklist.

Bias toward: privileged runners protected + tagged-only, ephemeral isolation for untrusted jobs, no shared runner ever touching prod secrets.