Roles and Permissions

This page tells you which permissions each default Layer5 Cloud role holds. Use it to find out why an action is missing for a user and which role grants it. For how roles, keychains, and permissions fit together, see Roles.

How permission checks work 🔗

A permission is a named key that allows one action, such as Create Team. A keychain groups keys, and a role groups keychains. Layer5 Cloud checks the key, never the role name. Before it runs a guarded action, Cloud resolves the organization the request names, then checks whether the user holds the key through a role in that organization. A user’s permissions are the union of the keys from every role the user holds there.

When a user lacks the key, Cloud refuses the request with HTTP 403 and the message “You do not hold the permission this action requires in this organization”. The response body is JSON with an error message and a code.

Provider Admin passes every permission check, in every organization.

Default roles 🔗

An anonymous user, someone using Kanvas without signing in, receives an internal Anonymous User role. It is not listed and cannot be assigned. See Permissions by Role for what anonymous users can do in Kanvas.

The Kanvas role holds no keychains. It makes the Kanvas extension available when a Meshery Server connects to Layer5 Cloud.

Reading the matrices 🔗

The matrices below are refreshed automatically from the Layer5 permission list.

• A check mark means the role holds the permission.
• A check mark with an asterisk means the role holds the permission only on resources the user owns.
• A dash means the role does not hold the permission.

The columns show the roles that hold permissions in the list. “Org Admin” is the Organization Admin role. Workspace Manager, Curator, Kanvas, and the Academy roles have no column; see Roles outside the matrices.

Designs and catalog 🔗

Teams 🔗

Organizations and roles 🔗

Workspaces, environments, and connections 🔗

Operator, performance, and settings 🔗

Roles outside the matrices 🔗

Default keychains 🔗

Each default keychain groups the permissions for one area. Roles hold keychains, so granting a keychain to a role grants every permission in it.

Layer5 Cloud also ships keychains for workspaces, environments, the catalog, lifecycle actions, extensions, settings, performance, views, collaboration, infrastructure, curation, the Academy, and the two Kanvas action sets (Designer Actions and Operator Actions). For keychain behavior, see Keychains.

What the matrices do not show 🔗

• Canvas editing. The permission list omits the per-edit Kanvas permissions, such as adding, deleting, and styling components. See Permissions by Role for which Kanvas actions check a permission.
• Provider Admin. It holds every permission, including permissions that are not in the list.
• Plan limits. A role grants a permission, and the plan decides whether the capability exists for the organization. See Feature Availability by Plan.

Custom roles 🔗

A custom role bundles keychains that the default roles do not combine. Only a Provider Admin can create, edit, or delete a custom role. On hosted Layer5 Cloud, Layer5 operates the Provider Admin role, so an organization cannot create custom roles itself. On a self-hosted deployment, the operator’s Provider Admins can.

Roles and keychains are defined for the whole Layer5 Cloud deployment, not per organization. Only a Provider Admin can create, edit, or delete a keychain, change its keys, or assign a keychain to a role. Changing the keychains of a role changes that role for every organization that uses it. See Roles.

Related Reading

• Permissions by Role
• Security Reference
• API Reference
• Assign and Manage Roles
• Build a Custom Keychain
• Cloud API