Cluster Runner
A cluster runner is an agent that runs build and deploy jobs inside your container nodes. You set it up by installing the worker pod and linking it to a service role. Teams often give this worker role wide cluster rights so every deploy script works. That wide role creates a huge risk when a bad script or developer runs a command. One bad job can read secret keys or delete live apps across every node. How a cluster runner works in your stack Your code host holds a queue of pending build and t
Runner: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A cluster runner is an agent that runs build and deploy jobs inside your container nodes. You set it up by installing the worker pod and linking it to a service role. Teams often give this worker role wide cluster rights so every deploy script works. That wide role creates a huge risk when a bad script or developer runs a command. One bad job can read secret keys or delete live apps across every node.
How a cluster runner works in your stack
Your code host holds a queue of pending build and test tasks. The cluster runner watches this queue and pulls new jobs as they arrive. When a job starts, the main agent asks the cluster API to make a new pod. The pod pulls a container image and runs the shell steps from your job file. When the script finishes, the agent sends the log output back to your code host. Then the cluster deletes the worker pod to free up memory and CPU.
Every job pod needs a service account role to talk to the cluster API. Teams bind this role to namespaces where the worker needs to place new apps. If the role only touches one namespace, the blast radius stays small. Yet most teams use one shared runner for many apps and namespaces. They attach cluster admin rights so the worker can create roles and services anywhere. Any engineer who can edit a pipeline file now owns that huge role.
What native roles solve and where they fall short
Native cluster roles decide which service accounts can call the main API server. You can lock down a role so a worker pod only edits one namespace. You can also block the pod from reading secret objects stored in the cluster. Network rules can stop the worker pod from talking to private internal networks. These native controls set a solid baseline for static build jobs.
Still, native roles only check who logs in at the start of a request. They do not inspect the actual shell commands or database queries running inside the job. A job with database access can drop tables or dump customer email addresses and phone numbers. Native logs only show that a pod started, not what queries ran inside it. If an engineer opens a debug shell into the runner, you lose visibility. You cannot pause a risky command for human review or rewrite sensitive fields in results.
Runner: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Ways to lock down worker jobs and debug sessions
Start by splitting your runners by team and risk level. Give your test runner a tiny role that cannot touch live systems. Put your live deploy runner in its own locked namespace with strict network rules. Never let untrusted pull requests run on a worker that holds live keys.
Next, remove long-lived database passwords and cloud keys from your pipeline settings. Static keys sitting in job settings leak through build logs all the time. Make sure every command and query leaves a clear audit trail tied to a real user. When an engineer needs to debug a broken build or live pod, track every action. Check each command in flight and mask card numbers or national IDs in query output.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between a host runner and a cluster runner?
A host runner executes jobs directly on a fixed virtual machine. A cluster runner spins up a fresh container pod for every single job and deletes it after.
Why should we avoid giving admin rights to a worker pod?
Any person who can trigger a build can run commands using that pod role. Admin rights let a bad build script read all secrets or wipe out live workloads.
How can teams protect sensitive data during runner tasks?
Keep static passwords out of build files and check every query in flight. Use data masking to rewrite emails and phone numbers before results reach the build log.