Permissions Reference

This page provides a comprehensive reference of all available permissions in edgeContinuum. Permissions are used to control what users and groups can do within the platform and are organized by service and resource type.

Understanding Permissions

edgeContinuum uses a relationship-based access control (ReBAC) model where:

• Permissions are granted through role bindings that connect users or groups to roles
• Roles are collections of permissions that can be assigned at organization or project level
• Organization-level permissions can inherit to projects within that organization (marked with ✓ in the Inheritable column)
• Project-level permissions apply only to that specific project

In the console you assign permissions directly

Although access is modeled with roles and role bindings underneath, the console lets you grant access by selecting permissions for a user or group at a given scope. The platform manages the corresponding roles for you, so you do not create or name roles yourself in the UI.

Scope Levels

• Org: Permission can be granted at the organization level (may inherit to projects)
• Project: Permission can be granted at the project level (applies only to that project)
• Org/Project: Permission can be granted at either level

Permission Implication

Some permissions are implied by a broader one. When a permission lists a parent in the Implied by column of the tables below, everyone who holds that parent automatically holds the child as well — you do not have to grant it separately.

For example, mvms_update implies the fine-grained virtual machine operations:

mvms_update
  ├─ mvms_power_update              (power on/off, reboot)
  ├─ mvms_resize_update             (resize)
  ├─ mvms_network_attachment_update (attach/detach NICs)
  ├─ mvms_monitoring_update         (metrics on/off)
  ├─ mvms_metadata_update           (rename, description)
  └─ mvms_action_update             (cancel/sync operations)

This gives you two ways to grant the same capability:

• Coarse: grant mvms_update to someone who should be able to change virtual machines in any way
• Fine: grant only mvms_power_update to someone who should be able to reboot a virtual machine but never resize it or touch its network

The same split applies to reads: every <resource>_get permission is a read bundle that implies a <resource>_metadata_get child covering only the plain "view details" endpoints — metadata, dependents, sharing information and action listings — alongside the children that hand out credentials or telemetry. Writes mirror it with a <resource>_metadata_update child that covers only renaming a resource or editing its description.

mks_get
  ├─ mks_metadata_get    (cluster details, dependents, action listings)
  ├─ mks_kubeconfig_get  (kubeconfig download, carries credentials)
  └─ mks_metrics_get     (cluster and node metrics)

Grant mks_metadata_get on its own when someone needs credential-free visibility: they can see the cluster and inspect its configuration, but cannot download its kubeconfig.

Implication only ever flows downwards, from parent to child. Holding a child permission never grants its parent or its siblings, so the fine-grained permissions are safe to hand out on their own.

Start coarse, then narrow

Grant the coarse permission for roles that own a resource end to end, and reach for the fine-grained children when you need to carve out a narrower job, such as an on-call rotation that may reboot virtual machines and read their logs but must not resize or delete them.

Permissions with no entry in the Implied by column stand on their own and must be granted explicitly.

Resource Manager Permissions

Resource manager permissions cover identity and access management: organizations, projects, members, groups, permission grants and quota.

Organizations

Permission	Scope	Inheritable	Implied by	Description
resourcemanager_organization_get	Org	✗	—	View organization details
resourcemanager_organization_update	Org	✗	—	Replace the organization settings
resourcemanager_organization_patch	Org	✗	—	Partially update the organization settings
resourcemanager_organization_delete	Org	✗	—	Delete the organization

Projects

Permission	Scope	Inheritable	Implied by	Description
resourcemanager_project_create	Org/Project	✓	—	Create a project in the organization
resourcemanager_project_get	Org/Project	✓	—	View project details
resourcemanager_project_list	Org/Project	✓	—	List projects
resourcemanager_project_update	Org/Project	✓	—	Replace a project's settings
resourcemanager_project_patch	Org/Project	✓	—	Partially update a project's settings
resourcemanager_project_delete	Org/Project	✓	—	Delete a project

Organization Members

