Authz as a Dev Workflow: Architecting Better Cloud Native Apps - Dan "phrawzty" Maher, Cerbos

Authz as a Dev Workflow: Architecting Better Cloud Native Apps

Speakers: Dan "phrawzty" Maher; Cerbos

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=EBbuyn72jtw

Overview

In this KubeCon EU 2025 talk, Dan "phrawzty" Maher, an open-source advocate at Cerbos, challenged the conventional perception of authorization. He argued compellingly that authorization, often relegated solely to the domain of security, is fundamentally a developer experience problem. Maher drew parallels to the evolution of other critical infrastructure concerns like networking, storage, and deployments, which have all undergone significant transformations to become more declarative, abstracted, and developer-friendly. Authorization, however, has largely remained "stuck," leading to friction, security gaps, and slowed development velocity.

Maher's central thesis is that by approaching authorization as a core development workflow concern, rather than an afterthought, organizations can achieve superior security outcomes while simultaneously enhancing developer productivity and satisfaction. The talk explored the "authorization paradox"—the omnipresent need for authorization checks in every modern application versus its consistent treatment as a secondary concern. By reframing authorization from a restrictive "what can't users do?" to an empowering "how do we enable the right access?", Maher posited that permissions can evolve into a strategic product feature, driving innovation instead of hindering it.

The presentation delved into core design principles, architectural patterns, and practical development strategies for implementing workflow-first authorization in cloud-native environments. Maher highlighted the growing ecosystem of open-source tools, including CNCF projects like OPA and OpenFGA, alongside Cerbos, to illustrate how organizations can adopt declarative policies, externalize decision points, and build context-aware authorization systems. The ultimate goal is to move from a state of constant context switching and tangled business logic to a streamlined, secure, and maintainable authorization pipeline that fosters developer flow and integrates security by design.

Background

▶ Watch: Authorization is a developer experience problem (0:50)

The journey of modern software development has seen remarkable advancements in how we manage complex infrastructure. Dan Maher highlighted how areas like networking have transformed from manual load balancer configurations and firewall rules to declarative service meshes and CNI plugins. Similarly, storage evolved from direct volume management to declarative persistent volume claims and CSI standards. Even deployments, once a perilous landscape of manual shell scripts and scp commands to production, are now governed by sophisticated, automated pipelines. In each of these transformations, the pattern is clear: good abstractions not only hide complexity but fundamentally alter how developers work, leading to increased productivity, improved security, and enhanced reliability.

Authorization, however, has largely missed this evolutionary leap. Maher described it as remaining "stuck" in a peculiar space, often deeply coupled with application logic, intertwined with business rules, and thus difficult to extract, standardize, or rationalize. Unlike networking or storage, which are external infrastructure concerns, authorization is intrinsically linked to the business domain itself. This leads to several critical challenges:

1. Domain Specificity: Authorization requirements are highly diverse across industries. Financial services, SaaS products, or niche applications like "Uber for dogs" all have distinct control needs. There's no universal model, making a one-size-fits-all solution elusive, despite what some vendors might claim.
2. Complexity of Relationships: Modern applications demand intricate permission structures. The simple user-A-can-access-document-B CRUD matrix, prevalent in the '90s, is long gone. Contemporary systems, exemplified by Google Drive or Slack permissions, involve complex relationships between users, resources, and contexts that quickly become tangled.
3. Developer Friction and Costs: The current state of authorization imposes significant costs. Developers constantly context-switch between implementing features and enforcing permissions, often resulting in "tangled rat's nests of if-then-else statements" scattered throughout the codebase. This slows development velocity, especially for new team members who might spend months deciphering existing permission structures. These scattered, inconsistent implementations also create significant security gaps, making it challenging to verify consistent enforcement and leading to extensive, error-prone regression testing when permission models change. Maher cited a past incident where Facebook inadvertently made 15 million private posts public due to a refactoring of their UI model that destroyed underlying permissions, underscoring the severe consequences of poorly managed authorization.

This "authorization paradox"—where authorization is an unavoidable, security-critical component of every request yet consistently treated as an afterthought—highlights the urgent need for a paradigm shift. The core problem, as Maher emphasized, is not solely a security or infrastructure issue, but fundamentally a developer experience problem that breaks developer flow and hinders innovation. The solution lies in approaching authorization as a creative tool, making it declarative, placing it in well-defined spaces, and providing intuitive, maintainable abstractions.

Key Findings

▶ Watch: Authorization's stagnation compared to other fields (2:00)

Dan Maher's talk presented several key findings and insights that collectively advocate for a transformative approach to authorization in cloud-native applications:

