Topic starter
12/06/2026 12:36 am
TL;DR: Centralising policy delivery by automating policy uploads from Bitbucket Pipelines to Cerbos Hub concentrates trust in pipeline secrets and branch controls, according to Cerbos documentation. For IAM and NHI teams, the issue is not the upload step itself but the access assumptions behind CI/CD variables and write-capable credentials.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Automating Cerbos Policy deployments with BitBucket Pipelines”.
Key questions
Q: What breaks when policy uploads from Bitbucket Pipelines are not tightly governed?
A: The pipeline becomes a privileged policy publisher rather than a neutral delivery step.
Q: Why do write-capable CI/CD credentials increase policy tampering risk?
A: Because they combine authentication and change authority in a runtime identity that is often reused across pushes.
Q: How do security teams know whether pipeline access is actually under control?
A: Look for three signals: no long-lived deploy secrets in repository or pipeline settings, tight Kubernetes roles scoped to the smallest viable namespace and verbs, and audit logs that tie each deploy to a specific workflow run.
Practitioner guidance
- Harden the policy repository branch path Require explicit review and protection for the main branch that triggers policy publication, so only authorised policy changes can reach the upload job.
- Scope pipeline credentials to the minimum publish path Use separate write credentials for policy upload and ensure they cannot be reused for unrelated environments or other administrative actions.
- Audit CI/CD variables as privileged identities Track CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET as governed secrets, including ownership, rotation, and offboarding when the workflow changes.
Bottom line: Bitbucket-to-Cerbos Hub automation is really a privileged identity path, not just a deployment convenience.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
12/06/2026 9:56 am
Bitbucket policy upload workflows turn CI/CD into a privileged non-human identity. The guide makes that clear by requiring stored client credentials and a write-capable upload path. That means the pipeline is not just moving files, it is exercising authorisation against a policy store, so governance must treat it as an identity with scope, lifecycle, and accountability.
A question worth separating out:
Q: What is the difference between securing a secret and governing its use in CI/CD?
A: Securing a secret means hiding the value and limiting casual exposure. Governing its use means defining who can trigger it, what it can change, how long it remains valid, and how its authority is revoked when the workflow changes. Both are needed for policy upload pipelines.
👉 Read our full editorial: Bitbucket policy uploads to Cerbos Hub expose pipeline trust gaps
This post was modified 5 days ago by NHI Mgmt Group