Permission	Scope	Inheritable	Implied by	Description
resourcemanager_organization_member_add	Org	✗	—	Add a user to the organization
resourcemanager_organization_member_get	Org	✗	—	View an organization member
resourcemanager_organization_member_list	Org	✗	—	List organization members
resourcemanager_organization_member_remove	Org	✗	—	Remove a user from the organization

Groups

Groups are defined at the organization level and can then be granted permissions in the organization and in individual projects.

Permission	Scope	Inheritable	Implied by	Description
resourcemanager_group_create	Org	✗	—	Create a group
resourcemanager_group_get	Org	✗	—	View group details
resourcemanager_group_list	Org	✗	—	List groups
resourcemanager_group_update	Org	✗	—	Replace a group's settings
resourcemanager_group_patch	Org	✗	—	Partially update a group
resourcemanager_group_delete	Org	✗	—	Delete a group
resourcemanager_group_user_add	Org	✗	—	Add a user to a group
resourcemanager_group_user_list	Org	✗	—	List the members of a group
resourcemanager_group_user_delete	Org	✗	—	Remove a user from a group

Organization Permission Grants

These permissions control who can grant access to others at the organization level. Treat them as administrative: anyone holding them can widen their own team's access.

Permission	Scope	Inheritable	Implied by	Description
resourcemanager_organization_user_role_grant	Org	✗	—	Grant organization-level permissions to a user
resourcemanager_organization_user_role_revoke	Org	✗	—	Revoke a user's organization-level permissions
resourcemanager_organization_user_role_update	Org	✗	—	Change the organization-level permissions granted to a user
resourcemanager_organization_user_role_get	Org	✗	—	View the organization-level permissions granted to a user
resourcemanager_organization_user_role_list	Org	✗	—	List the organization-level permission grants of all users
resourcemanager_organization_group_role_grant	Org	✗	—	Grant organization-level permissions to a group
resourcemanager_organization_group_role_revoke	Org	✗	—	Revoke a group's organization-level permissions
resourcemanager_organization_group_role_update	Org	✗	—	Change the organization-level permissions granted to a group
resourcemanager_organization_group_role_get	Org	✗	—	View the organization-level permissions granted to a group
resourcemanager_organization_group_role_list	Org	✗	—	List the organization-level permission grants of all groups

Project Permission Grants

Permission	Scope	Inheritable	Implied by	Description
resourcemanager_project_user_role_grant	Org/Project	✓	—	Grant project permissions to a user
resourcemanager_project_user_role_revoke	Org/Project	✓	—	Revoke a user's project permissions
resourcemanager_project_user_role_update	Org/Project	✓	—	Change the project permissions granted to a user
resourcemanager_project_user_role_get	Org/Project	✓	—	View the project permissions granted to a user
resourcemanager_project_user_role_list	Org/Project	✓	—	List the project permission grants of all users
resourcemanager_project_group_role_grant	Org/Project	✓	—	Grant project permissions to a group
resourcemanager_project_group_role_revoke	Org/Project	✓	—	Revoke a group's project permissions
resourcemanager_project_group_role_update	Org/Project	✓	—	Change the project permissions granted to a group
resourcemanager_project_group_role_get	Org/Project	✓	—	View the project permissions granted to a group
resourcemanager_project_group_role_list	Org/Project	✓	—	List the project permission grants of all groups

Quota

Permission	Scope	Inheritable	Implied by	Description
resourcemanager_organization_quota_get	Org	✗	—	View the organization's quota limits and current usage
resourcemanager_organization_quota_profile_get	Org	✗	—	View the organization's quota profile
resourcemanager_organization_quota_profile_register	Org	✗	—	Register a quota profile for the organization
resourcemanager_organization_quota_profile_update	Org	✗	—	Update the organization's quota profile
resourcemanager_organization_quota_profile_deregister	Org	✗	—	Deregister the organization's quota profile

Infrastructure Permissions