1. Authorization is a Developer Experience Problem: This is the foundational insight. While authorization is critical for security, its current implementation practices (scattered, imperative, tightly coupled) create significant friction for developers, hindering productivity, increasing context switching, and making code harder to maintain and test. Addressing developer experience in authorization directly leads to better security outcomes.
2. Shift from Imperative to Declarative Policies: Traditional authorization relies on imperative if-then-else checks embedded within application logic. Maher argued for a shift to declarative policies that describe intent (what should be allowed) rather than how to check permissions. These policies are human-readable, version-controlled, testable independently, and can evolve without requiring application code changes or redeployments.
3. Externalize Authorization as a Service: Decoupling authorization logic from application code is crucial. By treating authorization as an external service with its own APIs, contracts, and lifecycle, applications can query a dedicated decision point. This enables consistent enforcement across all microservices, simplifies reasoning, and allows permission models to be verified without spinning up the entire application stack. Netflix's early adoption of this approach for their microservices ecosystem was cited as a prime example of its benefits in improving security and accelerating feature development.
4. Authorization as a Product Feature, Not Just a Security Constraint: Maher advocated for a mindset shift from framing authorization negatively ("what can't users do?") to positively ("how do we enable the right access?"). This reframe elevates permissions from mere security restrictions to product capabilities. When integrated into product discussions, authorization can shape user experience, enabling progressive disclosure of functionality and enhancing collaborative features, as seen in Slack's workspace permissions.
5. Context-Aware Authorization is Essential: Simple Role-Based Access Control (RBAC) is no longer sufficient for modern, complex applications. Authorization decisions need to be context-aware, considering attributes like time, location, resource properties, and intricate relationship contexts. This moves beyond basic RBAC to more dynamic approaches like Attribute-Based Access Control (ABAC), allowing for fine-grained access control that adapts to situational nuances.

These findings collectively propose a holistic framework for architecting authorization, integrating it as a first-class concern throughout the entire software development lifecycle to achieve both robust security and enhanced developer agility.

Technical Deep Dive

▶ Watch: Why authorization is deeply coupled and complex (3:30)

To effectively transition authorization from a friction point to a fluid part of the development workflow, Maher outlined a set of core design principles and practical patterns.

Core Design Principles for Workflow-First Authorization

1. Domain-Driven Authorization: This principle emphasizes modeling permissions using the language of the business domain, rather than technical constructs. Instead of thinking about CRUD (Create, Read, Update, Delete) operations on database tables, developers should conceive permissions in terms of product roles and actions, such as editor, reviewer, or viewer in a document system. This creates a ubiquitous language across product, development, and security teams, making authorization intuitive and maintainable as the product evolves.
2. Declarative Policies: Moving away from scattered, imperative if user.hasPermission("update_document") checks, declarative policies describe what should be allowed based on business rules. These policies become human-readable artifacts that can be version controlled, independently reviewed, and tested outside of the application codebase. This allows permission models to be updated and deployed without requiring a full application redeployment, significantly reducing friction and increasing agility.
3. External Decision Points: The critical step of decoupling authorization from application logic involves asking an external service "Can user X perform action Y on resource Z?" This architectural pattern ensures consistent enforcement across all microservices, as they all query the same authorization service. This service can have its own APIs (e.g., REST or gRPC), contracts, and testing strategy, allowing for independent verification of the permission model without needing the entire application stack. Netflix's early adoption of this approach in their microservices architecture serves as a powerful testament to its benefits.
4. Context-Aware Authorization: Recognizing the limitations of static RBAC (ratified in 1996), modern applications require authorization decisions that consider a rich context. This includes user attributes, resource metadata, environmental factors (like time of day or location), and complex relationship information. Moving towards dynamic RBAC or Attribute-Based Access Control (ABAC) allows for fine-grained access control that adapts to the situation, such as a healthcare system allowing patient record access only during business hours.

Integration into the Development Lifecycle

These principles are not theoretical; they must be integrated throughout the entire software development lifecycle:

• Requirements Gathering: Permission models should be defined alongside feature requirements, considering access patterns and integration with existing models.
• API Design: Authorization requirements must be explicitly documented within API specifications, detailing who can call endpoints and under what conditions.
• Implementation: Clear, consistent interfaces for authorization checks prevent developers from "inventing new ways to check permissions."
• Testing: Dedicated testing frameworks for policies are essential, mirroring the rigor applied to application code.
• Operations: Monitoring and observability of authorization decisions, integrated into logs and audit trails, help identify and diagnose problems related to access enforcement.

