Ubicloud is an open and portable cloud. When we started working on it, we looked at how Identity and Access Management (IAM) systems were implemented in the public cloud. We were surprised by the big bifurcation. Hyperscalers such as AWS, Azure, and GCP, had powerful authorization models. Other cloud and hosting providers only had authorization at the most basic level.

So, we set out to deliver something as powerful as the authorization systems seen on the hyperscalers. In particular, we came up with the following requirements:

• Correct - We can look at the authorization system and reason that it works correctly. Ideally, we can prove to ourselves that it works as expected.
• Flexible - You can define complex access policies. These policies can then provide granular access control between roles, attributes, and resources.
• Simple - Ideally, a developer can own and support the entirety of the system part-time. We primarily need users to be able to express complex relationships; and we’re happy to trade-off nice to have features.
  

So, I spent a week understanding our options for authorization. I decided to simplify our solution space and only provide attribute-based access control (ABAC). AWS, Azure, and GCP were already going in that direction.

With that understanding, I could build a simple authorization system example on PostgreSQL in a day. I could then implement our initial ABAC system in 130 lines of code. This blog shares that example, our design and implementation, and our approach’s pros and cons.

ABAC example

The following diagram describes a simple example, where the users on the left have associated “tags” (classic roles) and the resources on the right also have “tags”.

ABAC is a flexible way of implementing access control policies between users and resources. (This is a rather simplified view and we’ll come back to it later.) Since a user can hold different roles with an organization, our ABAC system allows creating different “tags” for the user.

Design and Implementation

Our ABAC design is almost entirely based on the above example. We represent our data model in 5 PostgreSQL tables. We then use one query to check if a user has permissions to access a resource.

There are only three things to be mindful of. First, ABAC is way more flexible than what we showed it to be. In the above example, we used “tags” to assign roles to a user and used those roles to grant permissions to resources. In ABAC, you can also define those permissions over attributes. In addition to roles, attributes can include things like a user’s location, client device type, or authentication method. Tailscale has a great blog post that describes various access control policies in more detail.

Second, ABAC uses slightly different terms than the example above. In ABAC terminology, the subject is the user requesting access to a resource to perform an action. The resource is the object (such as VM, simple storage bucket, or source file) that the subject wants to access. The action is what the user is trying to do with the resource. So, the triplet <user, action, resource> above is more generally represented as <subject, action, object> in our design.

Third, for clarity, all we need for authorization is the following SQL query. This query checks if a path exists from a subject (a user identified with one or more tags) to the object (a resource identified with one or more tags).

SELECT object_applied_tags.tagged_id, object_applied_tags.tagged_table, subjects, actions, objects
FROM accounts AS subject
   JOIN applied_tag AS subject_applied_tags ON subject.id = subject_applied_tags.tagged_id
   JOIN access_tag AS subject_access_tags ON subject_applied_tags.access_tag_id = subject_access_tags.id
   JOIN access_policy AS acl ON subject_access_tags.project_id = acl.project_id
   JOIN jsonb_to_recordset(acl.body->'acls') as items(subjects JSONB, actions JSONB, objects JSONB) ON TRUE
   JOIN access_tag AS object_access_tags ON subject_access_tags.project_id = object_access_tags.project_id
   JOIN applied_tag AS object_applied_tags ON object_access_tags.id = object_applied_tags.access_tag_id AND objects ? object_access_tags."name"
WHERE subject.id = :subject_id
   AND actions ?| array[:actions]
   AND subjects ? subject_access_tags."name"
   

Pros & Cons

As with all software, our design comes with tradeoffs. The nice thing about this ABAC design is that it meets our original requirements.

• Correct - The design has an existence proof. When you run the query, if it returns a tuple, the subject can access the object. If it doesn’t, the subject isn’t authorized. Further, you can see all access paths from the subject to the object by looking at the tuples the above query returns.
  
• Flexible - We can express all attribute-based access control policies with this one query, for user-defined tags.
• Simple - We get an ABAC implementation in 10 lines of SQL. In fact, the entire file that implements our authorization policy is 130 lines of code.

When building our design, we also looked at Google’s influential paper on authorization systems, Zanzibar. Compared to Zanzibar, our design has the following drawbacks.

• Scale - We run a SQL query for each authorization action. This solution will scale to the extent that a single PostgreSQL database can handle reads and writes. When Ubicloud reaches that scale, we’ll need to optimize our implementation or switch to a distributed solution.
• Global availability - Zanzibar uses a globally distributed Spanner cluster; and builds on it with additional protocols, serving clusters, and offline data processing systems. We use PostgreSQL. Without additional modifications, this gives us high availability in one region.

Conclusion