How Google Manages Permissions for 4 Billion Users
Google Workspace serves over 4 billion users across Gmail, Drive, Docs, and Calendar. A document owner can share with specific people, anyone with the link, or their entire organization. A user might be an owner of one document, editor of another, and viewer of a third - all in different organizational contexts. Pure RBAC (admin/editor/viewer) cannot express 'Alice can edit documents owned by her department during business hours.' Google uses a hybrid approach: RBAC for broad access tiers, ABAC policies for fine-grained resource-level control.
RBAC: Role-Based Access Control
RBAC Model:
Users Roles Permissions
------ ------- ----------------------
Alice -----> [Editor] ----> create_article
|-> edit_article
|-> view_article
Bob -----> [Viewer] ----> view_article
Carol -----> [Admin] ----> create_article
|-> edit_article
|-> view_article
|-> delete_article
|-> manage_users
Check: can Alice delete an article?
Alice -> Editor role -> permissions: [create, edit, view]
'delete_article' NOT in permissions -> DENIED
Database Schema:
+-------+ +------------+ +-------+ +--------------+ +-------------+
| users |---->| user_roles |<----| roles |---->|role_permissions|<---| permissions |
+-------+ +------------+ +-------+ +--------------+ +-------------+
| id | | user_id | | id | | role_id | | id |
| name | | role_id | | name | | permission_id| | name |
+-------+ +------------+ +-------+ +--------------+ +-------------+
Hierarchical RBAC (role inheritance):
super_admin -> admin -> editor -> viewer
Each role inherits all permissions of roles below it.ABAC: Attribute-Based Access Control
ABAC Model:
Policy: ALLOW action IF conditions on attributes are met
Attributes checked:
+--Subject (User)-------+ +--Resource-----------+
| department: 'eng' | | owner: 'alice' |
| clearance: 'secret' | | classification: 'internal' |
| location: 'US' | | department: 'eng' |
| role: 'senior_eng' | | created: '2024-01-01'|
+-----------------------+ +---------------------+
+--Action--------+ +--Environment--------+
| type: 'edit' | | time: '14:30' |
+----------------+ | ip: '10.0.0.0/8' |
| device: 'corporate' |
+---------------------+
Example Policies:
Policy 1 (Healthcare - HIPAA):
ALLOW read patient_record
IF user.role = 'doctor'
AND user.department = resource.department
AND environment.network = 'hospital_internal'
AND user.has_signed_hipaa = true
Policy 2 (Finance - SOX compliance):
ALLOW approve transaction
IF user.role IN ['manager', 'director']
AND transaction.amount < user.approval_limit
AND user.id != transaction.creator_id (separation of duties)
AND environment.time BETWEEN '09:00' AND '17:00'
Policy 3 (Multi-tenant SaaS):
ALLOW access resource
IF user.tenant_id = resource.tenant_id (tenant isolation)
AND user.subscription_tier >= resource.required_tierRBAC vs ABAC Decision Matrix
When to Use What:
Criteria RBAC ABAC
------------------- --------------------- -------------------------
Permission model Static roles Dynamic attribute rules
Complexity Low High
Audit trail Easy (who has what) Hard (why was it allowed?)
Scalability Roles can explode Scales with attributes
Implementation time Days Weeks to months
Maintenance Add/remove roles Update policy engine
Best for Internal tools, SaaS Healthcare, finance, gov
Example Viewer/Editor/Admin HIPAA, SOX, GDPR rules
Role Explosion Problem (why RBAC breaks down):
Start: admin, editor, viewer (3 roles)
Add regions: us_admin, eu_admin, us_editor... (6 roles)
Add departments: us_eng_admin, eu_sales_viewer... (18 roles)
Add projects: us_eng_projectA_admin... (54+ roles)
ABAC solves this with: user.region + user.dept + resource.project
3 attributes replace 54 roles.
Hybrid Approach (recommended for most apps):
RBAC for: broad access tiers (free/pro/enterprise)
ABAC for: resource-level rules (own resources, same tenant)
Example: user.role = 'editor' AND resource.owner_id = user.idImplementation Patterns
Middleware pattern: check permissions before the request reaches your handler. Fail early, fail fast.
Policy-as-code: define policies in a dedicated language (OPA/Rego, Cedar, Casbin). Separate policy from application code.
Centralized policy service: one service evaluates all authorization decisions. Microservices call it for every request.
JWT claims: embed roles/permissions in JWT tokens for stateless RBAC. Avoid for ABAC (too many attributes).
PostgreSQL RLS: row-level security enforces tenant isolation at the database level. Even SQL injection cannot cross tenants.
Interview Tip
Authorization comes up in every multi-tenant or enterprise system design. Start with RBAC for simplicity - draw the user-role-permission relationship. Then explain when RBAC breaks down (role explosion with 50+ combinations of region, department, and project). Introduce ABAC as the solution: evaluate user attributes, resource attributes, and environment attributes against policies. Mention OPA (Open Policy Agent) as the industry-standard policy engine. For multi-tenant SaaS, always mention PostgreSQL Row-Level Security as the database-level enforcement that prevents cross-tenant data access even if application code has bugs.
Key Takeaway
RBAC groups permissions into roles - simple, auditable, and works for most applications. ABAC evaluates dynamic policies based on attributes of user, resource, action, and environment - powerful but complex. Most production systems use a hybrid: RBAC for broad access tiers, ABAC for fine-grained resource-level rules. Start simple with RBAC, add ABAC only when role explosion demands it.