Infrastructure permissions cover the physical and provider-side layer of the platform: regions, zones, infrastructures, their image and flavor catalogs, and the service configs that back managed services.

Regions

Permission	Scope	Inheritable	Implied by	Description
region_create	Org	✗	—	Create a region
region_get	Org	✗	—	Full read access to a region. Implies region_metadata_get
region_list	Org	✗	—	List regions
region_update	Org	✗	—	Update a region. Implies region_metadata_update
region_delete	Org	✗	—	Delete a region
region_metadata_get	Org	✗	region_get	Read the plain region details: metadata, dependents and action listings
region_metadata_update	Org	✗	region_update	Rename a region or edit its description

Zones

Permission	Scope	Inheritable	Implied by	Description
zone_create	Org	✗	—	Create a zone
zone_get	Org	✗	—	Full read access to a zone. Implies zone_metadata_get
zone_list	Org	✗	—	List zones
zone_update	Org	✗	—	Update a zone. Implies zone_metadata_update
zone_delete	Org	✗	—	Delete a zone
zone_metadata_get	Org	✗	zone_get	Read the plain zone details: metadata, dependents and action listings
zone_metadata_update	Org	✗	zone_update	Rename a zone or edit its description

Infrastructures

Permission	Scope	Inheritable	Implied by	Description
infra_create	Org	✗	—	Create an infrastructure
infra_get	Org	✗	—	Full read access to an infrastructure, including provider discovery and preflight introspection. Implies infra_metadata_get
infra_list	Org	✗	—	List infrastructures
infra_update	Org	✗	—	Update an infrastructure. Implies every fine-grained infrastructure permission below, plus the image and flavor catalog permissions
infra_delete	Org	✗	—	Delete an infrastructure
infra_metadata_get	Org	✗	infra_get	Read the plain infrastructure details: metadata, dependents and action listings, without the provider discovery and preflight introspection
infra_credentials_update	Org	✗	infra_update	Rotate the credentials used to reach the infrastructure provider
infra_action_update	Org	✗	infra_update	Create actions (cancel, sync) on infrastructure operations
infra_storage_update	Org	✗	infra_update	Edit the storage configuration: offered volume types and the default volume type
infra_network_config_update	Org	✗	infra_update	Edit the network configuration: DNS nameservers and the load balancer provider
infra_shards_update	Org	✗	infra_update	Edit which shards may manage the infrastructure
infra_metadata_update	Org	✗	infra_update	Rename an infrastructure or edit its description and location

Images

Images are read at organization and project level, because projects need them to create virtual machines and clusters. Changing the catalog is an organization-level infrastructure task.

Permission	Scope	Inheritable	Implied by	Description
image_get	Org/Project	✓	—	View image details
image_list	Org/Project	✓	—	List images
image_import	Org	✗	infra_update	Import image entries from the provider catalog
image_update	Org	✗	infra_update	Patch or delete image catalog entries

Flavors

Permission	Scope	Inheritable	Implied by	Description
flavor_get	Org/Project	✓	—	View flavor details
flavor_list	Org/Project	✓	—	List flavors
flavor_import	Org	✗	infra_update	Import flavor entries from the provider catalog
flavor_update	Org	✗	infra_update	Patch or delete flavor catalog entries

Service Configs and Service Platforms

Service configs group the service platforms that back managed services on an infrastructure. Managing a config's service platforms (including org-owned managed clusters) is gated by service_config_update.

Permission	Scope	Inheritable	Implied by	Description
service_config_create	Org	✗	—	Create a service config
service_config_get	Org	✗	—	Full read access to a service config. Implies service_config_metadata_get
service_config_list	Org	✗	—	List service configs
service_config_update	Org	✗	—	Update a service config and manage its service platforms. Implies service_platform_update
service_config_delete	Org	✗	—	Delete a service config
service_config_metadata_get	Org	✗	service_config_get	Read the plain service config details: metadata, dependents and action listings
service_config_metadata_update	Org	✗	service_config_update	Rename a service config or edit its description
service_platform_update	Org	✗	service_config_update	Manage a service platform. Implies the platform upgrade and enable/disable permissions below
service_platform_upgrade_update	Org	✗	service_platform_update	Upgrade a service platform
service_platform_enabled_update	Org	✗	service_platform_update	Enable or disable a service platform

