RBAC in Gateway Manager

Gateway Manager’s role-based access control (RBAC) system lets administrators control access to gateway clusters, virtual clusters, services, and administrative functions — from broad cluster-level access down to specific service execution permissions.

RBAC components

Gateway Manager’s RBAC system operates on a permission-based model with these key components:

• Users — individual accounts within Itential Platform
• Groups — collections of users that share common access requirements
• Roles — specific permissions that define what actions can be performed
• Resources — gateway clusters, virtual clusters, services, service groups, and certificates that require access control

Learn more:

• For managing users, groups, and roles in on-premises Platform deployments, see Authorization.
• For Cloud deployments, see Manage roles and permissions.
• For creating and managing service groups, see Service groups.

Built-in roles

Gateway Manager provides the following built-in roles.

Resource management roles

Certificates:

• certificate:create — upload and create new certificates
• certificate:read — view certificate details and properties
• certificate:delete — remove certificates from Gateway Manager

Physical clusters:

• gateway:create — create new gateway clusters
• gateway:read — view gateway cluster details and associated services
• gateway:update — modify gateway cluster configuration and settings
• gateway:delete — remove gateway clusters

Service groups:

• service-group:create — create new service groups within gateways
• service-group:read — view service group details and membership
• service-group:update — modify service group configuration and service assignments
• service-group:delete — remove service groups

Service execution role

• service:run — execute gateway services during workflow orchestration

Access control model

Permission hierarchy

Gateway access is controlled through group membership and role assignments:

• Users can only access resources if they belong to a group with the appropriate role.
• The group must be explicitly assigned to the specific resource (gateway cluster, virtual cluster, or service group).
• Users with service:run can execute any services they have read access to.

Service access methods

1. Physical cluster access — gateway:read provides access to all services on that physical cluster.
2. Virtual cluster access — access to a virtual cluster provides implicit runtime access to all services on all member physical clusters. See RBAC on virtual clusters.
3. Service group access — provides granular control by limiting access to specific service subsets within a physical cluster.

For more information on configuring service groups, see Create a service group.

Implementation guide

Initial setup

Every gateway cluster includes a Default service group that:

• Contains all services discovered on the cluster
• Inherits all user groups assigned directly to the cluster

Minimum permissions for service execution: Groups need both service:run and gateway:read roles, plus assignment to the gateway cluster.

Implementing least-privilege access

To restrict users to specific services on a physical cluster:

1. Create a user group with the service:run role and add the relevant users.
2. Create a service group on the cluster containing only the required services.
3. Assign the user group to the service group — not directly to the cluster.

Result: Users see only the limited service subset and can execute only those services.

Organizational patterns

Team-based: Create a user group per team with a corresponding virtual cluster or service group scoped to that team’s clusters and services. Each team manages their own execution environment with no credential or service overlap.

Function-based: Organize service groups by business function, allowing multiple user groups to access the same functional services across clusters.

RBAC on virtual clusters

Virtual clusters use the same RBAC model as physical clusters, with one important distinction: the virtual cluster is the permission boundary, not the individual physical clusters that make up its membership.

How access works

Granting a user group access to a virtual cluster gives those users implicit runtime access to all services on all member physical clusters — including services on clusters that the user group couldn’t access by navigating to those physical clusters directly. This is intentional. The virtual cluster is the single point of access control, which eliminates the need to manage permissions separately on each member cluster.

Revoking a user group’s access to a virtual cluster immediately removes their implicit runtime access to all member clusters via that virtual cluster. Any direct physical cluster permissions the group holds are unaffected.

Cluster selection is RBAC-filtered

When creating or editing a virtual cluster, the cluster selection dropdowns surface only the physical clusters that the requesting user’s group has access to. Clusters outside the user’s group membership don’t appear in the list.

Adding members to a live virtual cluster

When you add a member cluster to a virtual cluster that’s already enabled, all users with access to the virtual cluster immediately gain implicit runtime access to the newly added cluster and its services. Gateway Manager displays a warning before you save the change.

Before adding a member to a live virtual cluster, verify that the cluster and its registered services are appropriate for every user group currently assigned to the virtual cluster.

For step-by-step procedures, see Create a virtual cluster.

Troubleshoot

Gateway access issues

Problem: A user can’t view a gateway cluster.

Solution:

1. Verify the user belongs to a group with the gateway:read role.
2. Confirm the group is assigned to the gateway cluster in the Access section of Gateway Manager.

Virtual cluster access issues

Problem: A user can’t see a virtual cluster in the cluster selection list.

Solution:

1. Verify the user belongs to a group assigned to the virtual cluster.
2. Confirm that the physical clusters in the virtual cluster are within the user’s group access — the cluster selection UI only surfaces clusters the requesting user can access.

Service execution issues

Problem: A user can’t run a specific service.

Solution:

1. Verify the user belongs to a group with the service:run role.
2. Confirm a service group includes the desired service.
3. Confirm the user’s group is assigned to that service group.

Security best practices

• Start minimal — begin with least privileges and add access as needed.
• Use service groups — prefer service group assignments over cluster-level access for most users.
• Review virtual cluster membership — when adding a member to a live virtual cluster, verify that its services are appropriate for every group currently assigned to that virtual cluster.
• Regular audits — review user group memberships and role assignments periodically.
• Limit administrators — restrict cluster creation and deletion permissions to essential personnel.
• Document access — maintain clear records of role assignments and business justifications.