Users, Groups and Permissions¶

Access in edgeContinuum is managed per organization, in IAM & SECURITY > Organizations & projects. The building blocks:

Concept	What it is
Member	A user who accepted an invitation to the organization
Group	A set of members who share the same access
Permission	One capability, such as `mvms_power_update` (start and stop virtual machines)
Role	A named, reusable set of permissions, such as Cluster viewer
Grant	What a member or group holds on the organization or in one project: roles, individual permissions, or both

For creating and switching organizations and projects, see Organizations and Projects.

Owner and administrators¶

Owning an organization and administering it are different things:

The owner is the person who created the organization. Ownership can't be transferred, and the owner can't be removed from the organization.
Organization administrators are everyone who holds the organization's OrganizationAdmin role, which grants every permission in the organization and all its projects.

The owner holds OrganizationAdmin from the start and can never lose it, so an organization always has an administrator.

To make someone else an administrator, assign them the role, directly or through a group such as admins. Because the role is so powerful:

Only an administrator can assign it or take it away.
Only an administrator can change who is in a group that holds it, or delete that group. (Members of such a group are administrators through it.)
Only another administrator can remove an administrator from the organization.
It can't be edited, deleted or granted inside a project.

Members¶

Invite members¶

Open the organization and go to its Members tab.
Click Invite member and enter their email address.
Turn off Email them the invitation if you'd rather tell them yourself.
Click Send invitation.

You can invite someone who has no account yet: the invitation waits for them once they sign up with that address. Until they answer, they appear in Members as Invited; use the row's trash icon to cancel the invitation.

Invitations expire after 7 days unless your platform operator has set a different period. Each pending invitation takes a seat in the organization's users quota, just like a member does (the owner takes none). Declining, cancelling or expiry frees it.

Answer an invitation¶

Invitations sent to you are under My invitations in the Organizations & projects header; the sidebar shows a badge while any are pending. Click Accept or Decline. Once you accept, the organization appears in your list.

Give new members access¶

A new member starts with no access

Joining an organization grants no permissions. After someone accepts, give them a role, permissions, or a group membership before they can do anything.

The Needs access filter in Members shows everyone who holds no permission, role or group: usually someone whose invitation was accepted and then forgotten. To give someone the same access as a colleague, use Copy access.

Remove a member¶

Click Remove from organization on the member's page (or the trash icon on their row) and type their name to confirm. Removing a member also takes away, for good, everything they hold in the organization: their own permissions and roles on the organization and in every project, their group memberships and their pending invitations. An administrator can only be removed by another administrator.

Their seat is freed. You can't remove the owner.

Members can't leave an organization on their own: ask an organization administrator to remove you.

Groups¶

Groups let you grant the same access to several members at once. A group belongs to one organization, only its members can join, and a member can be in several groups. Everyone in a group holds what the group is granted, on the organization and in any project that grants the group access.

To create one, click New group in the organization's Groups tab, enter a name and optionally pick its first members. On the group's page:

Members: Add member adds an organization member; the trash icon removes one. They keep their own access but lose what the group gave them.
Organization permissions: Edit access gives the group roles, permissions or both.
Delete group revokes everything the group granted, on the organization and in every project. Its members keep their own access.

To give a group access in one project only, grant it on the project (see Project access).

Roles¶

A role is a named set of permissions you assign to many members and groups. When you edit a role, the change reaches everyone who holds it immediately, so define Developer once instead of picking the same permissions for each person.

The organization's Roles tab lists every role with its permission count, who holds it (Held by), and where it Can be used in. Its search also matches the permissions a role grants, which helps when a refusal names a permission you're missing.

Create a role¶

In the Roles tab, click New role and enter a name.
Pick the role's permissions. On a new role you can start from a template and adjust it:
- Viewer: every read permission.
- Developer: applications, Kubernetes clusters, virtual machines, PostgreSQL, SSH keys, images and sizes, plus every read permission.
- Network admin: networks, routers and firewalls, plus every read permission.
- Project admin: everything that can be granted inside a project.
Click Create role.

Templates include credential-bearing reads

Viewer, Developer and Network admin let holders read kubeconfigs, database credentials and VM consoles. See Credential-bearing reads.

The same three templates also include reads that exist only at organization level, so roles built from them are Organization only. A role that contains even one organization-only permission can be assigned on the organization but not inside a project; the role editor warns you when you add one. Project admin is the template meant for project grants, but it doesn't include the organization-level reads that create forms need; see Project access.