The Authorization Ecosystem: Tools and Standards

Maher highlighted a burgeoning ecosystem of open-source tools and standards addressing authorization challenges:

• OPA (Open Policy Agent): A CNCF graduated project, OPA is a general-purpose policy engine. It uses Rego, a purpose-built policy language, to express rules that can enforce policies for various systems, including Kubernetes admission control and microservice API authorization. OPA completely decouples policy from code, aligning with the externalization principle. While powerful and adopted by large organizations like Netflix, its general-purpose nature and the learning curve for Rego can be a barrier to adoption.
• OpenFGA: A CNCF sandbox project, OpenFGA focuses on relationship-based authorization at scale. It's based on Google's seminal Zanzibar paper, which describes the permission system powering services like Google Drive and YouTube. OpenFGA is optimized for high-performance modeling of complex, arbitrary relationships between objects, making it suitable for "planet-scale" scenarios. However, it's less suited for traditional RBAC or simple ABAC, being highly specialized for intricate relationship modeling.
• Ozen (Open ID Foundation AuthZ Working Group): This initiative aims to standardize authorization APIs and interfaces, building on the success of OAuth2 and OpenID Connect for authentication. Ozen seeks to foster interoperability between different authorization systems, creating common interfaces that various implementations can support, thus ensuring long-term evolution and coherence in the ecosystem.
• Cerbos: Maher's own company's offering, Cerbos, uses human-readable YAML policies that product teams can understand and review. It focuses on expressing who can do what to which resources under what conditions, emphasizing a strong developer experience with features like a playground for testing policies, an in-built testing framework, and tools for simulating requests and examining traces. Cerbos aims to make authorization accessible and intuitive.

Choosing among these tools depends on specific architectural needs. OPA is ideal for broad policy enforcement beyond just authorization (e.g., configuration validation). OpenFGA shines in highly complex, relationship-based scenarios at massive scale. Cerbos targets developer workflow integration and simplicity with human-readable policies. Maher noted that teams often use multiple tools, emphasizing that adherence to the core principles is paramount.

Architectural and Development Patterns

Maher also detailed several practical patterns for implementing workflow-first authorization:

• Policy as a Service (Architectural Pattern): This involves encapsulating all authorization logic in a dedicated service. Applications make explicit requests ("Can user X perform action Y on resource Z?") and receive a simple yes/no decision. This ensures consistent enforcement, simplifies policy updates, and works well in microservice architectures requiring centralized governance.
• Sidecar (Architectural Pattern): In Kubernetes environments, an authorization engine can be deployed as a sidecar container alongside each application instance. This provides very low latency for authorization checks by eliminating network hops for critical path decisions. Tools like Envoy can implement this pattern, offering the advantages of an API-driven authorization service without the network latency of a centralized service.
• Multi-Layer Authorization (Architectural Pattern): This pattern recognizes that different types of authorization belong at different layers of the stack.
• API Gateway/Ingress Layer: Handles coarse-grained checks, basic RBAC, and authentication validation.
• Service Layer: Enforces business logic authorization, performing user checks based on access levels and conditions (e.g., time of day).
• Data Layer: Implements fine-grained row-level or object-level authorization for fundamental primitive access control.

This layered approach builds a defense-in-depth model, enhancing overall security.

• Policy-Driven Design (Development Pattern): Analogous to Test-Driven Development (TDD), this flips the traditional implementation sequence. Developers start by writing authorization requirements and policies, testing them to ensure they return expected outcomes, and then write the application code that utilizes these policies. This approach can even drive API design, ensuring that exposed capabilities align directly with defined permissions.
• Request Context Enrichment (Development Pattern): Authorization decisions often require a rich set of contextual information (user attributes, resource metadata, environmental factors, relationships). This pattern involves implementing request middleware or interceptors to gather and bundle this information, making it available to the authorization engine. This rich context makes authorization rules significantly more powerful and flexible, particularly where RBAC falls short.
• Policy Testing (Development Pattern): Reiterating the importance of testing, Maher stressed that any authorization solution must have robust, built-in testing capabilities. This includes testing policies with test fixtures to simulate various scenarios, ensuring that authorization rules behave as expected.

These technical strategies, when combined, transform authorization from a complex, error-prone task into a streamlined, secure, and integrated part of the development process, fostering developer empowerment and security by design.

Demo / Proof of Concept

▶ Watch: The real costs: context switching, security gaps, slow velocity (4:40)

