Operating

Procedure

1. In the RHACS portal, click Compliance → Dashboard.

2. Optional: By default, information on all standards is displayed in the compliance results.

   To display information about specific standards only, perform the following steps:

   1. Click Manage standards.
   2. By default, all standards are selected. Clear the checkbox for any specific standard that you do not want to display.

   3. Click Save.

      Standards that are not selected do not appear in the dashboard display, including the widgets, in the compliance results tables accessible from the dashboard, and in the PDF files created by using the Export button. However, when exporting the results as a CSV file, all default standards are included.

3. Click Scan environment.

   Note

   Scanning the entire environment takes about 2 minutes to complete. This time might vary depending on the number of clusters and nodes in your environment.

Verification

1. In the RHACS portal, click Configuration Management.
2. In the CIS Kubernetes v1.5 widget, click Scan.
3. RHACS displays a message which indicates that a compliance scan is in progress.

Procedure

1. In the RHACS portal, click Compliance → Dashboard.
2. Click either the clusters, namespaces, or nodes tab to open the details page.
3. Enter your filtering criteria in the search bar, and then click Enter.

Procedure

1. In the RHACS portal, click Compliance → Dashboard.

2. Click the Export tab to do any of the following tasks:

   • To generate an executive report, select Download Page as PDF.

   • To generate an evidence report, select Download Evidence as CSV.

     Tip

     The Export option appears on all compliance pages and filtered views.

Procedure

1. In the RHACS portal, click Compliance → Schedules.
2. Click Create scan schedule.

3. In the Create scan schedule page, provide the following information:

   • Name: Enter a name to identify different compliance scans.
   • Description: Specify the reason for each compliance scan.

   • Schedule: Adjust the scan schedule to fit your required schedule:

     • Frequency: From the drop-down list, select how often you want to perform the scan.

       The following values are associated with how often you want to perform the scan:

       • Daily
       • Weekly
       • Monthly

     • On day(s): From the list, select one or more days of the week on which you want to perform the scan.

       The following values are associated with the days of the week on which you want to perform the scan:

       • Monday
       • Tuesday
       • Wednesday
       • Thursday
       • Friday
       • Saturday
       • Sunday
       • The first of the month

       • The middle of the month

         Note

         These values are only applicable if you specify the frequency of scan as Weekly or Monthly.

     • Time: Start to type the time in hh:mm at which you want to run the scan. From the list that is displayed, select a time.
4. Click Next.
5. In the Clusters page, select one or more clusters that you want to include in the scan.
6. Click Next.
7. In the Profiles page, select one or more profiles that you want to include in the scan.
8. Click Next.

9. Optional: To configure email delivery destinations for manually triggered reports, perform the following steps:

   Note

   You can add one or more delivery destinations.

   1. Expand Add delivery destination.

   2. In the Delivery destination page, provide the following information:

      • Email notifier: Select an email notifier from the drop-down list.

        Optional: To configure the setting for a new email notifier integration, perform the following steps:

        1. From Select a notifier drop-down list, click Create email notifier.

        2. In the Create email notifier page, provide the following information:

           • Integration name: Enter a unique name for the email notifier. This name helps you identify and manage this specific email notifier configuration.
           • Email server: Specify the address of the SMTP server that you want to use to send the emails.
           • Username: Enter the username that is required for authentication with the SMTP server. This is often the email address used for sending the emails.
           • Password: Enter the password associated with the SMTP username. This password is used for authentication with the SMTP server.
           • From: This address usually represents the sender of the emails and is visible to the recipients. This is optional.
           • Sender: Enter the name of the sender, which is displayed together with the From email address. This name helps recipients identify who sent the email.
           • Default recipient: Enter the default email address that should receive the notifications if no specific recipient is specified. This ensures that there is always a recipient for the emails.
           • Annotation key for recipient: Specify the annotation key to define a recipient that you want to notify about the policy violations related to a specific deployment or namespace. This is optional.
           • Optional: Select the Enable unauthenticated SMTP checkbox, if your SMTP server does not require authentication. This is not recommended due to security reasons.
           • Optional: Select the Disable TLS certificate validation (insecure) checkbox, if you want to disable TLS certificate validation. This is not recommended due to security reasons.

           • Optional: In the Use STARTTLS (requires TLS to be disabled) field, select the type of STARTTLS for securing the connection to the SMTP server from the drop-down list.

             Important

             To use this option, you must disable TLS certificate validation.

             The following values are associated with the type of STARTTLS for securing the connection to the SMTP server:

             • Disabled

               Data is not encrypted.

             • Plain

               Encodes username and password in base64.

             • Login

               Sends username and password as separate base64-encoded strings for added security.

        3. Click Save integration.
      • Distribution list: Enter one or more comma-separated email addresses of the recipients who should receive the report.

      • Email template: The default template is automatically applied.

        Optional: To customize the email subject and body as needed, perform the following steps:

        1. Click the pencil icon.

        2. In the Edit email template page, provide the following information:

           • Email subject: Enter the desired subject line for the email. This subject is displayed in the recipient’s inbox and should clearly indicate the purpose of the email.
           • Email body: Compose the text of the email. This is the main content of the email and can include text, placeholders for dynamic content and any formatting necessary to get your message across effectively.
        3. Click Apply.
