What is IAM
IAM (Identity and Access Management) is where you decide who can do what on the platform. It is the screen where you invite people, group them by the job they do, and choose which part of your infrastructure each one reaches.
Every access decision answers two separate questions: what action is being performed, and where it applies. Someone allowed to restart a virtual machine in one VDC does not automatically get to restart one in another. The action and the place are granted together, and both have to match.
The two axes
- Permission is the action itself, written as a key such as
vm:powerorbackup:restore. It says what can be done, never to which resource. - Scope is the part of your infrastructure where that permission is valid. It says where.
Because the resource lives in the scope and not in the key, there is no such thing as a "view VM 42" permission. Letting someone see the VMs of a single VDC is the permission vm:view granted at the scope of that VDC.
Scopes
You work with two scopes, from broadest to narrowest:
| Scope | What it is |
|---|---|
| Customer | Your organization on the platform. This is the administrative level: the people on your team, billing, and access management itself. It is the broadest scope you have, and it covers every VDC below it. |
| VDC | A virtual datacenter, the cloud console where your infrastructure actually lives: machines, disks, networks, backups. |
A permission granted at customer level applies to every VDC of that customer. Granted on a single VDC, it applies only there.
Customer covers your whole organization, so it needs no target. VDC applies to one specific datacenter, so you pick which one when you grant it.
Groups and direct grants
There are two ways someone ends up with a permission.
| Group | Direct grant | |
|---|---|---|
| What it is | A named set of permissions, given to a person at a scope | A single permission, given to one person at a scope |
| Use it for | Everyday access, anything more than one person needs | Exceptions and temporary access |
| Expires | No | Always, an expiry date is required |
| How to remove | Remove the assignment | Revoke the grant |
Groups are the normal path. A group bundles the permissions for a job, such as operating a VDC, and you give that group to a person at a scope. The same group can be given to different people on different VDCs, which is what keeps the access list manageable as the team grows. Group access does not expire on its own: it lasts until someone removes it.
Direct grants are the escape hatch, for when one person needs one extra permission for a short while. They require an expiry date in the future, so temporary access stays temporary instead of quietly becoming permanent. If you find yourself giving the same grant to several people, that is the signal to create a group instead.
Default groups
Your organization comes with two ready-made groups:
| Group | Scope | For |
|---|---|---|
CUSTOMER-ADMIN | Customer | Everything in your organization: operating all of its VDCs, and managing the people who access them |
VDC-OPERATOR | VDC | Operating a single VDC (compute, storage, network, backup), with read-only access to IAM |
Both carry the same infrastructure permissions. CUSTOMER-ADMIN applies them across every VDC and adds full access management, so it is the group for whoever runs the operation day to day.
You can also create your own groups when neither fits.
Effective permissions
A person's effective permissions are everything they hold, from every group and every direct grant, merged together, each one paired with the scope it came from.
Permissions only ever add up. Giving a second group can widen someone's access but never narrow it, and there is no deny rule that takes a permission away. To reduce what a person can do, remove the group or revoke the grant that provides it.
The Permissions tab shows this merged view for any user, including where each item came from. It is the fastest way to answer "why can this person do that?".
Reading permission keys
Keys are written as section:resource:action, for example vm:snapshot:rollback. The first segment is the area of the product, and it matches the section in the sidebar where you find the feature.
A few conventions are worth knowing:
- Viewing is broad. A single
<section>:viewkey covers listing and reading everything in that section. Sensitive reads get their own key, such asvm:console:viewandiam:audit:view. - Destructive actions get their own key, so that
backup:restoreorvm:disk:destroycan be withheld from someone who otherwise operates the resource. - A key ending in
:*covers everything beneath it, at any depth.storage:*includes bothstorage:viewandstorage:object_storage:bucket:delete. Convenient, but it also picks up permissions added in future releases, so prefer specific keys where the access matters.
When changes take effect
Permissions are read at sign-in and refreshed periodically while someone works, so a change is not always visible immediately. It applies on the next refresh, within about five minutes. Signing out and back in applies it right away.
If someone says an access you just granted is not working, this is usually why.