While Dan Maher's talk was primarily conceptual and architectural, focusing on principles, patterns, and an overview of the ecosystem, it did not feature a live, explicit demonstration of a specific tool or proof of concept in action. However, when discussing Cerbos, he highlighted features that serve as practical implementations of the workflow-first approach: "a playground for testing policies," an "in-built testing framework," and the ability to "simulat[e] requests examining traces." These features, integral to Cerbos's design, exemplify how developers can interact with and validate authorization policies in a hands-on manner, reflecting the emphasis on developer experience and testability central to the talk's message.

Defensive Implications

▶ Watch: Re-framing authorization as a creative workflow tool (6:15)

The shift to a workflow-first approach to authorization carries profound defensive implications, fundamentally altering how security is woven into the fabric of cloud-native applications:

1. Security by Design, Not an Add-on: By treating authorization as a first-class architectural concern from the outset, security becomes an inherent part of the application's design, rather than a bolted-on afterthought. This proactive stance significantly reduces the likelihood of critical vulnerabilities and misconfigurations.
2. Defense-in-Depth Enhancement: The multi-layer authorization pattern directly contributes to a robust defense-in-depth strategy. By implementing different types of authorization checks at the API Gateway, service, and data layers, an attacker would need to bypass multiple, distinct security controls to gain unauthorized access, increasing the overall resilience of the system.
3. Reduced Security Gaps and Inconsistencies: Externalizing authorization logic and enforcing policies consistently across all services through a dedicated authorization service eliminates the scattered, inconsistent implementations that often lead to security gaps. Every microservice calls the same trusted decision point, ensuring uniform application of access rules.
4. Improved Auditability and Verification: Declarative policies, being human-readable, version-controlled, and independently testable, drastically improve the auditability of permission models. Security teams can easily review, understand, and verify who can do what, based on clear business rules, without sifting through complex application code. This also enables easier compliance auditing.
5. Faster Identification of Problems: Integrating authorization decisions into monitoring and observability systems means that anomalies or unauthorized access attempts can be detected and alerted upon more rapidly. By tracking what permission checks are being made and how they affect system behavior, operations and security teams gain critical insights into potential breaches or misconfigurations.
6. Empowering Developers for Better Security Decisions: By providing clear abstractions, intuitive tools, and integrating authorization into the developer workflow, developers are empowered to make better security decisions. They spend less time "wrestling with permissions" and more time building features securely, understanding the "why" behind access controls rather than just implementing them mechanistically. This fosters a culture of shared security responsibility.
7. Mitigating High-Impact Errors: The historical example of Facebook's 15 million private posts becoming public due to authorization logic being tightly coupled with UI refactoring underscores the immense risk of the traditional approach. By decoupling and externalizing authorization, changes to core application features or UI elements are far less likely to inadvertently compromise access controls, preventing potentially catastrophic data breaches or privacy violations.

In essence, workflow-first authorization transforms security from a reactive burden into an integrated, proactive capability, enabling organizations to build more secure, resilient, and compliant cloud-native applications while accelerating development.

Key Takeaways

• Authorization is a Developer Experience Problem: It's not just a security concern, but a major source of friction, context switching, and slow velocity for developers. Addressing this improves both security and productivity.
• Shift to Declarative, Externalized Policies: Move away from imperative, embedded if-then-else checks to human-readable, version-controlled, and independently testable declarative policies managed by an external authorization service.
• Embrace Context-Awareness and Beyond RBAC: Modern applications require authorization decisions based on rich context (time, location, resource properties, relationships), moving beyond simple Role-Based Access Control to dynamic RBAC or Attribute-Based Access Control.
• Treat Authorization as a First-Class Architectural Service: Decouple authorization logic from application code, establishing it as a dedicated service with its own APIs, contracts, and lifecycle, similar to how other infrastructure concerns have evolved.
• Integrate Authorization Throughout the SDLC: From requirements gathering and API design to implementation, testing, and operations, authorization must be woven into every stage of the development lifecycle, including policy-driven design and dedicated policy testing.
• Leverage the Evolving Open-Source Ecosystem: Tools like OPA (general policy engine), OpenFGA (relationship-based authorization), and Cerbos (developer-friendly YAML policies) offer diverse solutions to manage authorization complexity, often used in combination to fit specific architectural needs.

About the Speaker(s)

Dan "phrawzty" Maher is an open-source advocate at Cerbos, a company focused on authorization solutions. With a background spanning infrastructure, development, and security, Maher has worked at notable organizations such as Ubisoft, Mozilla, and DataDog. His extensive experience across these domains has led him to the crucial insight that authorization, often compartmentalized as a security issue, is fundamentally a developer experience challenge that warrants architectural attention and a workflow-first approach.