10. Click Next.
11. Review your scan configuration, and then click Save.

Verification

1. In the RHACS portal, click Compliance → Schedules.
2. Select the compliance scan you have created.
3. In the Clusters section, verify that the operator status is healthy.

4. Optional: To edit the scan schedule, perform the following steps:

   1. From the Actions drop-down list, select Edit scan schedule.
   2. Make your changes.
   3. Click Save.

5. Optional: To manually send a scan report:

   Note

   You can only send a scan report manually if you have configured an email delivery destination.

   • From the Actions drop-down list, select Send report.

     You receive a confirmation that you have requested to send a report.

Procedure

1. In the RHACS portal, click Compliance → Coverage.
2. Select a cluster to view the details of the individual scans.
3. Optional: Enter the name of the profile check in the Filter by keyword box to view the status.

4. Optional: From the Compliance status drop-down list, select one or more statuses by using which you want to filter the scan details.

   The following values are associated with how you want to filter the scan details:

   • Pass
   • Fail
   • Error
   • Info
   • Manual
   • Not Applicable
   • Inconsistent

Procedure

1. In the RHACS portal, select Risk from the navigation menu.
2. Select a deployment from the list of deployments in the default Risk view. Deployment details open in a panel on the right.
3. In the Deployment details panel, select the Process Discovery tab.
4. The process baselines are visible under the Spec Container Baselines section.

Procedure

1. In the RHACS portal, select Risk from the navigation menu.
2. Select a deployment from the list of deployments in the default Risk view. Deployment details open in a panel on the right.
3. In the Deployment details panel, select the Process Discovery tab.
4. Under the Running Processes section, click the Add icon for the process you want to add to the process baseline.

Procedure

1. In the RHACS portal, select Risk from the navigation menu.
2. Select a deployment from the list of deployments in the default Risk view. Deployment details open in a panel on the right.
3. In the Deployment details panel, select the Process Discovery tab.
4. Under the Spec Container baselines section, click the Remove icon for the process you want to remove from the process baseline.

Procedure

1. In the RHACS portal, select Risk from the navigation menu.
2. Select a deployment from the list of deployments in the default Risk view. Deployment details open in a panel on the right.
3. In the Deployment details panel, select the Process Discovery tab.

4. Under the Spec Container baselines section:

   • Click the Lock icon to trigger violations for processes that are not in the baseline.
   • Click the Unlock icon to stop triggering violations for processes that are not in the baseline.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.

2. Disable enforcement on the default policies:

   • In the policies view, locate the Kubernetes Actions: Exec into Pod policy. Click the overflow menu, , and then select Disable policy.
   • In the policies view, locate the Kubernetes Actions: Port Forward to Pod policy. Click the overflow menu, , and then select Disable policy.
3. Disable enforcement on any other custom policies that you have created by using criteria from the default Kubernetes Actions: Port Forward to Pod and Kubernetes Actions: Exec into Pod policies.

Procedure

1. In the RHACS portal, go to Platform Configuration → Clusters.
2. Select an existing cluster from the list.
3. Turn off the Enable Admission Controller Webhook to listen on exec and port-forward events toggle in the Static Configuration section.
4. Select Next to continue with Sensor setup.
5. Click Download YAML file and keys.

