Skip to main content

Illumio Administration Guide 25.4

Roles, Scopes, and Granted Access

This section describes the concepts of role-based access control (RBAC) and how it works with the PCE.

Illumio Segmentation for Data Centers includes several roles that grant users access to perform operations. Each role is matched with a scope. You can add users (local and external) and groups to all the roles.

Global Roles use the scope of All Applications, Environments, and Locations. You cannot change the scope for these roles. The roles have the following capabilities Illumio Segmentation for Data Centers.

Global Roles

The following table presents various roles and their granted access.

Table 1. Roles and Granted Access

Role

Granted Access

Global Organization Owner

Perform all actions: add, edit, or delete any resource, security settings, or user account.

Global Administrator

Perform all actions except user management: add, edit, or delete any resource or organization setting.

This user can change settings in the UI to allow administrators to choose whether to show a warning for editing labels used by enforced workloads. The default is not to show a warning.

Global Viewer

View any resource or organization setting.

They cannot perform any operations. This role was previously called "Global Read Only."

Global Policy Object Provisioner

Provision rules containing IP lists, services, and label groups.

They cannot provision rulesets, virtual services, servers, or add, modify, or delete existing policy items.



Note

You can add, modify, and delete your API keys because you own them.

About Read-Only Users in the Global Viewer User Role

The Read Only User role applies to all users in your organization—local, external, and users who are members of external groups managed by your IdP. This role allows users to view resources in Illumio Segmentation for Data Centers when they are not explicitly assigned to roles and scopes in the PCE.

For example, you configure single sign-on for your corporate Microsoft Active Directory Federation Services (AD FS) so that users managed by AD FS can log into the PCE using their corporate usernames and passwords. However, you haven't added all your external users to the PCE or assigned them roles. These users can still log into the PCE by authenticating with the corporate IDP and view resources in the PCE.

The Read Only User role is not listed in the Access Management > Global Roles or Scopes pages because it is considered a default, catchall role. Users have access to this role organization-wide because you enable or disable it for your entire organization. Additionally, you do not see it in the list of a user's role assignments when you view the user's details page (Access Management > External Users or Local Users). However, when the role is enabled for your organization, you see it listed in the Access Management > User Activity details for each user.

Note

You can enable and disable the Read Only User role from the Access Management > Global Roles page by clicking the Global Viewer role.

When the Read Only User role is disabled for your organization, users who are not assigned to roles cannot access Illumio-managed resources. When attempting to log into the PCE, they are still authenticated by their corporate IDP, but the PCE immediately logs them out because they do not have access (even read-only access) to any Illumio-managed assets.

Roles with Custom Scopes

You can apply the following roles to specific scopes. These roles are called “Scoped Roles.”

Role

Granted Access

Full Ruleset Manager

  • Add, edit, and delete all rulesets within the specified scope.

  • You can add, edit, and delete rules when the source matches the specified scope. The rule destination can match any scope.

    Note

    With the Full Ruleset Manager role, you can choose the All Applications, All Environments, and All Locations scope.

Limited Ruleset Manager

  • Add, edit, and delete all rulesets within the specified scope.

  • Add, edit, and delete rules when the source and destination match the specified scope.

  • Ruleset Managers with limited privileges cannot manage rules that use IP lists, custom iptables rules, user groups, label groups, iptables rules as destinations, or have internet connectivity.

    Note

    With the Limited Ruleset Manager role, you cannot choose the All Applications, All Environments, and All Locations scope.

Ruleset Viewer

  • Read-only access to rules that match the specified scope.

  • Ruleset Viewers cannot edit rules or rulesets.

Ruleset Provisioner

Provision rulesets within the specified scope.

Note

With the Ruleset Provisioner role, you can choose the All Applications, All Environments, and All Locations scope and custom scopes.

Workload Manager

Manage workloads and pairing profiles within the specified scope—read-only access provided to all other resources.

Workload Manager Role

Use Case 1

You want to use scripts in your development environment to spin up and bring down workloads programmatically; your scripts create pairing profiles and generate pairing keys without you granting elevated Admin privileges to the scripts.

Use Case 2

Your application teams are in charge of changing workload security posture, such as changing policy enforcement states. You want to allow your application teams to manage workload security without granting them broad privileges, such as all access (for the standard Application, Environment, and Location label types or for any customer label types you have defined).

Use Case 3

You want to prevent your PCE users from accidentally changing workload labels by moving the workloads in Illumination or Illumination Plus.

Solution

Users with the Workload Manager role can create, update, and delete workloads and pairing profiles. This role is scoped; when you assign a user to a scope, they can only manage workloads within the allocated scope. The Workload Manager can pair, unpair, and suspend VENs and change the policy state. It is an additive role; you can assign the Workload Manager role to a user and combine it with any other PCE role to provide additional privileges for that user.

