Role-based Access Control
Learn about role-based access control (RBAC) and how it works with the PCE.
Built-in Roles
Illumio Core includes several roles that grant users access to perform operations. Each role is matched with a scope.
Granular Permissions
You can assign multiple roles to a single user, and by combining and adjusting the different roles, you can achieve varying levels of permission granularity.
You can grant different permissions to different users for different resources by defining scopes. For example, you might allow some users complete access to add rulesets for all workloads in your staging environment. For other users, you might grant access to all workloads in all environments. Users can be assigned exactly one role, representing their singular job function, while other users can be assigned multiple roles, representing multiple job functions.
Identity Federation Using External Users and Groups
You can connect to external LDAP directories to manage users and user groups by configuring single sign-on (SSO) for the PCE.
Using this feature, you can create and manage users locally in PCE or use an IdP to manage users and user groups from an existing directory. External users and user groups authenticate with external Identity Providers (IdPs).
External User Removal from LDAP
When an External user is deleted after being removed from LDAP, users and PCE admins still need to perform some manual cleanup as part of the deletion activity.
The responsibilities of users and PCE admins are to ensure that all permissions associated with the deleted user on the PCE (e.g., scp3) are removed. This is the organization owner's responsibility. Removing the user from the LDAP directory alone won't remove the permissions on the PCE.
Custom Role Assignments
You can customize access to suit your organization by specifying specific scopes for the Ruleset Manager and Ruleset Provisioner roles.
Audit Information
You can access an audit trail of user activity through the following reports:
The User Activity page displays the authentication details for each user, including when they logged in and whether they are online.
The Organization Events page displays when Organization Owners grant users access, when users log in and out, and the actions they perform.
Roles, Scopes, and Granted Access
Learn about role-based access control (RBAC) and how it works with the PCE.
About Roles
Illumio Core 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.
Roles with Global Scopes
These Global Roles use the scope All Applications, All Environments, and All Locations. You cannot change the scope for these roles. The roles have the following capabilities in Illumio Core.
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. |
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, or virtual servers, nor can they 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 Identity Provider (IdP). This role allows users to view resources in Illumio Core 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 by using their corporate usernames and passwords. However, you haven't added all your external users to the PCE or assigned them to roles. These users can still log in to the PCE by authenticating with the corporate IDP and view resources within the PCE.
The Read-Only User role is not listed on the Access Management > Global Roles or Scopes pages because it is considered a default, catch-all type of role. Users have access to this role on an organization-wide basis, as it is either enabled or disabled for your entire organization. Additionally, you will not see it in the list of a user's role assignments when viewing the user's details page (Access Management > External Users or Local Users). However, when the role is enabled for your organization, it is 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 will be unable to access Illumio-managed resources. When attempting to log into the PCE, they are still authenticated by their corporate IDP. Still, 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
Apply the following roles to specific scopes. These roles are referred to as “Scoped Roles.”
Role | Granted Access |
|---|---|
Full Ruleset Manager |
|
Limited Ruleset Manager |
|
Ruleset Viewer |
|
Ruleset Provisioner | Provision rulesets within the specified scope. NoteYou can choose the All Applications, All Environments, and All Locations scope and custom scopes with the Ruleset Provisioner role. |
Workload Manager | Manage workloads and pairing profiles within the specified scope—read-only access provided to all other resources. NoteThe 19.1.0 PCE does not support unpairing multiple managed workloads via the REST API when you are logged in as a Workload Manager. You can unpair workloads using the PCE web console because it restricts the selection of workloads by the user's scope. However, via the REST API, the bulk unpair operation fails when multiple workloads are selected and one or more of the workloads are out of the user's scope. |
RBAC Examples
Here are some examples for defining and combining roles.
Manager Role Examples
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 requiring you to grant elevated Admin privileges to the scripts.
Use Case 2
Your application teams are responsible for modifying the security posture of workloads, including 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, as well as 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
Create a local user with “None” or the Global Viewer role (with Read Only User turned on).
Assign the Workload Manager role to the user.
(Optional) Provide the invitation link to the new workload manager user.
The workload manager can then log into the PCE and manage workloads and pairing profiles per the allocated scope.
The Workload Manager role is available under Scopes. Users assigned to this role can view applications that fall outside their scopes, but can only modify those applications that are within their assigned scope.
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 scope of the Production environment.
For intra-scope rules, all workloads within their group (as defined by the scope) can communicate, 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 it is broader than the user's access, which is limited to 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. By mixing and matching them, you can effectively control the access your company needs.
Ruleset Only Roles
You can add users to the Full Ruleset Manager and Ruleset Provisioner roles, allowing them to edit security policies on workloads within their assigned scopes without affecting other entities, such as services, virtual services, or virtual servers.
The full Ruleset Manager can add, edit, and delete rules when the source matches a specified scope.
The limited Ruleset Manager can 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, user groups, label groups, iptables rules as destinations, or rules that allow internet connectivity.
The Ruleset Provisioners can provision rulesets within a specified scope. They cannot provision virtual servers, virtual services, SecureConnect gateways, security settings, IP lists, services, or label groups—provision rulesets within a specified scope.
Suppose you are granting a user or group the Ruleset Manager or Ruleset Provisioner role. In that case, you can also associate a scope with the role, allowing you to control which rulesets they can add and provision.
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, allowing them to control the security policy for workloads.
The rule destination can match any scope.
Global Organization Owner or Administrator Roles
You can add architect-level professionals to the Global Organization Owner or Global Administrator role, allowing them to define all security policies for an enterprise.
They can modify global objects, such as services and labels, add workloads, pair workloads, and change workload modes to function as a security policy administrator.
Role Access is Additive
In the following example, Joe Smith is assigned to two user roles and one external group, each with a specific role and scope. Joe's ability to manage security for his company is a union of the roles and scopes he is assigned to.
Because role access is additive, some caution is advisable when assigning more than one role to a user. Be sure to grant permissions only as 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 then 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 illustrates the handoffs between a user in the Global Organization Owner role and a user in the Ruleset Manager role.
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.
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.
The Ruleset Manager has read-only access to all other PCE resources, including services and rulesets with scopes that differ from the scopes the Ruleset Manager can access.
The Organization Owner reviews the rules created by the Ruleset Manager and provisions them as needed.
Setup for Role-based Access Control
This section describes how to configure role-based access control (RBAC) for the PCE.
Note
Permission to configure these settings is dependent on your role.
Add a Scoped Role
Add a scoped role to create fine-grained access control to manage security policy for your workloads.
By defining scopes, you can grant different permissions to different users for different resources. For example, you might allow some users to add rulesets for all workloads in your staging environment. You might grant access to all workloads in all environments for other users.
When adding a scoped role:
use the Access Wizard
Define the scope of the role by selecting labels or label groups for applications, environment, and location.
Add a local user, external user, or user group to the role.
Select roles and confirm your choice.
Manage a Local User
Local users are created in the PCE (an IdP does not manage them). When they log into the PCE, they must enter their email addresses and passwords. The Illumio PCE encrypts and stores their passwords.
When you install the PCE, the first user account it creates is a local user. You can create additional local users as a backup in case your external IdP goes offline or the SAML server is inaccessible.
To add a local user:
In the Local Users tab, click Add.
Enter a name and an email address. The email address must use the format [email protected] and be 255 characters or less.
You can add email addresses with an apostrophe (') in them. In the PCE, you can have duplicate names for local users, but you cannot have duplicate email addresses.
The PCE emails the user to the address you specified an invitation to with a link to create their Illumio user account. The link in the invitation email is valid only for 7 days, after which it expires.
Select a role for the user: None, Global Organization Owner, Global Administrator, or Global Read Only.
You can change a user's role membership after adding them by going to the user's details page or from a role details page. The "My Roles" feature allows you to view the list of assigned permissions (roles).
To remove a local user
Select it in the Users and Groups and remove it.
When you remove a local user while the user is online, the PCE logs the user out as soon as the user is removed.
The user is removed from the Local Users tab; however, the user remains in the User Activity page and is designated as offline. The user's actions remain in the Organization Events page.
You can re-add the user to the PCE as a local or external user with the same name and email address or username.
To edit a local user
In Users and Groups, find the user you want to edit. change the user's name and save.
You cannot edit a user's email address. You must remove and re-add the user with the new email address.
Changing a local user's name only changes it in the RBAC Roles and Users and Groups pages. The name is not changed in the user's profile or on the RBAC User Activity pages.
Note
Local and external users can change their names when they create their accounts or from their profiles.
To convert a local user
In Users and Groups, select the name of the user and click Convert.
You can convert a local user to an external user so that your corporate IdP manages the user authentication credentials. When you convert a user to an external user, the user retains all their role memberships.
To invite a local user
In Users and Groups, select the name of the user and click Re-invite.
You can send a new email to users to create their account when they haven't responded to the original email. An invitation remains valid for 7 days.
To lock or unlock a local user
In Users and Groups, select the name of the user and click Lock.
Local users are locked out of their accounts when they fail to log in after five consecutive failures.
Locked users retain all their granted access to scopes in the PCE; however, they cannot log into the PCE. When an account is locked, the PCE web console reports that the username or password is invalid even when a user enters valid credentials. The user's account resets after 15 minutes and does not require an Illumio administrator to unlock it.
Add or Remove an External User
Using RBAC, you can control access to Illumio Core for users who a corporate IdP externally authenticates. Your corporate IdP manages authentication so that when these users log into the PCE, they are redirected to the IdP to authenticate. The PCE does not validate their usernames or passwords.
Using RBAC, you control the access external users have to Illumio Core features and functionality. When you add an external user to the PCE, you specify that user's access by assigning the user to Illumio roles and scopes.
To add an external user:
Use the External Users tab to click Add and enter a name, email address, or username.
Whether you enter an email address or username for the user depends on how you have configured your IdP to identify corporate users. The username can contain up to 225 alphanumeric and special characters (. @ / _ % + -). In the PCE, you can have duplicate names for external users, but you cannot have duplicate email addresses or usernames.
When your IdP is configured to identify users by using email addresses, the PCE emails the user at the address you specify an invitation with a link to create their Illumio user account. If your IdP is configured to use usernames, you must provide the user your Illumio PCE web console URL.
Select the role: None, Global Organization Owner, Global Administrator, or Global Read Only.
Users without a role (None) can still log into the PCE to view resources when Read Only User access to the PCE is enabled. You can enable and disable Read Only User access in the Global Read Only role.
You can change a user's role membership after adding them by going to the user's details page or from a role details page.
To change an external user's name, click Edit User from the user's details page. You cannot edit the email address or username for an external user. You must remove and re-add the user with the new information.
To remove an external user:
Use the External Users tab to select the user you want to remove and click Remove.
Removing an external user removes the user from the External Users tab and all the user's RBAC role memberships. Your corporate IdP still manages the user's authentication.
If Read Only User access to the PCE is enabled for your organization, the user can still log into the PCE and view resources after you remove the user.
When you remove an external user while the user is online, the PCE logs the user out for their next action after being removed.
Add or Remove an External Group
The RBAC feature in Illumio Core integrates with the user groups maintained in your corporate IdP so you can manage user authentication centrally for the Illumio Core. In the PCE, you assign roles and scopes to the groups managed by your IdP to control the access that Illumio users have to their Illumio managed resources.
With user groups, you can authorize your teams to manage the security for the applications they manage without waiting for a centralized security team to delegate authority.
When a user who is a member of an external group logs into the PCE, the corporate IdP authenticates the user and returns the list of groups the user belongs to. For each of those groups, the PCE determines what roles and scopes are assigned to the group. The user is granted access to the resources associated with the roles and scopes.
A user can belong to multiple external groups. When a user belongs to multiple groups, the user is granted access to Illumio resources based on the most permissive role and scopes defined for each group.
To add an external group:
Use the External Users tab to add an external group
In the External Group field, enter the group name as it's configured in your IdP.
In your IdP, the group is designated by a simple group name (for example, “Sales”) or by a group name in distinguished name (DN) format (for example, “CN=Sales, OU=West”).
To verify the correct format to enter the PCE, check the memberOf attribute in the SAML assertion from your IdP. The memberOf attribute is a multiple-value attribute that contains a list of distinguished names for groups that contain the group.
To change an external group's name, click Edit Group from the group's details page. You cannot edit the External Group field. You must remove and re-add the group with the new information.
To remove an external group: Click Edit Group from the group's details page to change an external group's name.
Use the External Users tab to remove an external group, select it, and click Remove.
Removing an external group from the PCE removes all the group's RBAC role memberships and, therefore, removes access for all the group members. Your corporate IdP still manages user authentication for the group members.
If Read Only User access to the PCE is enabled, the external group members can still log into the PCE and view resources after you remove the group.
Change Users and Groups Added to Roles
When you change the membership for a role, the affected users must log out and log in to access the new capabilities.
When you revoke a user's access to scopes or global objects while the user is online, the PCE logs them out of the next action they can take after revoking their access.
In Global Roles, click the name of the role you want to assign users or groups to
To remove a user or group from the role, select it and click Remove.
To add a user or group to a role, click Add.
From the first drop-down list, select what (Any Principal Type, Local Users, External Users, or External Groups) you want to add to the role.
Selecting what you want to add filters the second list to display only those types of users or user groups.
Select the user or group to add to the role.
Click Grant Access.
Alternatively, you can select users or groups to add to roles from the Role-Based Access > User and Groups details pages, select Add, and follow the steps in the Access Wizard.
View User Activity
You can access a historical audit trail of user activity through the following reports:
User Activity: Go to Role-Based Access > User Activity
Displays session details for each user, including their status, email address, and when they were last logged in.
Click a user to view all the roles and scopes that are assigned to that user.
The User Activity page also displays users who were removed and are designated as offline.
Note
The names that appear in the User Activity pages can be different from the Role-Based Access > Users and Groups pages when users edit their profiles or an Organization Owner changes names in the Role-Based Access > Users and Groups pages.
Organization Events: Go to Troubleshooting > Organization Events
The Organization Events page provides an ongoing log of all events in the PCE. For example, it captures actions, such as users logging in and logging out and failed log-in attempts, when a system object is created, modified, deleted, or provisioned, and when a workload is paired or unpaired.
Each of these events has a severity level and are exportable in JSON format. You can narrow the search for many eventsby event type, severity, or time filters.
Change Your Profile Settings
If you want to change the password you use to access the PCE web console, you can do so from your User menu located at the top right corner of the PCE web console.
To change your password
In My Profile, click on Change Password.
Enter your current password and then your new password twice.
Click Change Password.
Color Vision Deficiency Mode
Users with color vision deficiency (Deuteranopia, Protanopia, or Tritanopia) can select Color Vision Deficiency mode, making it easier for them to distinguish between blocked and allowed traffic lines in the Illumination map. This mode can be enabled on a per-user basis.
The color vision deficiency mode is disabled by default.
To enable color vision deficiency mode
In My Profile, Accessibility section, select the Color Vision Deficiency button.
Note
To restore the default setting, select the Normal Vision button.
Role-based Access for Application Owners
The enhancements made to the Role-based Access Control (RBAC) framework in the Illumio Core 20.1.0 release enable organizations to address several use cases related to application owners.
Overview
These enhancements include:
Delegation of policy writing to downstream application teams.
Assigning read-only privileges to application owners. Those users get read access based on the assigned scopes.
Flexibility to assign read/write or read-only privileges to the same user for different applications. For example, the same user can have read/write privileges in a staging environment but have read-only privileges in a production environment.
Although the RBAC controls in releases prior to 20.1.0 restricted "writes" based on user role and scope, users had visibility into all aspects of the PCE, irrespective of their role. With these new RBAC controls, application owners get visibility into the applications within their assigned scopes, specifically the PCE information relevant to their applications. Depending on the user's role, application owners can:
Read/write policies to manage application segmentation.
View inbound and outbound traffic flows as well as use Explorer.
View labeled objects used in policies.
View details of global objects such as, IP Lists and Services used by their applications.
Benefits
The key benefits of the RBAC framework in the PCE are as follows:
Provides a label-based approach to define user permissions.
Provides roles based on application owner personas to manage application segmentation.
Provides a building block-based approach to stack permissions for users.
Offers flexibility to delegate read/write and read-only privileges to the same user for different sets of applications.
Enables enforcement of least privilege by hiding information outside of an application scope.
Allows application owners to manage segmentation for their applications effectively.
Updates to Roles
Illumio Core provides two types of user roles - Global and Scoped. It also provides the ability to stack multiple roles for the same user. A PCE owner can assign multiple roles to the same user. The resulting set of permissions is the summation of all permissions included with each stacked. With these updates:
Existing scoped roles were enhanced to restrict reads by scope.
The new scope-based read-only role limits read access by labels.
Scoped users get limited visibility into objects 1-hop away (this applies to Explorer, App Group Maps, Rule Search, and Traffic).
Global read-only is disabled by default for new PCE installations.
PCE performance and scale enhanced to support concurrently active users.
Global Roles
Global roles allow the user to view everything and perform operations globally. The four Global roles are :
Global Organization Owner: Allowed to manage all aspects of the PCE, including user management.
Global Administrator: Allowed to manage most aspects of the PCE, except user management.
Global Viewer: Allowed to view everything within the PCE in a read-only capacity. This role was previously called "Global Read-only".
Global Policy Object Provisioner: Allowed to provision global objects that require provisioning, such as Services and Label Groups.
Scoped Roles
The Scoped roles are defined using labels. The permissions included with the assigned role apply only to the assigned scope, where the scope is defined using a combination of as many label types as you have defined (and with only one label value per type). To provide permissions to different applications for a user, each of the application scopes has to be added to the same user.
All the Scoped roles have been enhanced to restrict reads and writes by Scope. The Scoped roles are :
Ruleset Viewer: A new scope-based read-only role. A user with this role has read-only permissions within the assigned scope. The user can view policy, application groups, incoming and outgoing traffic, and labeled objects, such as workloads, within the assigned scope.
Ruleset Manager (Limited or Full): An existing scope-based read/write role. A user with this role can read/write policy within the assigned scope. The user can also view application groups, incoming and outgoing traffic, and labeled objects within the assigned scope.
Ruleset Provisioner: This role allows a user to provision changes to scoped objects, provided the objects are inside the user's assigned scope. A user with this role can also provision changes to policies within the assigned scope. The user can also view application groups, incoming and outgoing traffic, and labeled objects within the assigned scope.
Workload Manager: This role allows a user to perform workload-specific operations such as pairing, unpairing, label assignment, and changing policy state. A user with this role cannot view policies and traffic and cannot provision changes.
Configuration
The Global Read-only user setting should be disabled to enforce scoped reads for users with scoped roles. To disable this setting, make sure that the Read Only User setting under Access > Global Roles > Global Viewer is set to Off.
Note
In PCE versions 20.1.0 and higher, the Global Read-only user setting is disabled by default.
On PCE versions upgraded from prior releases, this setting must be manually turned off for users to have reads restricted by scope. If this setting is se On, users with scoped roles will get global visibility by default.
Facet Searches for Scoped Roles
The Scopes page now features a search bar with auto-complete and facets. This is restricted to users with a Global Organization Owner role. To use this feature, navigate to Access Management > Scopes. The search bar allows Organization Owners to query a list of users by a user's role. They can search by labels and label groups to get a list of users with the selected label(s) in their assigned scope(s), or for users with no labels assigned. They can also select Principals to search for a specific user.
Ruleset Viewer
Ruleset Viewer is a new scope-based read-only role. When assigned, a user get read-only visibility into the assigned application scope. As a Ruleset Viewer, you can view all the Rulesets and Rules within the assigned scope. However, you cannot edit any of the rules or create new rules. You can use Policy Generator to preview the policies that will be generated. However, you are not allowed to save policy after previewing it using Policy Generator.
A Ruleset Viewer is allowed to view everything that a Ruleset Manager with the same scope is allowed to view. This includes traffic flows, labeled objects, application groups, global objects, and so on. The only difference between a Ruleset Manager and a Ruleset Viewer is the absence of write privileges for a Ruleset Viewer. A Ruleset Manager is allowed to create and update policy within the application scope.
Scoped Roles and Permissions
The following table provides a summary of the different permissions provided with each of the scoped roles.
(R) = Restricted based on scope
(T) = Restricted based on resource type
--- = Not applicable
Page | Ruleset Viewer (Scoped Read-Only) | Ruleset Manager | Ruleset Provisioner | Workload Manager | Application Owner (Combined Permissions) |
|---|---|---|---|---|---|
Traffic - Illumination, App Group, Explorer | |||||
Illumination Location Map | --- | --- | --- | --- | --- |
App Group Policy Map | Read (R) | Read (R) | Read (R) | --- | Read (R) |
App Group Vulnerability Map | Read (R) | Read (R) | Read (R) | --- | Read (R) |
App Group List | Read (R) | Read (R) | Read (R) | Read (R) | |
Explorer | Read (R) | Read (R) | Read (R) | --- | Read (R) |
Blocked Traffic | Read (R) | Read (R) | Read (R) | --- | Read (R) |
Policy | |||||
Policy Generator | Read (R) | Read+Write (R) | Read (R) | --- | Read+Write (R) |
Rulesets and Rules | Read (R) | Read+Write (R) | Read (R) | --- | Read+Write (R) |
Rule Search | Read (R) | Read (R) | Read (R) | --- | Read (R) |
Policy Check | Read (R) | Read (R) | Read (R) | --- | Read (R) |
Provisioning Draft Changes | Read (R) | Read (R) | Read+Write (R) | --- | Read+Write (R) |
Policy Versions | Read (R) | Read (R) | Read (R) | --- | Read (R) |
Provisioning Status | Read (R) | Read (R) | Read (R) | --- | Read (R) |
Labeled Objects | |||||
Workloads | Read (R) | Read (R) | Read (R) | Read+Write (R) | Read+Write (R) |
Container Workloads | Read (R) | Read (R) | Read (R) | Read (R) | Read (R) |
Virtual Enforcement Nodes | Read (R) | Read (R) | Read (R) | Read+Write (R) | Read+Write (R) |
Pairing Profiles | --- | --- | --- | Read+Write (R) | Read+Write (R) |
Virtual Services | Read (R) | Read (R) | Read (R) | Read (R) | Read (R) |
Virtual Servers | Read | Read | Read | Read | Read |
Global Policy Objects | |||||
Services | Read | Read | Read | Read | Read |
IP Lists | Read | Read | Read | Read | Read |
User Groups | Read | Read | Read | Read | Read |
Labels | Read | Read | Read | Read | Read |
Label Groups | Read | Read | Read | Read | Read |
Settings | |||||
Segmentation Templates | --- | --- | --- | --- | --- |
Role-Based Access Global Roles | --- | --- | --- | --- | --- |
Role-Based Access Scoped Roles | --- | --- | --- | --- | --- |
Role-Based Access Users and Groups | --- | --- | --- | --- | --- |
Role-Based Access User Activity | --- | --- | --- | --- | --- |
Load Balancers | --- | --- | --- | --- | --- |
Container Clusters | --- | --- | --- | --- | --- |
Bi-directional Routing Networks | --- | --- | --- | --- | --- |
Event Settings | --- | --- | --- | --- | --- |
Setting Security | --- | --- | --- | --- | --- |
Setting Single Sign-On | --- | --- | --- | --- | --- |
Setting Password Policy | --- | --- | --- | --- | --- |
Setting Offline Timers | --- | --- | --- | --- | --- |
VEN Library | --- | --- | --- | Read | Read |
My Profile | Read+Write | Read+Write | Read+Write | Read+Write | Read+Write |
My API Keys | Read+Write | Read+Write | Read+Write | Read+Write | Read+Write |
Other | |||||
Support Reports | --- | --- | --- | Read+Write (R) | Read+Write (R) |
Events | --- | --- | --- | --- | --- |
Reports | Read (R, T) | Read (R, T) | Read (R, T) | Read (R, T) | Read (R) |
Support | Read | Read | Read | Read | Read |
PCE Health | --- | --- | --- | --- | --- |
Product Version | Read | Read | Read | Read | Read |
Help | Read | Read | Read | Read | Read |
Terms | Read | Read | Read | Read | Read |
Privacy | Read | Read | Read | Read | Read |
Patents | Read | Read | Read | Read | Read |
About Illumio | Read | Read | Read | Read | Read |
Scoped Users and PCE
Each scoped role has different permissions that impact an application owner's visibility into various aspects of the PCE. Application owners can be assigned scoped roles that come with different permissions.
Navigation Menus
The PCE navigation menu options vary based on the user's role. The navigation menu options available for Application Owner are limited. For example, a user is logged in as a Global Organization Owner has more (complete) menu options displayed than when a user logs in as a scoped user (Application Owner).
The following table provides the menu options available for different scoped users.
Y = Yes (menu option is displayed for the user)
N/A = Not applicable (menu option is hidden from the user)
Page | Ruleset Viewer | Ruleset Manager | Ruleset Provisioner | Workload Manager |
|---|---|---|---|---|
Illumination Map | N/A | N/A | N/A | N/A |
Role-based Access | N/A | N/A | N/A | N/A |
Policy Objects > Segmentation Templates | N/A | N/A | N/A | N/A |
Policy Objects > Pairing Profiles | N/A | N/A | N/A | Y |
Infrastructure | N/A | N/A | N/A | N/A |
Troubleshooting > Events | N/A | N/A | N/A | N/A |
Troubleshooting > Support Reports | N/A | N/A | N/A | Y |
Settings | N/A | N/A | N/A | See row below |
Settings > VEN Library | N/A | N/A | N/A | Y |
PCE Health | N/A | N/A | N/A | N/A |
App Groups > Map | Y | Y | Y | N/A (App Group Members are visible) |
App Groups > List | Y | Y | Y | Y |
App Groups > Vulnerability Map | Y | Y | Y | N/A |
Explorer | Y | Y | Y | N/A |
Policy Generator | Y | Y | Y | N/A |
Rulesets and Rules | Y | Y | Y | N/A |
Rule Search | Y | Y | Y | N/A |
Workload Management > Workloads | Y | Y | Y | Y |
Workload Management > Container Workloads | Y | Y | Y | Y |
Workload Management > Virtual Enforcement Nodes (Agents) | Y | Y | Y | Y |
Provision > Draft Changes | Y | Y | Y | N/A |
Provision > Policy Versions | Y | Y | Y | N/A |
Policy Objects > IP Lists | Y | Y | Y | Y |
Policy Objects > Services | Y | Y | Y | Y |
Policy Objects > Labels | Y | Y | Y | Y |
Policy Objects > User Groups | Y | Y | Y | Y |
Policy Objects > Label Groups | Y | Y | Y | Y |
Policy Objects > Virtual Services | Y | Y | Y | Y |
Policy Objects > Virtual Servers | Y | Y | Y | Y |
Troubleshooting > Blocked Traffic | Y | Y | Y | N/A |
Troubleshooting > Export Reports | Y | Y | Y | Y |
Troubleshooting > Policy Check | Y | Y | Y | N/A |
Troubleshooting > Product Version | Y | Y | Y | Y |
Support | Y | Y | Y | Y |
My Profile | Y | Y | Y | Y |
My Roles | Y | Y | Y | Y |
My API Keys | Y | Y | Y | Y |
Help | Y | Y | Y | Y |
Terms | Y | Y | Y | Y |
Patents | Y | Y | Y | Y |
Privacy | Y | Y | Y | Y |
About Illumio | Y | Y | Y | Y |
Landing Page
The PCE landing page changes dynamically based on the user's role. The Illumination page opens when you log in to your account as an Organization Owner. However, when you log in as a Scoped user, the landing page changes to the App Groups List page where you can see the list of App Groups assigned.
Labeled Objects
The scope of the user filters labeled objects, such as workloads. On the Workloads page, you will only see the list of the workloads within the application scope. You cannot see any workloads that are outside the application scope. This applies to any labeled object, such as workloads, containers, Virtual Services, and Virtual Enforcement Nodes (VENs).
The menu functions and buttons change dynamically to reflect a user's permissions. If logged in as a Ruleset Manager, you cannot manage workloads. So, all the workload-specific operations buttons are disabled. However, you can view the list of workloads within the scope and get details for individual workloads, except for Virtual Servers.
Note
While Virtual Servers are considered labeled objects, they are visible to all scoped users regardless of object scope.
Facet Searches and Auto-complete
The search bar with auto-complete and facets is scoped for labeled objects and Rulesets. For example, if you search for Application Labels, you can only select the Application Labels under the assigned scope. This applies to other label types such as Environment labels and Location labels. However, Role labels are excluded since Role labels are not part of the user scope. The restriction of visibility by scope applies to facets such as hostname, IP address, etc. The search bar automatically filters the facets to the list of facets in the user's assigned scope.
Global Objects
Scoped users get complete read-only visibility into all global objects. This includes IP Lists, services, labels, label groups, and user groups. However, scoped users cannot create, modify, or provision global objects.
Note
Only the Global Organization Owner and Global Administrator can create, modify, and provision global objects.
Rulesets and Rules
Scoped users, except Workload Managers, can see rulesets and rules that apply to their applications. A Ruleset Manager can edit the ruleset, whereas the other scoped roles (Ruleset Viewer and Ruleset Provisioner) can view rulesets. A scoped user can see all the rules within the application ruleset.
When label groups are used within the scope of a ruleset, a Ruleset Manager may not be allowed to edit the ruleset and its rules even if there is a scope match between the user's assigned scope and the underlying scope of the ruleset. The user will, however, be able to view the rules within such a ruleset.
In addition, scoped users can also see rules that apply to their applications. For example, scoped users can view rules written by other applications that apply to their application. To see those rules, click Rule Search from the navigation menu.
On the Rule Search page, a scoped user can see all the rules that apply to their application. This includes rules for incoming and outgoing traffic flows. The rules highlighted in the screenshot below are the outbound rules which are for your application. The application owner provides visibility to all the rules that are applied to your application.
Policy Generator and Explorer
With Policy Generator, scoped users can generate policies only for their applications. Only Ruleset Managers can generate policies with Policy Generator. Ruleset Viewers can preview Policy Generator without the ability to save the policy.
Explorer views are also filtered for scoped users. To use Explorer, one of the endpoints has to be within the scoped user's application. The same applies to Blocked Traffic.
My Roles
"My Roles" is a new feature that allows you to view the list of assigned permissions (roles).
App Group Map
The App Group Map provides visibility into applications and their contents. All scoped users except for Workload Managers can view App Group Maps.
Scoped users get limited visibility for connected App Groups such as Source App Groups and Destination App Groups. Scoped users get limited information on endpoints with traffic flows to their application. For an endpoint in a connected App Group from traffic flow, scoped users can get limited information such as labels, role names, and host names.
