Authorization
Ubicloud’s authorization system is designed to be easy to use for simple cases, while still giving you full control over what actions your users can perform in the system.
Transparent By Default
Every project in Ubicloud uses Ubicloud’s access control system. Even if you are the only account with access to the project, all actions you take in the system are checked by the access control system to see if they are allowed. This is transparent by default, because the account that creates the project is made an admin of the project, and project admins are allowed to take any action on any object in the project.
User Management
When you create a project, you are the sole user and admin of the project. From the users page, you can invite new and existing Ubicloud users to the project:
By default, users you invite to the project are invited as members of the project. Members have more limited access rights than admins. By default, members can take all actions on virtual machines, PostgreSQL databases, private subnets, firewalls, and load balancers. They can also setup GitHub Runners in the project, as well as view AI inference endpoints.
You can change access for users from during the invitation process, or at any point after inviting the user. On the user management page, you can choose from either Admin, Member, or No Access for users:
The per-user Admin/Member/No Access setting is sufficient for many projects. However, some projects need more control over access, and those can use the Access Control system for full control over access.
Access Control
The Access Control tab on the User Management page gives you full control to manage access to the system:
In order to use the access system properly, you need to understand how it works. All access control in Ubicloud boils down to the question of whether the subject has access to perform a particular action, on a particular object. Ubicloud stores such information in access control entries. Each access control entry for the project has a subject, action, and object.
Subjects are generally users, roles, or groups. Actions are either specific actions (such as Vm:view to view virtual machines), groups of actions, or all actions. Objects are either specific objects (such as a specific virtual machine), groups of objects, or all objects.
To group multiple subjects, actions, or objects, you use tags. Ubicloud has subject tags for grouping multiple subjects, action tags for grouping multiple actions, and object tags for grouping multiple objects.
By default, projects in Ubicloud have 2 access control entries:
- Members of the Admin subject tag (i.e. project admins) can perform all actions on all objects (this access control entry is not modifiable, but you can modify which users are in the Admin subject tag)
- Members of the Member subject tag (the default for invited users) can perform all actions in the Member action tag, on all objects.
The recommended way to manage access control in Ubicloud is to create appropriate subject tags, action tags, and object tags, and then using those tags, add the minimum number of access control entries for the access you want to enforce.
Example: Different Types of Administrators
Let’s say you have three groups:
- System Administrators
- Network Administrators
- Database Administrators
And you want to enforce the following access:
- System administrators only have access to virtual machines.
- Network administrators only have access to private subnets, firewalls, and load balancers.
- Database administrators only have access to PostgreSQL databases.
We need to start by defining subject tags for these three groups. You can think of subject tags as groups or roles. On the Access Control page, click the “(Tags)” link next to Subject, to go to the Subject Tags page:
On this page, you can create the subject tags for each group by setting the tag name, and then clicking the Create button. Note that tag names cannot contain spaces, so you are recommended to use dashes instead of spaces:
After creating the three subject tags, you can click on the “Manage” button for the subject tag to go to the page to add or remove members of that tag:
Subject tags created by users have no members by default. After creating the subject tag, you should add the appropriate members to it. As you can see on the page, in addition to adding accounts to subject tags, you can add other subject tags to a subject tag. For example, if you make the Web-Server-Admins tag a member of the System-Admins tag, then all members of the Web-Server-Admins tag are considered members of the System-Admins tag. This works recursively, up to a configuable limit (32 levels by default).
In the “Add Members” table, you can check the box for any of the accounts or tags, and then click the “Add Members” button to add members:
That handles the subject tags. Action tags are handled similarly, but to make things easier to users, Ubicloud includes some default action tags (called global action tags) that are available in every project. There are global action tags for all actions you can take on a virtual machine (Vm:all), as well as for all actions you can take on a PostgreSQL database (Postgres:all). There are also global action tags for all actions you can take on private subjects (PrivateSubnet:all), firewalls (Firewall:all), and load balancers (LoadBalancer:all), but the network admins need a single tag that includes those three global tags.
Back on the Access Control page, lick on the “(Tags)” link next to Action, to go to the Action Tags page. Then add a Networking action tag:
Click on the Manage button. Then check the boxes for the PrivateSubnet:all, Firewall:all, and LoadBalancer:all global action tags:
Then click on the Add Members button on the button to add them to the tag:
Now that the subject and action tags have been setup, we can create the necessary access control entries. Back on the Access Control page, you can click the New Access Control Entry button three times to create three new, unsaved entries. On the access control form, changes are not made until you click the Save All button on the bottom right.
You can then populate the access control entries:
- Subject: System-Admins, Action: Vm:all, Object: All Objects
- Subject: Network-Admins, Action: Networking, Object: All Objects
- Subject: Database-Admins, Action: Postgres:all, Object: All Objects
Make sure to click the Save All button after populating the entries, to make sure they are saved.
Object Tags
The above example did not discuss the use of object tags, but they work similarly to subject and action tags, and allow you to grant users actions to specific objects (or more likely, groups of objects). For example, if you have both web servers and media encoding servers, and they are managed by different groups, you can create Web-Servers and Media-Encoding-Servers object tags, and create Web-Server-Admins and Media-Encoding-Server-Admins subject tags, and then create two access control entries:
- Subject: Web-Server-Admins, Action: All Actions, Object: Web-Servers
- Subject: Media-Encoding-Server-Admins, Action: All Actions, Object: Media-Encoding-Servers
Access Control for Your Access Control
Ubicloud’s access control system uses the access control system to ensure that only allowed access control changes are permitted. Project admins have full control over the access control system, but they can create access control entries granting other users more limited access.
For example, if only members of the Human-Resources subject tag should be adding or removing users from the Member subject tag, you could add an action tag named Tag-Membership, that contains the SubjectTag:add and SubjectTag:remove actions, and an access control entry:
- Subject: Human-Resources, Action: Tag-Membership, Object: Members (Subject Tag)
As you can see, a subject tag can be a member of an object tag, granting access to actions on that subject tag. An action tag can also be a member of an object tag, granting access to actions on that action tag. An object tag can be a member of an object tag, but this could potentially be ambiguous. If an object tag named Servers includes an object tag named Web-Servers, does that mean that members of Web-Servers are members of Servers, or does it means that actions on the Web-Servers tag are granted to members of the Servers tag? Ubicloud handles this by separating the inclusion, so you can choose when making an object tag a member of another object tag whether you want inclusion or access control (or both, as there are separate checkboxes for the two separate kinds of access).