Roles at a Glance¶
Pilvio.pro has three kinds of users. Which one you are decides what you see in the left menu and what you can change.
| Audience | Who they are | What they see |
|---|---|---|
| Cloud admin | The platform operator that runs Pilvio.pro | An extra Cloud admin menu group. It is described in the operator documentation and is not covered in these pages. |
| Admin | A user who holds the customer-admin role on a customer account (see Who does what after you sign up) | The Admin menu group, plus Software Licenses and Containerspaces, together with everything a role user sees |
| Role user | Anyone who got access to a customer account through a role | Locations, Cloudspaces, Objectspaces, Disks, vGPUs, Recycle bin, Spendings (listed, but opening it needs customer-admin access), Docs, APIs and IAM. They do not see the Admin group, Software Licenses or Containerspaces. |
One account, several customers
A user account can belong to several customers. The Welcome page lists every customer you belong to; select one to enter it. See First Login.
How an Admin gives access¶
An Admin decides who gets access to the customer's resources, and how much:
- Create a role. Go to Admin > Roles > Add role, enter a Name and a Description, and choose the role's permissions. See Roles & Permissions.
- Add people to the role. Inviting a user happens in IAM. Roles & Permissions shows where to start it.
- Grant the role access to resources. For example, from a cloudspace's MORE menu you can open Roles & permissions and use GRANT ROLE ACCESS.
- For automation, use a service account. A service account is attached to roles and gets exactly the permissions of those roles.
Authorization Required
Some Admin actions, such as adding a role or a service account, first show an Authorization Required dialog. It asks for the owner scope of your organization in IAM (user:ownerof:organization) before the portal continues. Approve it with AUTHORIZE.
What a role user can and cannot reach¶
The table below shows which areas a role user can read, and which are refused. It was checked with a service account that holds a read-only role.
| Area | Admin | Role user |
|---|---|---|
| Admin group (Certificate Store, Roles, Service Accounts, DNS, License Notifications, Audits, Credit cards, Billing, Emergency notifications, Backups, VDI) | Yes | No |
| Software Licenses | Yes | No |
| Containerspaces | Yes | No |
| Locations | Yes | Read |
| Cloudspaces | Yes | Read |
| Objectspaces | Yes | Read |
| Recycle bin | Yes | Read |
| Prices | Yes | Read |
| DNS records | Yes | Read |
| Backup targets and backup policies | Yes | Read |
| Certificates (Certificate Store) | Yes | Refused |
| DNS settings | Yes | Refused |
| VDI profiles | Yes | Refused |
| Backup workers | Yes | Refused |
| Audits | Yes | Refused |
| Roles | Yes | Refused |
| Service accounts | Yes | Refused |
"Read" means the area can be opened and listed. What a role user can do beyond reading, such as creating or changing resources, depends on the permissions of their role. The Admin chooses those permissions when adding the role.