Managed Services Permissions

Managed services permissions control access to Kubernetes clusters, virtual machines and PostgreSQL instances. Each service exposes coarse lifecycle permissions plus fine-grained children for individual day-2 operations and for reads that expose credentials or telemetry.

Managed Kubernetes Service (MKS)

Permission	Scope	Inheritable	Implied by	Description
mks_create	Org/Project	✓	—	Create a Kubernetes cluster
mks_get	Org/Project	✓	—	Full read access to a cluster. Implies the metadata, kubeconfig and metrics reads below
mks_list	Org/Project	✓	—	List clusters
mks_update	Org/Project	✓	—	Update a cluster. Implies every day-2 cluster operation below
mks_delete	Org/Project	✓	—	Delete a cluster
mks_metadata_get	Org/Project	✓	mks_get	Read the plain cluster details: metadata, dependents and action listings, without the kubeconfig
mks_kubeconfig_get	Org/Project	✓	mks_get	Download the cluster kubeconfig, which carries cluster credentials
mks_metrics_get	Org/Project	✓	mks_get	Read cluster and node metrics
mks_action_update	Org/Project	✓	mks_update	Create actions (cancel, sync) on cluster operations
mks_controlplane_upgrade_update	Org/Project	✓	mks_update	Upgrade the control plane Kubernetes version
mks_controlplane_resize_update	Org/Project	✓	mks_update	Resize the control plane: compute flavor and/or replica count
mks_csi_update	Org/Project	✓	mks_update	Manage the cluster CSI (storage) configuration
mks_nodepool_scale_update	Org/Project	✓	mks_update	Scale a node pool
mks_nodepool_upgrade_update	Org/Project	✓	mks_update	Upgrade a node pool's Kubernetes version
mks_monitoring_update	Org/Project	✓	mks_update	Enable or disable the cluster's end-user metrics
mks_metadata_update	Org/Project	✓	mks_update	Rename a cluster or edit its description

Managed VM Service (MVMS)

Permission	Scope	Inheritable	Implied by	Description
mvms_create	Org/Project	✓	—	Create a virtual machine
mvms_get	Org/Project	✓	—	Full read access to a VM. Implies the metadata, logs, console and metrics reads below
mvms_list	Org/Project	✓	—	List virtual machines
mvms_update	Org/Project	✓	—	Update a VM. Implies every fine-grained VM operation below
mvms_delete	Org/Project	✓	—	Delete a virtual machine
mvms_power_update	Org/Project	✓	mvms_update	Power a VM on or off, and reboot it
mvms_resize_update	Org/Project	✓	mvms_update	Resize a VM
mvms_network_attachment_update	Org/Project	✓	mvms_update	Attach, detach and modify a VM's network interfaces
mvms_action_update	Org/Project	✓	mvms_update	Create actions (cancel, sync) on VM operations
mvms_monitoring_update	Org/Project	✓	mvms_update	Enable or disable the VM's end-user metrics
mvms_metadata_update	Org/Project	✓	mvms_update	Rename a VM or edit its description
mvms_metadata_get	Org/Project	✓	mvms_get	Read the plain VM details: metadata, dependents and action listings, without the console
mvms_logs_get	Org/Project	✓	mvms_get	Read VM logs
mvms_console_get	Org/Project	✓	mvms_get	Access the VM console
mvms_metrics_get	Org/Project	✓	mvms_get	Read VM metrics

VM Snapshots

Snapshots are managed as their own resource, so their permissions are independent of the VM permissions above.