6. From a system that has access to the monitored cluster, extract and run the sensor script:

   $ unzip -d sensor sensor-<cluster_name>.zip

   $ ./sensor/sensor.sh

   Note

   If you get a warning that you do not have the required permissions to deploy the sensor, follow the on-screen instructions, or contact your cluster administrator for help.

   After the sensor is deployed, it contacts Central and provides cluster information.

7. Return to the RHACS portal and check if the deployment is successful. If it is successful, a green checkmark appears under section #2. If you do not see a green checkmark, use the following command to check for problems:

   • On OpenShift Container Platform:

     $ oc get pod -n stackrox -w

   • On Kubernetes:

     $ kubectl get pod -n stackrox -w

8. Select Finish.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.
2. Click the Policy categories tab. This tab provides a list of existing categories and allows you to filter the list by category name. You can also click Show all categories and select the checkbox to remove default or custom categories from the displayed list.
3. Click Create category.
4. Enter a category name and click Create.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.
2. Click the Policy categories tab. This tab provides a list of existing categories and allows you to filter the list by category name. You can also click Show all categories and select the checkbox to remove default or custom categories from the displayed list.
3. Click a policy name to edit or delete it. Default policy categories cannot be selected, edited, or deleted.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.
2. Click Create policy.

3. Enter the following details about your policy in the Policy details section:

   • Enter a Name for the policy.

   • Optional: Attach notifiers to the policy by selecting from the available Notifiers under the Attach notifiers section.

     Note

     Before you can forward alerts, you must integrate RHACS with your notification provider, such as webhooks, Jira, PagerDuty, Splunk, or others.

   • Select a Severity level for this policy, either Critical, High, Medium, or Low.
   • Select policy Categories you want to apply to this policy. For information about creating categories, see "Creating and managing policy categories" later in this document.
   • Enter details about the policy in the Description field.
   • Enter an explanation about why the policy exists in the Rationale field.
   • Enter steps to resolve violations of this policy in the Guidance field.

   • Optional: Under the MITRE ATT&CK section, select the tactics and the techniques you want to specify for the policy.

     1. Click Add tactic, and then select a tactic from the drop-down list.
     2. Click the Add technique to add techniques for the selected tactic. You can specify multiple techniques for a tactic.
4. Click Next.

5. In the Policy behavior section, take the following steps:

   1. Select the Lifecycle stages to which your policy is applicable: Build, Deploy, or Runtime. You can select more than one stage.

      • Build-time policies apply to image fields such as CVEs and Dockerfile instructions.
      • Deploy-time policies can include all build-time policy criteria but they can also include data from your cluster configurations, such as running in privileged mode or mounting the Docker socket.
      • Runtime policies can include all build-time and deploy-time policy criteria but they can also include data about process executions during runtime.

   2. Optional: If you selected the Runtime lifecycle stage, select one of the following Event sources:

      • Deployment: RHACS triggers policy violations when event sources include process and network activity, pod exec and pod port forwarding.
      • RHACS triggers policy violations when event sources match Kubernetes audit log records.

6. For Response method, select one of the following options:

   1. Inform: include the violation in the violations list.
   2. Inform and enforce: enforce actions.

7. Optional: If you selected Inform and enforce, in Configure enforcement behavior, select the enforcement behavior for the policy by using the toggle for each lifecycle. It is only available for the stages you select when configuring Lifecycle stages. The enforcement behavior is different for each lifecycle stage.

   • Build: RHACS fails your continuous integration (CI) builds when images match the criteria of the policy.

   • Deploy: For the Deploy stage, RHACS blocks the creation and update of deployments that match the conditions of the policy if the RHACS admission controller is configured and running.

     • In clusters with admission controller enforcement, the Kubernetes or OpenShift Container Platform API server blocks all noncompliant deployments. In other clusters, RHACS edits noncompliant deployments to prevent pods from being scheduled.
     • For existing deployments, policy changes only result in enforcement at the next detection of the criteria, when a Kubernetes event occurs. For more information about enforcement, see "Security policy enforcement for the deploy stage".

   • Runtime - RHACS deletes all pods when an event in the pods matches the criteria of the policy.

     Warning

     Policy enforcement can impact running applications or development processes. Before you enable enforcement options, inform all stakeholders and plan about how to respond to automated enforcement actions.

8. Click Next.

