Uber's Attribute-Based Access Control (ABAC) System: Charter

The Challenge of Microservice Authorization at Scale

Uber's ecosystem, comprising thousands of microservices, demands authorization decisions millions of times daily with microsecond latency. Traditional access control models, such as basic service-to-service or group-based permissions, proved insufficient for the complex, context-dependent rules required. For instance, restricting access based on user location, time of day, or dynamic relationships between data items necessitated a more flexible and expressive system.

Introducing Attribute-Based Access Control (ABAC)

To overcome these limitations, Uber built Charter, a centralized Attribute-Based Access Control (ABAC) system. ABAC allows authorization policies to be defined using attributes of the actor (who is making the request), the resource (what is being accessed), the action (what is being done), and the environment (contextual factors like time or location). This approach provides significantly more granularity and flexibility compared to traditional Role-Based Access Control (RBAC).

Core Components of the Charter System

• <b>Charter Service:</b> A centralized policy repository where administrators define authorization policies. It stores these policies in a database.
• <b>Unified Configuration Distribution System:</b> Pushes policy updates from Charter to all relevant microservices.
• <b>authfx Library:</b> A local library embedded within each service responsible for evaluating policies for incoming requests. This ensures authorization decisions are made locally, minimizing latency.
• <b>Attribute Stores:</b> External services or data sources that provide attribute values at runtime (e.g., ActorAttributeStore, ResourceAttributeStore, EnvironmentAttributeStore). These are critical for evaluating complex conditions.

Policy Definition and Evaluation

Policies in Charter are defined using a declarative syntax, often resembling YAML. A policy specifies an effect (allow/deny), actions, resources, and associations (e.g., target type, target ID). The key innovation of ABAC is the addition of a 'condition' field, which is a Boolean expression evaluated against attributes fetched from various attribute stores at runtime. For example, a policy might allow an employee to access payment data only if their location matches the payment's location and the payment type is 'credit card'.

actions: [create, delete, read, update]
resource: "uon://payments.svc/production/payment/*"
associations:
  - target_type: EMPLOYEE
condition: expression: "resource.paymentType == 'credit card' && actor.location == resource.paymentLocation"
effect: ALLOW

Leveraging Common Expression Language (CEL)

Uber adopted Google's Common Expression Language (CEL) as the expression language for defining conditions within their ABAC policies. CEL offers a simple, familiar syntax, support for multiple data types, built-in functions, and excellent performance characteristics (microseconds for evaluation). Its ability to support lazy attribute fetching further optimizes efficiency by only retrieving attributes explicitly needed for a given condition's evaluation.