Permission	Scope	Inheritable	Implied by	Description
mvms_snapshot_create	Org/Project	✓	—	Create a VM snapshot
mvms_snapshot_get	Org/Project	✓	—	View snapshot details
mvms_snapshot_list	Org/Project	✓	—	List a VM's snapshots
mvms_snapshot_update	Org/Project	✓	—	Update a snapshot
mvms_snapshot_delete	Org/Project	✓	—	Delete a snapshot

Managed PostgreSQL Service

Permission	Scope	Inheritable	Implied by	Description
postgresql_instance_create	Org/Project	✓	—	Create a PostgreSQL instance
postgresql_instance_get	Org/Project	✓	—	Full read access to an instance. Implies the metadata, connection and metrics reads below
postgresql_instance_list	Org/Project	✓	—	List PostgreSQL instances
postgresql_instance_update	Org/Project	✓	—	Update an instance. Implies every fine-grained instance operation below
postgresql_instance_delete	Org/Project	✓	—	Delete a PostgreSQL instance
postgresql_instance_metadata_get	Org/Project	✓	postgresql_instance_get	Read the plain instance details: metadata, dependents and action listings, without the connection information
postgresql_instance_connection_get	Org/Project	✓	postgresql_instance_get	Read the instance connection information, including database credentials
postgresql_instance_metrics_get	Org/Project	✓	postgresql_instance_get	Read instance metrics
postgresql_instance_action_update	Org/Project	✓	postgresql_instance_update	Create actions (cancel, sync) on instance operations
postgresql_instance_resize_update	Org/Project	✓	postgresql_instance_update	Resize an instance: compute size, storage (grow-only) and high availability
postgresql_instance_upgrade_update	Org/Project	✓	postgresql_instance_update	Upgrade the instance's PostgreSQL version
postgresql_instance_monitoring_update	Org/Project	✓	postgresql_instance_update	Enable or disable the instance's end-user metrics
postgresql_instance_metadata_update	Org/Project	✓	postgresql_instance_update	Rename an instance or edit its description

Networking Permissions

Networking permissions cover the network resources that managed services attach to, plus the SSH keys used to reach virtual machines. Import permissions adopt resources that already exist on the infrastructure provider, and share permissions control whether a resource can be offered to other projects in the organization.

Networks

Permission	Scope	Inheritable	Implied by	Description
network_create	Org/Project	✓	—	Create a network
network_get	Org/Project	✓	—	Full read access to a network. Implies network_metadata_get
network_list	Org/Project	✓	—	List networks
network_update	Org/Project	✓	—	Update a network. Implies every fine-grained network operation below
network_delete	Org/Project	✓	—	Delete a network
network_import	Org/Project	✓	—	Adopt an existing network from the infrastructure provider
network_share	Org/Project	✓	—	Manage sharing of a network with other projects
network_metadata_get	Org/Project	✓	network_get	Read the plain network details: metadata, dependents, sharing information and action listings
network_action_update	Org/Project	✓	network_update	Create actions (cancel, sync) on network operations
network_dhcp_update	Org/Project	✓	network_update	Edit the network's DHCP configuration (allocation pools, DNS servers, gateway, static routes)
network_metadata_update	Org/Project	✓	network_update	Rename a network or edit its description

Routers

Permission	Scope	Inheritable	Implied by	Description
router_create	Org/Project	✓	—	Create a router
router_get	Org/Project	✓	—	Full read access to a router. Implies router_metadata_get
router_list	Org/Project	✓	—	List routers
router_update	Org/Project	✓	—	Update a router. Implies every fine-grained router operation below
router_delete	Org/Project	✓	—	Delete a router
router_metadata_get	Org/Project	✓	router_get	Read the plain router details: metadata, dependents and action listings
router_route_update	Org/Project	✓	router_update	Manage the routes of a router
router_network_attachment_update	Org/Project	✓	router_update	Attach and detach networks on a router
router_action_update	Org/Project	✓	router_update	Create actions (cancel, sync) on router operations
router_metadata_update	Org/Project	✓	router_update	Rename a router or edit its description

