# Permissions by Role > Which Kanvas actions are checked against a permission, which default role grants each permission, what anonymous users can do, and which actions are limited by mode and ownership instead. This page tells you which Kanvas actions require a permission, which default roles grant each permission, and which actions are limited by something other than a permission. Use it to find out why an action is missing for a user and which role grants it. ## How permissions work A permission is a named key, such as Deploy Design, that allows one action. Keys are grouped into keychains, and a role bundles one or more keychains. Your organization assigns roles to users. Before Kanvas offers certain actions, it checks whether the user holds the matching key. Kanvas uses the shared Layer5 permission set and defines no permissions of its own. See [Roles](/cloud/concepts/identity-and-security/roles/) and [Keychains](/cloud/concepts/identity-and-security/keychains/). ## Where Kanvas checks a permission Kanvas checks a permission before it offers each of the following actions: | Action | Permission checked | Also note | |---|---|---| | Validate and Dry run | Validate Design | One permission controls both actions. Disabled while the design is empty. | | Deploy | Deploy Design | Disabled while the design is empty. | | Undeploy | Undeploy Design | Disabled while the design is empty. | | Share | Share Design | Also hidden while the design is empty or published. | | Publish | Publish Design | Anonymous users get a sign-in prompt instead. | | Operator mode | None | The provider enables Operator mode. When the provider does not enable it, the Operator switch is disabled. | When a user does not hold the permission, Kanvas does not offer the action: the toolbar hides it or shows it disabled, and the action sheet on small screens omits it. Layer5 Cloud also enforces permissions when it receives a request, independently of the Kanvas interface. It checks Share Design when a design is shared, View Designs when a user reads other members' private designs, the workspace permissions when designs or views are assigned to or removed from a workspace, and Share Views when a view is shared. ## Default role access The tables below show which default roles grant each design and view permission. They are refreshed automatically from the Layer5 permission list. - A check mark means the role grants the permission. - A check mark with an asterisk means the role grants the permission only on resources the user owns. - A dash means the role does not grant the permission.
Design lifecycle
Permission What it allows UserTeam AdminWorkspace AdminOrg AdminProvider Admin
Validate Design Validate a design Allowed Allowed Allowed Allowed Allowed
Deploy Design Deploy a design Not granted Not granted Allowed Allowed Allowed
Undeploy Design Retract all resources used in a Meshery design from the cluster Not granted Not granted Allowed Allowed Allowed
Share Design Share design with anyone within your organization, and make your design easily accessible to all relevant team members. Allowed Allowed Allowed Allowed Allowed
Publish Design Publish a design Allowed Allowed Allowed Allowed Allowed
Unpublish Design Unpublish a design Allowed on resources the user owns Allowed on resources the user owns Allowed Allowed Allowed
Clone Design Clone any published design to customise it according to your use cases Allowed Allowed Allowed Allowed Allowed
View Designs View all public and published designs of other team members and private of signed-in user Allowed Allowed Allowed Allowed Allowed
Assign Designs to Workspaces Assign designs to workspaces Not granted Not granted Allowed Allowed Allowed
Remove Designs from Workspaces Remove designs from workspaces Not granted Not granted Allowed Allowed Allowed
Views and clusters
Permission What it allows UserTeam AdminWorkspace AdminOrg AdminProvider Admin
View Views See all views within a workspace Allowed Allowed Allowed Allowed Allowed
Assign Views to Workspace Add new views to workspace Not granted Not granted Allowed Allowed Allowed
Unassign Views from Workspace Remove views from workspace Not granted Not granted Allowed Allowed Allowed
Add cluster Add Kubernetes cluster Not granted Not granted Allowed Allowed Allowed
View All Kubernetes Clusters View all configured Kubernetes clusters Allowed Allowed Allowed Allowed Allowed
Org Admin is the Organization Admin role. The roles not shown, Org Billing Manager and the Academy roles, hold none of these permissions. Provider Admin holds every permission. ## Anonymous users A user is anonymous when no one is signed in or the signed-in account has anonymous status. An anonymous user authors and edits designs. Sharing or publishing a design opens a sign-in prompt that names the feature and offers a single Sign in action. Anonymous users receive the anonymous role. It holds the same canvas permissions as the User role, plus Screenshot Canvas and View help center. It does not hold the Operator terminal, metrics, or component details permissions. On [kanvas.new](https://kanvas.new), Validate, Dry run, Deploy, Undeploy, connecting a cluster, and Operator mode open a prompt that directs the user to the [Meshery Playground](https://playground.meshery.io) or a self-hosted Meshery deployment. This applies to signed-in users on kanvas.new as well. See [Feature Availability by Plan](/kanvas/reference/feature-availability/). ## What is not gated per action ### Canvas editing Kanvas does not check a permission for individual canvas edits: adding, deleting, cloning, copying, locking, and styling components, shapes, text boxes, sections, and comments; undo and redo; and the pen and pencil tools. Roles carry permissions with these names, but removing them from a role does not prevent the edit. Three things limit canvas editing instead: - **Mode.** Designer mode allows authoring. Operator mode does not. - **Node kind.** Live nodes, the resources Kanvas reads from a connected cluster, are read-only in every mode. - **Design ownership and sharing.** A user edits a design they own or one that is shared with them. ### Operator mode Operator mode blocks canvas authoring: dropping, editing, duplicating, deleting, and renaming nodes are not allowed. Operator mode is not read-only, though. From Operator, a user still opens terminal and exec sessions and generates load. ### Terminal, log streaming, and performance tests The Kanvas interface does not check a permission before it opens a terminal session, streams container logs, or runs a performance test. Layer5 Cloud defines the permissions Stream container logs, Perform performance test in Operator, and Select performance profile in Operator. By default, only Organization Admin and Provider Admin hold them. ## Customizing access Enterprise plans can define custom roles built from keychains, so you can grant a group exactly the permissions it needs, such as Validate Design without Deploy Design. In the Kanvas interface, a custom role changes what is offered only for the actions listed in [Where Kanvas checks a permission](#where-kanvas-checks-a-permission); Layer5 Cloud applies its own checks to sharing, private designs, and workspace assignments. See [Roles](/cloud/concepts/identity-and-security/roles/).