Assign a role¶

From the role: open it, click Assign role and pick members and groups. They hold the role on the organization straight away; its project-level permissions also apply in every project.
From a member or group: tick the role in the Roles tab of their access editor (see Organization access).
In a project: grant it in that project only (see Project access).

The role's Held by tab lists who holds it on the organization, with a trash icon to take it off them. Roles granted inside a project are listed on that project, not here.

Edit or delete a role¶

Edit permissions on the role's page changes the role for everyone who holds it, immediately. Delete role works only once nobody holds the role, on the organization or in any project: take it off its holders first, including project grants that use it.

Grant access¶

How access adds up¶

Access only ever adds up. What someone can do in a project is the combination of:

their own grant and their groups' grants on the organization, which reach every current and future project, and
their own grant and their groups' grants in that project,

plus every permission the roles in those grants contain. Nothing subtracts access: a project grant can't take away what the organization gives, and removing a project grant leaves inherited access in place. To limit someone to one project, grant their access in that project rather than on the organization.

There is no separate project membership: anyone in the organization whose access reaches a project can act in it. Permissions that exist only at organization level never apply inside a project. Each permission's scope is listed in the Permissions Reference.

Managing access needs the matching permissions; organization administrators have all of them.

Organization access¶

For a member: open them from Members and click Edit organization access.
For a group: open it, go to Organization permissions and click Edit access.

Pick permissions in the Permissions tab and roles in the Roles tab, then click Save. Saving with nothing selected revokes that member's or group's own organization grant; a member keeps whatever their groups and project grants give them. What a member gets through a group is changed on the group, not on the member.

Project access¶

Open the project from the organization's tree. Its Members and Groups tabs list everyone who can act in the project, marked Organization (inherited) or Granted here. To grant access in the project:

Click Add project permissions on Members, or Add project permissions to group on Groups.
Pick organization members or groups.
Choose roles, permissions, or both, and click Grant access. Roles that can't be used in a project, including OrganizationAdmin, are shown disabled.

To change a project grant, open the member (or group) from the project. Their page shows what is inherited and what is granted in the project, with Edit their project permissions and Remove project grant. Saving a project grant with nothing selected removes it.

Project-only members also need a few organization reads

Someone whose access comes only from project grants can't fill in the create and import forms: picking a region, zone, infrastructure or service config needs read permissions on the organization. See What project members typically need.

Copy access from a colleague¶

On the member's page, click Copy access from… and pick the colleague whose access is already right. The dialog shows what will be copied.
Optionally keep Also add them to… ticked to add the member to the colleague's groups too (this never removes group memberships).
Click Copy access.

Copying replaces the member's own organization roles and permissions with the colleague's. Check what the dialog shows before you confirm.

Check who can do what¶

The organization's Check access tab answers "what can this person do, and why?". Pick a member or group to see every permission they hold, grouped by area, with the grant each comes from (their own, a role, or a group). Search for a permission they don't hold to see why. The selection is kept in the page address, so you can share the link. Inside a project, the member's page shows the same for that project.

To look up what a permission does and where it can be granted, click Permission reference in the Roles tab, or see the Permissions Reference.

When an action is refused¶

A refused action tells you that you don't have permission; Show details on the message gives the platform's reason. Use Check access to see what is missing, and ask an organization administrator for it. A resource in a project you can't access is reported as not found, never as existing.

Sharing a network, firewall or SSH key with a project gives no one any permissions: people still need that resource type's own permissions in their project. See Sharing resources between projects.

Best practices¶

Grant roles to groups: create a role for each recurring job and assign it to a group, rather than picking permissions person by person. Give roles and groups names that describe their purpose.
Least privilege: grant only what people need. For narrow jobs, grant the fine-grained permission (for example mvms_power_update) instead of its parent.
Keep organization grants narrow: they reach every project, and project grants can't take them away. Grant broad access per project instead.
Guard secrets: keep credential-bearing reads out of read-only roles.
Grant detach and ownership deliberately: detaching leaves a resource running in your cloud but unmanaged, and ownership lets people delete imported resources.
Treat access-management permissions as administrative: anyone who can grant roles or permissions can widen access, their own included. Keep OrganizationAdmin to a small group.
Review regularly: check Needs access after inviting people, and use Check access when people change teams or leave.