Firewalls

Permission	Scope	Inheritable	Implied by	Description
firewall_create	Org/Project	✓	—	Create a firewall
firewall_get	Org/Project	✓	—	Full read access to a firewall. Implies firewall_metadata_get
firewall_list	Org/Project	✓	—	List firewalls
firewall_update	Org/Project	✓	—	Update a firewall. Implies every fine-grained firewall operation below
firewall_delete	Org/Project	✓	—	Delete a firewall
firewall_import	Org/Project	✓	—	Adopt an existing firewall from the infrastructure provider
firewall_share	Org/Project	✓	—	Manage sharing of a firewall with other projects
firewall_metadata_get	Org/Project	✓	firewall_get	Read the plain firewall details: metadata, dependents, sharing information and action listings
firewall_action_update	Org/Project	✓	firewall_update	Create actions (cancel, sync) on firewall operations
firewall_rules_update	Org/Project	✓	firewall_update	Edit the firewall's ruleset
firewall_metadata_update	Org/Project	✓	firewall_update	Rename a firewall or edit its description

SSH Keys

Permission	Scope	Inheritable	Implied by	Description
sshkey_create	Org/Project	✓	—	Create or upload an SSH key
sshkey_get	Org/Project	✓	—	Full read access to an SSH key. Implies sshkey_metadata_get
sshkey_list	Org/Project	✓	—	List SSH keys
sshkey_update	Org/Project	✓	—	Update an SSH key
sshkey_delete	Org/Project	✓	—	Delete an SSH key
sshkey_import	Org/Project	✓	—	Adopt an existing SSH key from the infrastructure provider
sshkey_share	Org/Project	✓	—	Manage sharing of an SSH key with other projects
sshkey_attach	Org/Project	✓	—	Attach an SSH key to a VM when creating it
sshkey_metadata_get	Org/Project	✓	sshkey_get	Read the plain SSH key details: metadata, dependents, sharing information and action listings

Application Orchestration Permissions

Application orchestration permissions control access to managed application resources through the Edge Orchestrator (MEO).

Application Templates

Permission	Scope	Inheritable	Implied by	Description
meo_application_template_get	Org/Project	✓	—	View an application template
meo_application_template_list	Org/Project	✓	—	List application templates
meo_application_template_create	Org/Project	✓	—	Create an application template
meo_application_template_update	Org/Project	✓	—	Replace an application template
meo_application_template_patch	Org/Project	✓	—	Partially update an application template
meo_application_template_delete	Org/Project	✓	—	Delete an application template

Application Instances

Permission	Scope	Inheritable	Implied by	Description
meo_application_instance_get	Org/Project	✓	—	View an application instance
meo_application_instance_list	Org/Project	✓	—	List application instances
meo_application_instance_create	Org/Project	✓	—	Create an application instance
meo_application_instance_update	Org/Project	✓	—	Replace an application instance
meo_application_instance_patch	Org/Project	✓	—	Partially update an application instance
meo_application_instance_delete	Org/Project	✓	—	Delete an application instance

Application Clusters

Permission	Scope	Inheritable	Implied by	Description
meo_application_cluster_get	Org/Project	✓	—	View an application cluster
meo_application_cluster_list	Org/Project	✓	—	List application clusters
meo_application_cluster_create	Org/Project	✓	—	Create an application cluster
meo_application_cluster_update	Org/Project	✓	—	Replace an application cluster
meo_application_cluster_patch	Org/Project	✓	—	Partially update an application cluster
meo_application_cluster_delete	Org/Project	✓	—	Delete an application cluster
meo_application_cluster_getfleet	Org/Project	✓	—	View the fleet a cluster belongs to

Cluster Fleets

