GitLab Cluster
You set up a gitlab cluster by running an agent inside your Kubernetes nodes. This agent talks back to your source code host to pull changes and run jobs. Teams often start by giving that agent broad cluster admin roles to ship apps fast. When roles stay that wide, one bad job or leaked token can touch every app. How a gitlab cluster setup works In the past, the code host pushed changes straight to the Kubernetes API. That old push model forced teams to open their cluster API to the public we
GitLab CI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a gitlab cluster by running an agent inside your Kubernetes nodes. This agent talks back to your source code host to pull changes and run jobs. Teams often start by giving that agent broad cluster admin roles to ship apps fast. When roles stay that wide, one bad job or leaked token can touch every app.
How a gitlab cluster setup works
In the past, the code host pushed changes straight to the Kubernetes API. That old push model forced teams to open their cluster API to the public web. Modern setups reverse this flow by placing a small agent inside your nodes. The agent opens an outbound link back to the code host and waits for work.
You keep a text file in your code repo to tell the agent what to do. In that file, you state which groups or projects can use the link. You then map those project identities to native Kubernetes roles inside your nodes. When a pipeline runs, it sends commands through the agent using those mapped roles.
This workflow also supports pull-based app syncs right from your git branch. The agent watches a chosen folder in your repo for any manifest changes. When a developer merges new code, the agent pulls the state and applies it. Humans can also use this path from their laptops if you grant user roles.
Where native cluster roles fall short
The native agent model solves the network firewall problem very well. You no longer need to expose your control plane to outside traffic. It also links your code projects to cluster roles in one central place. Still, role bindings only check who can log in and which verbs they hold.
Once a user or job gets update or exec rights, the native setup steps back. A role that allows pod exec lets an engineer run any shell command inside. That engineer can read app memory, pull secret keys, or query internal data stores. Native cluster logs often show that an exec call happened, not the exact commands run.
GitLab CI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared service roles for pipelines create a similar blind spot for security teams. Many jobs share one deployment role to push updates across a namespace. If a developer changes a pipeline script, that script runs with full namespace power. Native role checks cannot inspect each command in flight or ask a peer for approval.
Why teams need command level controls
To run safe clusters, teams must look past initial login and role checks. You need a way to inspect every single command and query as it runs. Good controls let a developer check pod logs while blocking destructive shell actions. When an engineer needs to run a risky fix, the system should pause for approval.
Data safety also matters when engineers debug live pods or linked databases. Live logs and query results often hold user emails, phone numbers, or card numbers. Masking rules can rewrite those matched fields in results before they reach the screen. This keeps your day-to-day fix workflows fast while keeping private customer data safe.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How does the agent link to a gitlab cluster?
You install a small agent pod inside your Kubernetes nodes using a token. That pod opens an outbound link back to your code host to receive work.
Should pipelines use cluster admin roles?
No, broad admin roles give every pipeline job power over all namespaces and secrets. You should scope each project to a narrow role in its own target namespace.
Can native Kubernetes roles hide sensitive data in pod output?
No, native roles only decide if a user can view a pod or its logs. They cannot rewrite sensitive fields like emails or card numbers inside the output stream.