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.
Example: Different Types of Administrators
Let’s say you have three groups:- System Administrators
- Network Administrators
- Database Administrators
- 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.
- 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
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)