Notifications
Clear all
Topic starter
09/06/2026 11:02 pm
TL;DR: Policy-driven authorization can be versioned, tested, and deployed through GitOps while keeping decisions stateless, auditable, and fast across Kubernetes, serverless, edge, and on-prem environments, according to Cerbos’ CNCF demo. The governance lesson is that authorization drift is now an infrastructure problem, not just an application-code concern.
NHIMG editorial — based on content published by Cerbos: GitOps for application authorization, demonstrated in a CNCF live session
By the numbers:
- Cerbos says its GitOps workflow can pull policy updates every 10 seconds.
Questions worth separating out
Q: How should security teams govern application authorization outside code?
A: Security teams should treat authorization as a controlled policy asset, not a series of hidden conditional statements inside services.
Q: Why do distributed applications make authorization harder to govern?
A: Distributed applications create more places for authorization logic to drift.
Q: How do you know if policy-based authorization is working?
A: It is working when policy changes are versioned, testable, and traceable, and when allow or deny decisions can be explained after the fact.
Practitioner guidance
- Separate authorization policy from application code Move permission rules into centrally governed policy files so they can be reviewed, versioned, and deployed independently of service releases.
- Require policy tests before deployment Create isolated test cases for common roles, attributes, and resource states before merging policy changes.
- Log every allow and deny decision centrally Send decision records to a system security teams can inspect for audit, troubleshooting, and recertification support.
What's in the full article
Cerbos' full demo covers the operational detail this post intentionally leaves for the source:
- The live walkthrough of how the policy decision point is wired into an application request flow.
- The GitHub Actions test workflow used to validate authorization policy changes before deployment.
- The YAML policy and test fixtures that show how roles, regions, and resource attributes are evaluated.
- The runtime options for Kubernetes, serverless, edge, and WebAssembly deployments.
👉 Read Cerbos' CNCF demo on GitOps for application authorization →
GitOps for application authorization in Kubernetes and beyond?
Explore further
10/06/2026 1:13 am
Policy-driven authorization is becoming a governance layer, not a coding convenience. The demo shows why decoupling permission logic from application code is more than developer ergonomics. Once authorization is expressed as policy, it can be reviewed, tested, and versioned like other identity controls, which is how mature IAM programmes should already treat access logic. For practitioners, the implication is that authorization belongs in controlled lifecycle governance, not ad hoc service development.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
- Another finding from that research shows organisations maintain an average of 6 distinct secrets manager instances, which fragments control and weakens consistency.
A question worth separating out:
Q: What is the difference between centralized authorization and embedded access checks?
A: Centralized authorization evaluates permissions through one governed policy source, while embedded checks scatter logic across application code. The centralized model improves consistency, testing, and auditability, while embedded logic tends to create duplication and hidden drift across services.
👉 Read our full editorial: GitOps for application authorization: what Cerbos changes
