Attribute-Based Access Control at Uber

Uber · 2023 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bản crawl không giữ được các ví dụ YAML policy và sơ đồ kiến trúc; ghi chú dựa trên phần chữ.

Bối cảnh

Uber phân quyền theo policy qua một service tập trung là Charter (giống IAM của AWS/GCP). Policy được phân phối xuống các microservice, và mỗi service đánh giá, thực thi tại chỗ bằng thư viện authfx.
Mô hình request: Actor thực hiện Action trên Resource trong Context.
- Actor dạng SPIFFE ID: nhân viên, khách hàng, hay workload (spiffe://prod.upki.ca/workload/service-foo/production).
- Resource dạng UON (Uber Object Name, URI uon://): endpoint RPC, bảng hay cột DB, đối tượng nghiệp vụ; phần host là policy domain để nhóm policy.
Policy cơ bản (actor/action/resource) không đủ khi:
- cần quyết định theo thuộc tính của resource (support chỉ xem thông tin thanh toán của khách ở một quốc gia hay thành phố, trong khi resource chỉ là UUID);
- cần quan hệ giữa thuộc tính của actor và resource (nhân viên hoặc quản lý của họ được sửa hồ sơ);
- cần AND nhiều group.

ABAC: permission có thể kèm condition; permission chỉ có hiệu lực khi khớp resource, action và condition trả true.
Attribute store (PIP): plugin mà service tự cung cấp để lấy giá trị thuộc tính lúc chạy; một service dùng nhiều store, một store dùng chung cho nhiều service. Store khai báo SupportedAttributes() để engine biên dịch trước biểu thức.
Ngôn ngữ biểu thức: chọn CEL của Google thay vì tự viết; có bản Go (cel-go) và Java (cel-java), đánh giá vài micro giây, hỗ trợ lấy thuộc tính theo nhu cầu (chỉ fetch khi biểu thức cần).
Áp dụng (2023): 70 service dùng ABAC. Ví dụ Kafka: topic là resource uon://topics.kafka/production/<topic> với action subscribe/publish/admin. Đội Kafka không thể quản lý policy cho hàng nghìn topic, nên viết một policy chung: ai có role Develop trên topic (lấy từ service sở hữu tài sản uOwn qua attribute store) thì được quản lý policy của topic đó.

Theo Uber: policy chi tiết hơn theo đúng nhu cầu từng service; quản trị tập trung ở Charter nên đổi policy không cần build/deploy lại code, và các service không phải tự viết logic phân quyền.

Tách điểm quản trị policy (tập trung) khỏi điểm thực thi (thư viện tại chỗ) để vừa quản lý được vừa không thêm network call.
RBAC/ACL tĩnh hết đủ khi luật phụ thuộc thuộc tính; thêm condition + nguồn thuộc tính dạng plugin thay vì nhét thuộc tính vào tên resource.
Dùng ngôn ngữ biểu thức có sẵn (CEL) thay vì tự viết.
Một policy chung dựa trên dữ liệu sở hữu (ai sở hữu tài sản) cho phép uỷ quyền quản trị mà không phải viết policy cho từng tài sản.

Uber 2025 (cùng đội bảo mật, hướng workload identity) · LinkedIn 2019 (ACL tập trung, thực thi tại chỗ) · Figma 2024 (policy + điều kiện, tự viết DSL)
Xác thực và phân quyền (authn/authz) · Nền tảng nội bộ cho service (đường ray chung)