Permission	Scope	Inheritable	Implied by	Description
meo_application_clusterfleet_get	Org/Project	✓	—	View a cluster fleet
meo_application_clusterfleet_list	Org/Project	✓	—	List cluster fleets
meo_application_clusterfleet_create	Org/Project	✓	—	Create a cluster fleet
meo_application_clusterfleet_update	Org/Project	✓	—	Replace a cluster fleet
meo_application_clusterfleet_patch	Org/Project	✓	—	Partially update a cluster fleet
meo_application_clusterfleet_delete	Org/Project	✓	—	Delete a cluster fleet
meo_application_clusterfleet_addcluster	Org/Project	✓	—	Add a cluster to a fleet
meo_application_clusterfleet_removecluster	Org/Project	✓	—	Remove a cluster from a fleet

Cluster Fleet Instances

Permission	Scope	Inheritable	Implied by	Description
meo_application_clusterfleetinstance_get	Org/Project	✓	—	View a cluster fleet instance
meo_application_clusterfleetinstance_list	Org/Project	✓	—	List cluster fleet instances
meo_application_clusterfleetinstance_create	Org/Project	✓	—	Create a cluster fleet instance
meo_application_clusterfleetinstance_patch	Org/Project	✓	—	Partially update a cluster fleet instance
meo_application_clusterfleetinstance_delete	Org/Project	✓	—	Delete a cluster fleet instance

Stats and Billing Permissions

These read-only organization permissions back the dashboards and the billing views. They expose aggregate counts and usage, not the resources themselves.

Permission	Scope	Inheritable	Implied by	Description
resourcemanager_organization_stats_get	Org	✗	—	Read organization statistics: project, member and group counts
meo_organization_stats_get	Org	✗	—	Read application orchestration statistics for the organization
rex_stats_get	Org	✗	—	Read managed-resource statistics for the organization
billing_usage_get	Org	✗	—	Read the organization's usage and billing data

Permission Inheritance

Some organization-level permissions automatically apply to projects within that organization. This inheritance happens through the authorization model:

How Inheritance Works

Organization (acme-corp)
  └─ mks_get (inheritable ✓)

     ├─ Project A (backend-api)
     │  └─ Inherits: mks_get
     │
     └─ Project B (frontend-app)
        └─ Inherits: mks_get

When a user or group has an inheritable organization-level permission:

• They automatically have that permission in all projects
• Project-level permissions can still grant or restrict access further
• Permissions are checked through multiple paths: direct project grants, group membership, and organization inheritance

Inheritance and implication are different

Inheritance moves a permission you already hold down the scope hierarchy, from the organization to its projects. Implication derives other permissions from the one you hold, at the same scope. They combine: an inheritable parent granted at the organization level also gives you its implied children in every project.

Permission Resolution

When checking if a user can perform an action on a project, the system checks:

1. Direct role bindings on the project
2. Group memberships and their role bindings on the project
3. Organization-level role bindings (inherited permissions)
4. Organization-level group role bindings

The user has access if any of these paths grants the required permission.

Special Roles

Super Admin

The super_admin role has special access:

• Grants all available permissions through all_permissions
• Applies at organization level with full inheritance to projects
• Intended for organization owners and administrators

Best Practices

• Use groups for consistency: Assign permissions to groups for common job functions rather than to individual users, for easier management
• Apply least privilege: Grant only the permissions needed for users to perform their work
• Prefer fine-grained permissions for narrow jobs: When a role only needs one operation on a resource, grant the implied child instead of the coarse parent
• Guard credential-bearing reads: mks_kubeconfig_get and postgresql_instance_connection_get hand out working credentials, so grant them only where they are needed, and reach for <resource>_metadata_get when a role only needs to see the resource
• Watch the grant permissions: Anyone who can grant permissions to users or groups can widen access for the whole team, so treat those permissions as administrative
• Plan inheritance: Use organization-level inheritable permissions to establish baseline access, then use project-level permissions for fine-grained control
• Audit regularly: Review who has what permissions to ensure they align with current team structure and responsibilities
• Use meaningful group names: Choose group names that clearly describe their purpose (e.g., "project-viewer", "infrastructure-admin")