Configuration

  1. Create a local user with “None” or the Global Viewer role (with Read Only User turned on).

  2. Assign the Workload Manager role to the user.

  3. (Optional) Provide the invitation link to the new workload manager user.

  4. The workload manager can log into the PCE and manage workloads and pairing profiles per the allocated scope.

The Workload Manager role is available under Scopes. Users assigned this role can view applications outside their scopes, but can only modify those within their scopes.

Note

A workload manager user cannot clear traffic counters from workloads within their scope.

Example: Limited Ruleset Manager Role

A user has the Full Ruleset Manager role and access to the following scope:

All Applications | Production Environment | All Locations

The user can create and manage:

  • Any ruleset that matches the Production environment

  • Intra- or extra-scope rules that match this scope:

    All Applications | Production Environment | All Locations

    Where the source and destination of the rule are both within the Production environment scope.

For intra-scope rules, all workloads can communicate within their group (as defined by the scope), so the rule destination is not restricted. However, in extra-scope rules, the Environment label of the resource selected as the destination must match the label in the scope exactly.

The user cannot create a rule with the scope “All | All | All” because that scope is broader than the user's access, which is only for the Production environment.

Because the user is a member of the Limited Ruleset Manager role, the user cannot manage custom iptables rules, and the following resources cannot be selected as destinations in extra-scope rules:

  • IP lists

  • Label groups

  • User groups

  • Workloads

Combine Roles to Support Security Workflows

Illumio includes fine-grained roles to manage security policy. The roles control different aspects of the security workflow. Mixing and matching them allows you to effectively control your company's access needs.

Ruleset Only Roles

You can add users to the Full Ruleset Manager and Ruleset Provisioner roles to edit the security policies on the workloads within their assigned scopes without affecting other entities, such as services, virtual services, or virtual servers.

These users can write rules for their workloads and provision them when the rules do not depend on global objects such as services or IP lists.

Ruleset Plus Global Policy Object Provisioner Roles

You can add users to the Ruleset Manager (Full or Limited) role and the Global Policy Object Provisioner role so that they can control the security policy for workloads.

These users can create rulesets within their assigned scopes and write rules not dependent on global objects. However, they can provision any workloads, including services, IP lists, and label groups.

Global Organization Owner or Administrator Roles

You can add architect-level professionals to the Global Organization Owner or Global Administrator role so that they can define all security policies for an enterprise.

To function as a security policy administrator, they can modify global objects such as services and labels, add workloads, pair workloads, and change workload modes.

Role Access is Additive

In the following example, Joe Smith is added to two user roles and one external group, each assigned a specific role and scope. Joe's ability to manage security for his company is a union of these roles and scopes.

rbac_roles_drawing.png

Exercise Caution when Combining Roles

Because role access is additive, caution is advisable when assigning more than one role to a user. Be sure you do not grant permissions beyond what is intended. For example, suppose you are assigning a scoped role to a user. The user's access will be restricted to workloads within the defined scope. If you assign the Global Read Only role to the same user, the user will be able to view all workloads, including those outside the scope defined in the first role.

Example Role Workflows

The following example shows the handoffs between a user who is a member of the Global Organization Owner role and a member of the Ruleset Manager role.

  1. An Organization Owner grants access to one or more scopes for a Ruleset Manager by selecting specific labels, which define the permitted scopes for the Ruleset Manager.

  2. The Ruleset Manager logs in and creates rules that conform to the specified scopes, as defined by the labels that are accessible to that user.

  3. The Ruleset Manager has read-only access to all other PCE resources, such as services or rulesets with different scopes from those the Ruleset Manager can access.

  4. The Organization Owner reviews the rules created by the Ruleset Manager and provisions them as needed.

Prerequisites and Limitations
  • To manage users, roles, and scopes in the PCE, you must be a member of the Global Organization Owner role.

  • Configuring SSO for an Illumio supported IdP is required for using RBAC with external users and groups. See PCE Information Needed to Configure SSO for information.

    If you have not configured SSO, you can still add external users and external groups to the PCE; however, these users will not be able to log into the PCE because they cannot reach the IdP or SAML server to authenticate.

  • Illumio resources that are not labeled are not access-restricted and are accessible by all users.

  • External users designated by username and not an email address in your IdP will not receive an automatic invitation to access the PCE. You must send them the PCE URL so they can log in.

  • You cannot change the primary designation for users and groups in the PCE; specifically, the email address for a local user, the username or email address for an external user, or the contents of the External Group field for an external group. To change these values, delete the users or groups and re-add them to the PCE.

  • An App Owner in charge of the application in both production and development environments does not have permission to write extra-scope rules between production and development.

Local users are not locked out of their accounts when they fail to log in. After five consecutive failures, the PCE emails the user that their account might be compromised.

Locked users retain all their granted access to scopes in the PCE; however, they cannot log into the PCE.