9. In the Policy Criteria section, configure the attributes that you want to trigger the policy for.

   1. Click and drag policy fields into the Policy Section to add criteria.

      Note

      The policy fields that are available depend on the lifecycle stage you chose for the policy. For example, criteria under Kubernetes access policies or Networking are available when creating a policy for the runtime lifecycle, but not when creating a policy for the build lifecycle. See "Policy criteria" in the "Additional resources" section for more information about policy criteria, including information about criteria and the lifecycle phase in which they are available.

   2. Optional: Click Add condition to add policy sections that contain additional criteria that will trigger the policy (for example, to trigger on old, stale images, you can configure that image tag is not latest or image age and specify a minimum number of days since an image is built).
10. Click Next.

11. In the Policy scope section, configure the following:

    • Click Add inclusion scope to use Restrict by scope to enable this policy only for a specific cluster, a namespace, or a label. You can add multiple scopes and also use regular expression in RE2 Syntax for namespaces and labels.
    • Click Add exclusion scope to use Exclude by scope to exclude deployments, clusters, namespaces, and labels you specify. The policy will not apply to the entities that you select. You can add multiple scopes and also use regular expression in RE2 Syntax for namespaces and labels. However, you cannot use regular expression for selecting deployments.

    • For Excluded Images (Build Lifecycle only), select all images that you do not want to trigger a violation for.

      Note

      The Excluded Images setting only applies when you check images in a continuous integration system with the Build lifecycle stage. It does not have any effect if you use this policy to check running deployments in the Deploy lifecycle stage or runtime activities in the Runtime lifecycle stage.

12. Click Next.
13. In the Review policy section, preview the policy violations.
14. Click Save.

Procedure

1. Go to the RHACS portal and select Risk from the navigation menu.
2. Apply local page filtering criteria that you want to create a policy for.
3. Select New Policy and fill in the required fields to create a new policy.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.
2. From the Policies page, select the policy you want to edit.
3. Select Actions → Export policy to JSON.

Procedure

1. In the RHACS portal, go to Platform Configuration → Policy Management.
2. Click Import policy.
3. In the Import policy JSON dialog, click Upload and select the JSON file you want to upload.
4. Click Begin import.

1. In the RHACS portal, go to Network Graph and select your cluster from the drop-down list.
2. Click the Namespaces list and use the search field to locate a namespace, or select individual namespaces.
3. Click the Deployments list and use the search field to locate a deployment, or select individual deployments to display in the network graph.
4. In the network graph, click on a deployment to view the information panel.
5. Click the Details, Flows, Baseline, or Network policies tab to view the corresponding information.

Procedure

1. In the RHACS portal, go to Network Graph and select your cluster from the drop-down list.
2. Click the Namespaces list and select individual namespaces, or use the search field to locate a namespace.
3. Click the Deployments list and select individual deployments, or use the search field to locate a deployment.
4. In the network graph, click on a deployment to view the information panel.

5. In the Details tab, in the Network security section, you can view summary messages about network policy rules that give the following information:

   • If policies exist in the network that regulate ingress or egress traffic
   • If your network is missing policies and is therefore allowing all ingress or egress traffic
6. To view the YAML file for the network policies, you can click on the policy rule, or click the Network policies tab.

Procedure

1. In the RHACS portal, go to Network Graph, and then select Manage CIDR Blocks. You can perform the following actions:

   • Toggle Auto-discovered CIDR blocks to hide auto-discovered CIDR blocks in the network graph.

     Note

     When you hide the auto-discovered CIDR blocks, the auto-discovered CIDR blocks are hidden for all clusters, and not only for the selected cluster in the network graph.

   • Add a custom CIDR block to the graph by performing the following steps:

     1. Enter the CIDR name and CIDR address in the fields. To add additional CIDR blocks, click Add CIDR block and enter information for each block.
     2. Click Update Configuration to save the changes.

1. In the RHACS portal, go to Network Graph.
2. Select a cluster, and then select one or more namespaces.
3. Optional: Select individual deployments to restrict the policy generated to only those deployments. You can also use the Filter deployments feature to further narrow the scope.
4. In the network graph header, select Network policy generator.

5. Optional: In the information panel that opens, select Exclude ports & protocols to remove the port/protocol restrictions when generating network policies from a baseline.

   As an example, the nginx3 deployment makes a port 80 connection to nginx4, and this is included as part of the baseline for nginx4. If policies are generated and this checkbox is not selected (the default behavior), the generated policy will restrict the allowed connections from nginx3 to nginx4 to only port 80. If policies are generated with this option selected, the generated policy will allow any port in the connection from nginx3 to nginx4.

