How access works
Every access decision on the platform answers two separate questions: what action is being performed, and where it applies. A user who can 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.
Understanding these two axes is enough to reason about almost everything in the IAM screen.
The two axes
- Permission — the action itself, written as a key such as
vm:powerorbackup:restore. It says what can be done, never to which resource. - Scope — the part of your tenant the permission applies to. 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.
Scope hierarchy
Scopes are nested, from broadest to narrowest:
PLATFORM › TENANT › CUSTOMER › VDC
A permission granted at one level applies to the levels below it, with one important exception described just below.
| Scope | What it covers | Needs a target |
|---|---|---|
| Platform | The whole platform, across every tenant. Reserved for EdgeX staff. | No |
| Tenant | Running the tenant itself: people, groups, customers, billing. | No |
| Customer | One customer, and every VDC that belongs to it. | Yes |
| VDC | One virtual datacenter. | Yes |
Platform and tenant cover an entire boundary, so they need no target. Customer and VDC apply to one specific object, so you pick which one when you grant them.
To act on a resource that lives in a VDC — a VM, a disk, a firewall rule, a backup — the permission has to be granted on that VDC, or on the customer that owns it. A grant at tenant scope is not enough, even though tenant sits higher in the hierarchy.
Tenant scope is for administering the tenant. Someone who also has to operate infrastructure needs a second assignment, on the customer or on the VDC.
Groups and direct grants
There are two ways a user ends up with a permission.
| Group | Direct grant | |
|---|---|---|
| What it is | A named set of permissions assigned to a user at a scope | A single permission given to one user at a scope |
| Use it for | Everyday access, anything more than one person needs | Exceptions and temporary access |
| Expires | Optional | Always — an expiry date is required |
| Revocable | Remove the assignment | Revoke the grant |
Groups are the normal path. A group bundles the permissions for a job — "operate the VDC", "manage customers" — and you assign that group to a user at a scope. The same group can be assigned to different people on different VDCs, which is what keeps the permission list manageable as the team grows.
Direct grants are the escape hatch, for when one person needs one extra permission for a short while. They must carry an expiry date in the future, so temporary access stays temporary instead of quietly becoming permanent. If you find yourself giving the same direct grant to several people, that is the signal to create a group instead.
Default groups
Every tenant comes with two ready-made groups:
| Group | Scope | For |
|---|---|---|
CUSTOMER-ADMIN | Customer | Everything inside one customer: 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 |
The two carry the same infrastructure permissions. CUSTOMER-ADMIN applies them across every VDC of its customer and adds full IAM management, so it is the group to assign to whoever runs a customer day to day.
A third group, PLATFORM-ADMIN, belongs to EdgeX staff and is not assignable inside your tenant.
You can create your own groups when neither of these fits.
Effective permissions
A user's effective permissions are everything they hold, from every group assignment and every direct grant, merged together — each one paired with the scope it came from.
Permissions only ever add up. Assigning 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 user can do, remove the assignment or grant that provides it.
The Permissions tab shows this merged view for any user, including where each permission 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 are split out into their own keys, 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:*includesstorage:viewandstorage:object_storage:bucket:deletealike. These are convenient, but they also pick up permissions added in future releases — prefer specific keys where the access matters.
When changes take effect
Permissions are read when you sign in and refreshed periodically while you work, so a change to someone's access is not always visible immediately. It applies on their next refresh, within about five minutes. Signing out and back in applies it right away.
If someone reports that access you just granted is not working, this is usually why.