Managed CI CD Hosting
You set up managed ci cd hosting by linking your code repo to a cloud runner service. Then you assign narrow roles so each build job only gets the keys it needs. Most teams start by storing cloud keys inside shared repo settings. When a team gives those keys broad roles, any pull request can change live apps or read private databases. Limiting those job permissions is the core task of a safe build setup. How managed ci cd hosting permissions work A cloud build host runs your tests and deploy
CI/CD Credential Management + Managed Identities: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up managed ci cd hosting by linking your code repo to a cloud runner service. Then you assign narrow roles so each build job only gets the keys it needs. Most teams start by storing cloud keys inside shared repo settings. When a team gives those keys broad roles, any pull request can change live apps or read private databases. Limiting those job permissions is the core task of a safe build setup.
How managed ci cd hosting permissions work
A cloud build host runs your tests and deploy scripts on remote virtual machines. When a developer pushes code, the host spins up a fresh runner machine. That runner pulls the code and reads the workflow file from the repo.
To deploy code or run database updates, the runner must log in to your cloud account. Teams handle this step in two main ways. The old way is to paste static keys into the build host secret store. The runner loads those keys into memory when the job starts. Any script inside that job can read and use those static keys.
A safer way uses short trust links between the build host and your cloud provider. The runner asks the cloud provider for a short token at the start of a job. The cloud provider checks which repo and branch asked for the token. If the branch matches your rule, the cloud issues a temporary role for that single run. When the job ends, the token expires right away.
What native build roles solve and what they miss
Branch rules and temporary tokens solve the problem of long-lived keys sitting in repo settings. You no longer need to rotate static keys by hand every few months. You can also block test branches from getting production roles.
Still, native build roles only check who logs in at the start of a job. Once a deploy job assumes a production role, the cloud host trusts every command it sends. A database migration role needs rights to change tables and read rows. Native cloud roles cannot tell a safe schema update from a bad script that drops a table.
CI/CD Credential Management + Managed Identities: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The same gap appears when a build job runs shell commands on live servers or queries live data. If a third-party package in your build pipeline gets compromised, it runs with the full role of that job. It can read emails, phone numbers, or card numbers from your database during a migration step. Build logs also fail to capture the exact SQL queries or remote commands that the runner sent. Teams need a way to check individual commands in flight and rewrite sensitive fields in results.
Steps to lock down your build runners
Start by splitting your build jobs into small steps with separate roles. Give your test job zero cloud keys so it only runs unit tests on isolated code. Put your deploy and database migration steps in a separate job that only runs on your main branch.
Next, replace static secret keys with short trust tokens tied to specific repo branches. Scope each cloud role down to the exact service that the deploy job touches. Finally, add runtime checks between your runners and your live databases or servers. This step lets you block destructive queries and log every command that a build job runs.
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 sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How should teams store secrets in a cloud build host?
Avoid storing long-lived cloud keys in your build host whenever you can. Set up trust rules so your runner trades a job identity token for a short cloud session. For third-party API keys that cannot use trust tokens, scope them to specific deploy branches only.
Why do build runners need runtime command checks?
A deploy runner needs high permissions to update apps and alter database tables. Cloud roles only check the runner identity when the session starts. Runtime checks inspect each query or command in flight to stop accidental data loss or rogue scripts.
Can pull requests from forks steal build secrets?
Yes, if your workflow runs untrusted code with secret access turned on. Always block fork pull requests from reading secrets or requesting cloud tokens. Require a team member to review the code before any build job runs with cloud permissions.