6. Click Generate and simulate network policies. RHACS generates policies for the scope that you have chosen. This scope is displayed at the top of the Generate network policies panel.

   Note

   Clicking on the deployment information in the scope displays a list of the deployments that are included.

7. Optional: Copy the generated network policy configuration YAML file to the clipboard or download it by clicking the download icon in the panel.

8. Optional: To compare the generated network policies to the existing network policies, click Compare. The YAML files for existing and generated network policies are shown in a side-by-side view.

   Note

   Some items do not have generated policies, such as namespaces with existing ingress policies or deployments in certain protected namespaces such as as stackrox or acs.

9. Optional: Click the Actions menu to perform the following activities:

   • Share the YAML file with notifiers: Sends the YAML file to one of the system notifiers you have configured, for example, Slack, ServiceNow, or an application that uses generic webhooks. These notifiers are configured by navigating to Platform Configuration → Integrations. See the documentation in the "Additional resources" section for more information.
   • Rebuild rules from active traffic: Refreshes the generated policies that are displayed.
   • Revert rules to previously applied YAML: Removes the simulated policy and reverts to the last network policy.

Procedure

1. To create policies using the saved YAML file, run the following command:

   $ oc create -f "<generated_file>.yml" 1

   1

   If you use Kubernetes, enter kubectl instead of oc.

2. If the generated policies cause problems, you can remove them by running the following command:

   $ oc delete -f "<generated_file>.yml" 1

   1

   If you use Kubernetes, enter kubectl instead of oc.

Procedure

1. In the RHACS portal, go to Network Graph.
2. Select a cluster name from the menu on the top bar.
3. Select one or more namespaces and deployments.
4. Select Simulate network policy.
5. Select View active YAMLS.

6. From the Actions menu, select Revert rules to previously applied YAML.

   Warning

   Directly applying network policies might cause problems for running applications. Always download and test the network policies in a development environment or test clusters before applying them to production workloads.

Procedure

1. In the RHACS portal, go to Network Graph.
2. Select a cluster, and then select one or more namespaces.
3. On the network graph header, select Network policy generator.
4. Optional: To generate a YAML file with network policies to use in the simulation, click Generate and simulate network policies. For more information, see "Generating network policies in the network graph".

5. Upload a YAML file of a network policy that you want to use in the simulation. The network graph view displays what your proposed network policies would achieve. Perform the following steps:

   1. Click Upload YAML and then select the file.
   2. Click Open. The system displays a message to indicate the processing status of the uploaded policy.

6. You can view active YAML files that correspond to the current network policies by clicking the View active YAMLS tab, and then selecting policies from the drop-down list. You can also perform the following actions:

   • Click the appropriate button to copy or download the displayed YAML file.
   • Use the Actions menu to rebuild rules from active traffic or revert rules to a previously applied YAML. For more information, see "Generating network policies in the network graph".

Procedure

1. Click the Namespaces list and use the search field to locate a namespace, or select individual namespaces.
2. Click the Deployments list and use the search field to locate a deployment, or select individual deployments to display in the network graph.
3. In the network graph, click on a deployment to view the information panel.
4. Select the Baseline tab. Use the filter by entity name field to further restrict the flows that are displayed.

5. Optional: You can mark baseline flows as anomalous by performing one of the following actions:

   • Select an individual entity. Click the overflow menu, , and then select Mark as anomalous.
   • Select multiple entities, and then click Bulk actions and select Mark as anomalous.
6. Optional: Check the box to exclude ports and protocols.
7. Optional: To save the baseline as a network policy YAML file, click Download baseline as network policy.

Procedure

1. In the RHACS portal, go to Network Graph.
2. Click the Namespaces list and use the search field to locate a namespace, or select individual namespaces.
3. Click the Deployments list and use the search field to locate a deployment, or select individual deployments to display in the network graph.
4. In the network graph, click on a deployment to view the information panel.
5. The Baseline tab lists the baseline flows. Use the filter by entity name field to further restrict the list of flows.
6. Optional: Check the box to exclude ports and protocols.
7. Click Download baseline as network policy.

Procedure

