CI/CD policy uploads in Buildkite: what IAM teams should notice

TL;DR: A Buildkite pipeline pattern uploads policy files to Cerbos Hub on main-branch changes using environment-stored client credentials and a Docker-based agent step, according to Cerbos. The governance issue is not the upload itself, but the standing trust and secret handling assumptions embedded in pipeline execution.

NHIMG editorial — based on content published by Cerbos: a guide to uploading Cerbos policies from a Buildkite pipeline

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

Questions worth separating out

Q: How should security teams govern CI/CD credentials used by build agents?

A: Treat CI/CD credentials as non-human identities with explicit ownership, scope, and lifecycle controls.

Q: Why do branch protections not fully solve CI/CD secret risk?

A: Branch protections decide when a pipeline runs, but they do not constrain what the pipeline credential can do once execution starts.

Q: What breaks when CI/CD secrets live in shared environment variables?

A: Shared environment variables create standing privilege on the agent host, which widens exposure to any process or operator with sufficient local access.

Practitioner guidance

• Move build secrets out of host-wide environment files Store Cerbos Hub client credentials in a dedicated secret manager or ephemeral injection mechanism instead of /etc/environment, then verify that the Buildkite agent only receives them for the duration of the job.
• Scope policy-upload credentials to the narrowest possible action Create a credential pair that can upload policies only to the intended store and cannot be reused for unrelated administrative functions or broader Hub actions.
• Separate release gating from secret authority Keep the main-branch trigger as a deployment gate, but do not treat it as access control for the credential itself.

What's in the full article

Cerbos's full guide covers the operational detail this post intentionally leaves for the source:

• The exact Buildkite pipeline syntax for uploading policy files to Cerbos Hub from a main-branch commit.
• The agent-side environment file setup and restart sequence needed to make the upload job run.
• The Cerbos Hub store credential settings required to permit write access for policy replacement.
• The container command structure used to mount the repository and execute the Cerbos CLI in Buildkite.

👉 Read Cerbos's guide for Buildkite-based Cerbos policy uploads →

CI/CD policy uploads in Buildkite: what IAM teams should notice?

Explore further

View Full Forum →  |  NHI Foundation Course →