1. Set the ROX_NETWORK_BASELINE_OBSERVATION_PERIOD environment variable by running the following command:

   $ oc -n stackrox set env deploy/central \1
     ROX_NETWORK_BASELINE_OBSERVATION_PERIOD=<value> 2

   1

   If you use Kubernetes, enter kubectl instead of oc.

   2

   Value must be time units, for example: 300ms, -1.5h, or 2h45m. Valid time units are ns, us or µs, ms, s, m, h.

2. Set the ROX_BASELINE_GENERATION_DURATION environment variable by running the following command:

   $ oc -n stackrox set env deploy/central \1
     ROX_BASELINE_GENERATION_DURATION=<value> 2

   1

   If you use Kubernetes, enter kubectl instead of oc.

   2

   Value must be time units, for example: 300ms, -1.5h, or 2h45m. Valid time units are ns, us or µs, ms, s, m, h.

Procedure

1. Click the Namespaces list and use the search field to locate a namespace, or select individual namespaces.
2. Click the Deployments list and use the search field to locate a deployment, or select individual deployments to display in the network graph.
3. In the network graph, click on a deployment to view the information panel.
4. In the Baseline tab, you can view baseline flows. Use the filter by entity name field to further restrict the flows that are displayed.

5. Toggle the Alert on baseline violations option.

   • After you toggle the Alert on baseline violations option, anomalous network flows trigger violations.
   • You can toggle the Alert on baseline violations option again to stop receiving violations for anomalous network flows.

Prerequisites

1. The build-time network policy generator recursively scans the directory you specify when you run the command. Therefore, before you run the command, you must already have service manifests, config maps, and workload manifests such as Pod, Deployment, ReplicaSet, Job, DaemonSet, and StatefulSet as YAML files in the specified directory.
2. Verify that you can apply these YAML files as-is using the kubectl apply -f command. The build-time network policy generator does not work with files that use Helm style templating.

3. Verify that the service network addresses are not hard-coded. Every workload that needs to connect to a service must specify the service network address as a variable. You can specify this variable by using the workload’s resource environment variable or in a config map.

   • Example 1: using an environment variable
   • Example 2: using a config map
   • Example 3: using a config map

4. Service network addresses must match the following official regular expression pattern:

   (http(s)?://)?<svc>(.<ns>(.svc.cluster.local)?)?(:<portNum>)? 1

   1

   In this pattern,

   • <svc> is the service name.
   • <ns> is the namespace where you defined the service.
   • <portNum> is the exposed service port number.

   Following are some examples that match the pattern:

   • wordpress-mysql:3306
   • redis-follower.redis.svc.cluster.local:6379
   • redis-leader.redis
   • http://rating-service.

Procedure

1. Verify that the build-time network policy generation feature is available by running the help command:

   $ roxctl netpol generate -h

2. Generate the policies by using the netpol generate command:

   $ roxctl netpol generate <folder_path> [flags] 1

   1

   Specify the path to the folder, which can include sub-folders that contain YAML resources for analysis. The command scans the entire sub-folder tree. Optionally, you can also specify parameters to modify the behavior of the command.

   For more information about optional parameters, see roxctl netpol generate command options.

Procedure

1. Go to the RHACS portal and click Configuration Management.
2. Select Role-Based Access Control → Users and Groups from the header in the Configuration Management view. The Users and Groups view displays a list of Kubernetes users and groups, their assigned roles, and whether the cluster-admin role is enabled for each of them.
3. Select a user or group to view more details about the associated cluster and namespace permissions.

Procedure

1. In the RHACS portal, go to Configuration Management.
2. Select RBAC Visibility and Configuration → Service Accounts from the header in the Configuration Management view. The Service Accounts view displays a list of Kubernetes service accounts across your clusters, their assigned roles, whether the cluster-admin role is enabled, and which deployments use them.
3. Select a row or an underlined link to view more details, including which cluster and namespace permissions are granted to the selected service account.

Procedure

1. In the RHACS portal, go to Configuration Management.
2. Select RBAC Visibility and Configuration → Roles from the header in the Configuration Management view. The Roles view displays a list of Kubernetes roles across your clusters, the permissions they grant, and where they are used.
3. Select a row or an underlined link to view more details about the role.
4. To find roles not granted to any users, groups, or service accounts, select the Users & Groups column header. Then select the Service Account column header while holding the Shift key. The list shows the roles that are not granted to any users, groups, or service accounts.