Operating


Red Hat Advanced Cluster Security for Kubernetes 4.5

Operating Red Hat Advanced Cluster Security for Kubernetes

Red Hat OpenShift Documentation Team

Abstract

This document describes how to perform common operating tasks in Red Hat Advanced Cluster Security for Kubernetes, including using the dashboards, managing compliance, evaluating security risks, managing security policies and network policies, examining images for vulnerabilities, and responding to violations.

Chapter 1. Viewing the dashboard

The Red Hat Advanced Cluster Security for Kubernetes (RHACS) Dashboard provides quick access to the data you need. It contains additional navigation shortcuts and actionable widgets that are easy to filter and customize so that you can focus on the data that matters most to you. You can view information about levels of risk in your environment, compliance status, policy violations, and common vulnerabilities and exposures (CVEs) in images.

Note

When you open the RHACS portal for the first time, the Dashboard might be empty. After you deploy Sensor in at least one cluster, the Dashboard reflects the status of your environment.

The following sections describe the Dashboard components.

1.2. Dashboard filter

The Dashboard includes a top-level filter that applies simultaneously to all widgets. You can select one or more clusters, and one or more namespaces within selected clusters. When no clusters or namespaces are selected, the view automatically switches to All. Any change to the filter is immediately reflected by all widgets, limiting the data they present to the selected scope. The Dashboard filter does not affect the Status Bar.

1.3. Widget options

Some widgets are customizable to help you focus on specific data. Widgets offer different controls that you can use to change how the data is sorted, filter the data, and customize the output of the widget.

Widgets offer two ways to customize different aspects:

  • An Options menu, when present, provides specific options applicable to that widget.
  • A dynamic axis legend, when present, provides a method to filter data by hiding one or more of the axis categories. For example, in the Policy violations by category widget, you can click on a severity to include or exclude violations of a selected severity from the data.
Note

Individual widget customization settings are short-lived and are reset to the system default upon leaving the Dashboard.

1.4. Actionable widgets

The following sections describe the actionable widgets available in the Dashboard.

1.4.1. Policy violations by severity

This widget shows the distribution of violations across severity levels for the Dashboard-filtered scope. Clicking a severity level in the chart takes you to the Violations page, filtered for that severity and scope. It also lists the three most recent violations of a Critical level policy within the scope you defined in the Dashboard filter. Clicking a specific violation takes you directly to the Violations detail page for that violation.

1.4.2. Images at most risk

This widget lists the top six vulnerable images within the Dashboard-filtered scope, sorted by their computed risk priority, along with the number of critical and important CVEs they contain. Click on an image name to go directly to the Image Findings page under Vulnerability Management. Use the Options menu to focus on fixable CVEs, or further focus on active images.

Note

When clusters or namespaces have been selected in the Dashboard filter, the data displayed is already filtered to active images, or images that are used by deployments within the filtered scope.

1.4.3. Deployments at most risk

This widget provides information about the top deployments at risk in your environment. It displays additional information such as the resource location (cluster and namespace) and the risk priority score. Additionally, you can click on a deployment to view risk information about the deployment; for example, its policy violations and vulnerabilities.

1.4.4. Aging images

Older images present a higher security risk because they can contain vulnerabilities that have already been addressed. If older images are active, they can expose deployments to exploits. You can use this widget to quickly assess your security posture and identify offending images. You can use the default ranges or customize the age intervals with your own values. You can view both inactive and active images or use the Dashboard filter to focus on a particular area for active images. You can then click on an age group in this widget to view only those images in the Vulnerability ManagementImages page.

1.4.5. Policy violations by category

This widget can help you gain insights about the challenges your organization is facing in complying with security policies, by analyzing which types of policies are violated more than others. The widget shows the five policy categories of highest interest. Explore the Options menu for different ways to slice the data. You can filter the data to focus exclusively on deploy or runtime violations.

You can also change the sorting mode. By default, the data is sorted by the number of violations within the highest severity first. Therefore, all categories with critical policies will appear before categories without critical policies. The other sorting mode considers the total number of violations regardless of severity. Because some categories contain no critical policies (for example, “Docker CIS”), the two sorting modes can provide significantly different views, offering additional insight.

Click on a severity level at the bottom of the graph to include or exclude that level from the data. Selecting different severity levels can result in a different top five selection or ranking order. Data is filtered to the scope selected by the Dashboard filter.

1.4.6. Compliance by standard

You can use the Compliance by standard widget with the Dashboard filter to focus on areas that matter to you the most. The widget lists the top or bottom six compliance benchmarks, depending on sort order. Select Options to sort by the coverage percentage. Click on one of the benchmark labels or graphs to go directly to the Compliance Controls page, filtered by the Dashboard scope and the selected benchmark.

Note

The Compliance widget shows details only after you run a compliance scan.

For more information, see Checking the compliance status of your infrastructure.

Chapter 2. Using the Compliance Operator with Red Hat Advanced Cluster Security for Kubernetes

You can configure RHACS to use the Compliance Operator for compliance reporting and remediation with OpenShift Container Platform clusters. Results from the Compliance Operator are reported in the RHACS Compliance Dashboard.

The Compliance Operator automates the review of numerous technical implementations and compares them with certain aspects of industry standards, benchmarks, and baselines.

The Compliance Operator is not an auditor. To comply or certify to these various standards, you must engage an authorized auditor such as a Qualified Security Assessor (QSA), Joint Authorization Board (JAB), or other industry-recognized regulatory authority to assess your environment.

The Compliance Operator makes recommendations based on generally available information and practices that relate to such standards and can assist with remediation, but actual compliance is your responsibility. You are required to work with an authorized auditor to achieve compliance with a standard.

For the latest updates, see the Compliance Operator release notes.

2.1. Installing the Compliance Operator

Install the Compliance Operator by using the Operator Hub.

Procedure

  1. In the web console, go to the OperatorsOperatorHub page.
  2. Enter compliance operator into the Filter by keyword box to find the Compliance Operator.
  3. Select the Compliance Operator to view the details page.
  4. Read the information about the Operator, and then click Install.
Important
  • If you use the compliance feature, you can schedule your scan by using RHACS to create a compliance scan schedule.

    For more information about scheduling a compliance scan by using the compliance feature, see "Customizing and automating your compliance scans".

  • If you create a scan schedule, you do not need to create the ScanSettingBinding on the Compliance Operator.

2.2. Configuring the ScanSettingBinding object

By creating a ScanSettingBinding object in the openshift-compliance namespace, you can scan your cluster by using the cis and cis-node profiles either from the command-line interface (CLI) or user interface (UI).

Important

This example uses ocp4-cis and ocp4-cis-node profiles, but OpenShift Container Platform provides additional profiles.

For more information, see "Understanding the Compliance Operator".

Prerequisites

  • You have installed the Compliance Operator.

Procedure

  • To create the ScanSettingBinding object from the CLI, perform the following steps:

    1. Create a file named sscan.yaml by using the following content:

      apiVersion: compliance.openshift.io/v1alpha1
      kind: ScanSettingBinding
      metadata:
        name: cis-compliance
      profiles:
        - name: ocp4-cis-node
          kind: Profile
          apiGroup: compliance.openshift.io/v1alpha1
        - name: ocp4-cis
          kind: Profile
          apiGroup: compliance.openshift.io/v1alpha1
      settingsRef:
        name: default
        kind: ScanSetting
        apiGroup: compliance.openshift.io/v1alpha1
    2. Create the ScanSettingBinding object by running the following command:

      $ oc create -f sscan.yaml -n openshift-compliance

      If successful, the following message is displayed:

      $ scansettingbinding.compliance.openshift.io/cis-compliance created
  • To create the ScanSettingBinding object from the UI, perform the following steps:

    1. Change the active project to openshift-compliance.
    2. Click + to open the Import YAML page.
    3. Paste the YAML from the previous example, and then click Create.

Verification

  1. Run a compliance scan in RHACS.

    For more information about how to run a compliance scan by using the compliance feature, see "Checking the compliance status of your infrastructure".

  2. Ensure that ocp4-cis and ocp4-cis-node results are displayed.
Important
  • If you are using the CLI, you can view the compliance scan results from the dashboard page.

    For more information about how to view the compliance scan results from the dashboard page, see "Viewing the compliance standards across your environment".

  • If you are using the UI, you can view the compliance scan results from both the dashboard and coverage page.

    For more information about how to view the compliance scan results from the coverage page, see "Assessing the profile compliance across clusters".

Chapter 3. Managing compliance

3.1. Compliance feature overview

The compliance feature ensures that your Kubernetes clusters adhere to industry standards and regulatory requirements. It provides automated compliance checks that enable you to continuously monitor your clusters against predefined benchmarks such as CIS, PCI-DSS, HIPAA, and so on.

The feature includes detailed reports and remediation guidance to help administrators quickly identify and resolve compliance issues. You can view the compliance results associated with your cluster by using the compliance feature in the Red Hat Advanced Cluster Security for Kubernetes (RHACS) portal.

The compliance feature summarizes information into the following sections:

  • Dashboard, formerly known as Compliance 1.0, summarizes the compliance information collected from all your clusters. It covers workload and infrastructure compliance.

    Important

    By running a compliance scan in RHACS, you can monitor the entire Kubernetes infrastructure and workloads and ensure that they meet the required standards. You can use the compliance dashboard for filtering and detailed reporting.

    For more information, see Monitoring workload and cluster compliance.

  • Schedules and Coverage (Tech preview), formerly known as Compliance 2.0, summarizes the compliance information in a single interface after the scheduled scans by using the Compliance Operator.

    Important

    If you have Red Hat OpenShift clusters with the Compliance Operator installed, you can create and manage compliance scan schedules directly in RHACS on the schedules page. The coverage page shows you the scan results associated with a benchmark and profile in a single interface.

    For more information, see Scheduling compliance scans and assessing profile compliance (Technology preview).

3.1.1. Compliance assessment and reporting by using RHACS

On the dashboard page, you can assess and report on the compliance of your containerized infrastructure and workloads with the applicable technical controls from a range of security and regulatory frameworks.

You can run out-of-the-box compliance scans based on the following industry standards:

  • Center for Internet Security (CIS) Benchmarks for Kubernetes
  • Health Insurance Portability and Accountability Act (HIPAA)
  • National Institute of Standards and Technology (NIST) Special Publication 800-190
  • NIST Special Publication 800-53
  • Payment Card Industry Data Security Standard (PCI DSS)
  • OpenShift Compliance Operator Profiles: The Compliance Operator evaluates the compliance of both the OpenShift Container Platform Kubernetes API resources and the nodes running the cluster. There are several profiles available as part of the Compliance Operator installation.

    For more information about the available profiles, see Supported compliance profiles.

By scanning your environment based on these standards, you can:

  • Evaluate your infrastructure for regulatory compliance.
  • Harden your Kubernetes orchestrator.
  • Understand and manage the overall security posture of your environment.
  • Get a detailed overview of the compliance status of clusters, namespaces, and nodes.

3.2. Monitoring workload and cluster compliance

By performing compliance scans, you can check the compliance status of your entire infrastructure in RHACS. You can view the results in the compliance dashboard, where you can filter data and monitor compliance status across clusters, namespaces and nodes.

By generating detailed compliance reports and focusing on specific standards, controls and industry benchmarks, you can track and share the compliance status of your environment, and ensure that your infrastructure meets the required compliance standards.

3.2.1. Checking the compliance status of your infrastructure

By performing a compliance scan, you can check the compliance status of your entire infrastructure for all compliance standards. When you run a compliance scan, Red Hat Advanced Cluster Security for Kubernetes (RHACS) creates a data snapshot of your environment. The data snapshot includes alerts, images, network policies, deployments, and related host-based data.

Central collects the host-based data from Sensors running in your clusters. Central then collects further data from the compliance container running in each Collector pod.

The compliance container collects the following data about your environment:

  • Configurations for the container daemon, container runtime and container image.
  • Information about container networks.
  • Command-line arguments and processes for the container runtime, Kubernetes, and OpenShift Container Platform.
  • Permissions for specific file paths.
  • Configuration files for Kubernetes and OpenShift Container Platform core services.
  • After data collection is complete, Central checks the data to determine the results. You can view the results in the compliance dashboard and create compliance reports based on the results.
Note
  • The following terms are associated with a compliance scan:

    • Control describes a single line item in an industry or regulatory standard that an auditor uses to evaluate an information system for compliance with that standard. RHACS verifies evidence of compliance with a single control by performing one or more checks.
    • Check is the single test performed during a single control assessment.
  • Some controls have multiple checks associated with them. If one of the associated checks for a control fails, the entire control state is marked as Fail.

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.

3.2.2. Viewing the compliance standards across your environment

The compliance dashboard gives you an overview of the compliance standards in all clusters, namespaces, and nodes in your environment, including charts and options to investigate potential compliance issues.

You can view the compliance scan results for an individual cluster, namespace, or node. You can also generate reports on the compliance status of your containerized environment.

Procedure

  • In the RHACS portal, click Compliance → Dashboard.

    Note

    When you open the compliance dashboard for the first time, you see the dashboard is empty. Perform a compliance scan to fill the dashboard with data.

3.2.3. Compliance dashboard overview

After you have performed a compliance scan, the compliance dashboard displays the results as the compliance status for your environment. You can view compliance violations directly from the dashboard. To find out if your environment is compliant against specific benchmarks, filter the detailed view and drill down into the compliance standards.

You can use shortcuts to check the compliance status of clusters, namespaces, and nodes, which are located at the upper right of your compliance dashboard. Clicking these shortcuts, you can view the compliance snapshot and generate reports on the overall compliance of your clusters, namespaces, or nodes.

3.2.3.1. Viewing the compliance status for clusters

By viewing the compliance status for clusters, you can monitor and ensure that your clusters adhere to the required compliance standards.

You can view the compliance status for all clusters or an individual cluster in the compliance dashboard.

Procedure

  • To view the compliance status for all clusters in your environment:

    • In the RHACS portal, click Compliance → Dashboardclusters tab.
  • To view the compliance status for a specific cluster in your environment, perform the following steps:

    • In the RHACS portal, click Compliance → Dashboard.
    • Look for the Passing standards by cluster widget.
    • In this widget, click a cluster name to view its compliance status.
3.2.3.2. Viewing the compliance status for namespaces

By viewing the compliance status for namespaces, you can monitor and ensure that each namespace adheres to the required compliance standards.

You can view the compliance status for all namespaces or a single namespace in the compliance dashboard.

Procedure

  • To view the compliance status for all namespaces in your environment:

    • In the RHACS portal, click Compliance → Dashboard → namespaces tab.
  • To view the compliance status for a specific namespace in your environment, perform the following steps:

    • In the RHACS portal, click Compliance → Dashboard → namespaces tab.
    • In the Namespaces table, click a namespace. A side panel opens, which is located on the right side.
    • In the side panel, click the name of the namespace to view its compliance status.
3.2.3.3. Viewing the compliance status for a specific standard

By viewing the compliance status for a specific standard, you can ensure that your environment adheres to industry and regulatory compliance requirements.

Red Hat Advanced Cluster Security for Kubernetes (RHACS) supports NIST, PCI DSS, NIST, HIPAA, and CIS for Kubernetes compliance standards. You can view all the compliance controls for a single compliance standard.

Procedure

  1. In the RHACS portal, click Compliance → Dashboard.
  2. Look for the Passing standards across clusters widget.
  3. Click a standard to view information about all the controls associated with that standard.

Additional resources

3.2.3.4. Viewing the compliance status for a specific control

By viewing the compliance status for a specific control, you can ensure that your environment meets detailed compliance requirements.

You can view the compliance status for a specific control for a selected standard.

Procedure

  1. In the RHACS portal, click Compliance → Dashboard.
  2. Look for the Passing standards by cluster widget.
  3. Click a standard to view information about all the controls associated with that standard.
  4. In the Controls table, click a control. A side panel opens, which is located on the right side.
  5. In the side panel, click the name of the control to view its details.

3.2.4. Limiting the amount of data visible in the compliance dashboard

By filtering the compliance data, you can focus your attention on a subset of clusters, industry standards, passed or failed controls, and limit the amount of data visible in the compliance dashboard.

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.

3.2.5. Tracking the compliance status of your environment

By generating compliance reports, you can keep a track of the compliance status of your environment. You can use these reports to convey compliance status across various industry mandates to other stakeholders.

You can generate the following reports:

  • Executive reports that focus on the business aspect and include charts and a summary of the compliance status in PDF format.
  • Evidence reports that focus on the technical aspect and contain detailed information in CSV format.

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.

3.2.5.1. Evidence reports

You can export comprehensive compliance-related data from Red Hat Advanced Cluster Security for Kubernetes (RHACS) in CSV format as an evidence report. This evidence report contains detailed information about the compliance assessment, and is tailored for technical roles, such as compliance auditors, DevOps engineers, or security practitioners.

An evidence report contains the following information:

CSV fieldDescription

Standard

The compliance standard, for example, CIS Kubernetes.

Cluster

The name of the assessed cluster.

Namespace

The name of the namespace or project where the deployment exists.

Object Type

The Kubernetes entity type of the object. For example, node, cluster, DaemonSet, Deployment, or StaticPod.

Object Name

The name of the object, which is a Kubernetes systems-generated string that uniquely identify objects. For example, gke-setup-dev21380-default-pool-8e086a77-1jfq.

Control

The control number as it appears in the compliance standard.

Control Description

Description about the compliance check that the control carries out.

State

Whether the compliance check passed or failed.

Evidence

The explanation about why a specific compliance check failed or passed.

Assessment Time

The time and date when you ran the compliance scan.

3.2.6. Supported benchmark versions

Red Hat Advanced Cluster Security for Kubernetes (RHACS) supports compliance checks against the following industry standards and regulatory frameworks:

BenchmarkSupported version

CIS Benchmark (Center for Internet Security) for Kubernetes

CIS Kubernetes v1.5.0

HIPAA (Health Insurance Portability and Accountability Act)

HIPAA 164

NIST (National Institute of Standards and Technology)

NIST Special Publication 800-190 and 800-53 Rev. 4

PCI DSS (Payment Card Industry Data Security Standard)

PCI DSS 3.2.1

3.3. Scheduling compliance scans and assessing profile compliance (Technology preview)

Important

Scheduling compliance scans and assessing profile compliance is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

You can create and manage compliance scan schedules on the schedules page that meet your operational needs. You can only have one schedule that scans the same profile on the same cluster.

By viewing and filtering the scan results on the coverage page, you can monitor the compliance status across all clusters.

3.3.1. Customizing and automating your compliance scans

By creating a compliance scan schedule, you can customize and automate your compliance scans to align with your operational requirements.

Note

You can only have one schedule that scans the same profile on the same cluster. This means that you cannot create multiple scan schedules for the same profile on a single cluster.

Prerequisites

  • You have installed the Compliance Operator.

    For more information about how to install the Compliance Operator, see "Using the Compliance Operator with Red Hat Advanced Cluster Security for Kubernetes".

    Note
    • Currently, the compliance feature and the Compliance Operator evaluate only infrastructure and platform compliance.
    • The compliance feature requires the Compliance Operator to be running and does not support Amazon Elastic Kubernetes Service (EKS).

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.

3.3.2. Assessing the profile compliance across clusters

By viewing the coverage page, you can assess the profile compliance for nodes and platform resources across clusters.

Prerequisites

  • You have installed the Compliance Operator.

    For more information about how to install the Compliance Operator, see "Using the Compliance Operator with Red Hat Advanced Cluster Security for Kubernetes".

    Note
    • Currently, the compliance feature and the Compliance Operator evaluate only infrastructure and platform compliance.
    • The compliance feature requires the Compliance Operator to be running and does not support Amazon Elastic Kubernetes Service (EKS).
  • You have created a compliance scan schedule.

    For more information about how to create a compliance scan schedule, see "Customizing and automating your compliance scans".

Procedure

  • In the RHACS portal, click Compliance → Coverage.

3.3.3. Coverage page overview

When you view the coverage page and apply a filter to a schedule, all results are filtered accordingly. This filter remains active for all coverage pages until you delete it. You can always view the results based on a single profile.

You can select profiles grouped according to their associated benchmarks by using the toggle group. You calculate the compliance percentage based on the number of passed checks in relation to the total number of checks.

The Checks view lists the profile checks and enables you to easily navigate and understand your compliance status.

The profile check information is organized into the following groups:

  • Check: The name of the profile check.
  • Controls: Shows the various controls associated with each check.
  • Fail status: Shows the checks that have failed and require your attention.
  • Pass status: Shows the checks that have been successfully passed.
  • Manual status: Shows the checks that require a manual review because additional organizational or technical knowledge is required that you cannot automate.
  • Other status: Shows the checks with a status other than pass or fail, such as warnings or informational statuses.
  • Compliance: Shows the overall compliance status and helps you to ensure that your environment meets the required standards.

The Clusters view lists the clusters and enables you to effectively monitor and manage your clusters.

The cluster information is organized into the following groups:

  • Cluster: The name of the cluster.
  • Last scanned: Indicates when the individual clusters were last scanned.
  • Fail status: Shows the clusters whose scan has failed and which require your attention.
  • Pass status: Shows the clusters that have successfully passed all checks.
  • Manual status: Shows the checks that require a manual review because additional organizational or technical knowledge is required that you cannot automate.
  • Other status: Shows the clusters that have a status other than pass or fail, such as warnings or informational alerts.
  • Compliance: Shows the overall compliance status of your clusters and helps you to ensure that they meet the required standards.

3.3.4. Monitoring and analyzing the health of your clusters

By viewing the status of a profile check, you can efficiently monitor and analyze the health of your clusters.

Important

Wait until the Compliance Operator returns the scan results. It might take a few minutes.

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

3.3.5. Compliance scan status overview

By understanding the compliance scan status, you can manage the overall security posture of your environment.

StatusDescription

Fail

The compliance check failed.

Pass

The compliance check passed.

Not Applicable

Skipped the compliance check because it was not applicable.

Info

The compliance check gathered data, but RHACS could not make a pass or fail determination.

Error

The compliance check failed due to a technical issue.

Manual

Manual intervention is required to ensure compliance.

Inconsistent

The compliance scan data is inconsistent, and requires closer inspection and targeted resolution.

Chapter 4. Evaluating security risks

Red Hat Advanced Cluster Security for Kubernetes assesses risk across your entire environment and ranks your running deployments according to their security risk. It also provides details about vulnerabilities, configurations, and runtime activities that require immediate attention.

4.1. Risk view

The Risk view lists all deployments from all clusters, sorted by a multi-factor risk metric based on policy violations, image contents, deployment configuration, and other similar factors. Deployments at the top of the list present the most risk.

The Risk view shows list of deployments with following attributes for each row:

  • Name: The name of the deployment.
  • Created: The creation time of the deployment.
  • Cluster: The name of the cluster where the deployment is running.
  • Namespace: The namespace in which the deployment exists.
  • Priority: A priority ranking based on severity and risk metrics.

In the Risk view, you can:

  • Select a column heading to sort the violations in ascending or descending order.
  • Use the filter bar to filter violations.
  • Create a new policy based on the filtered criteria.

To view more details about the risks for a deployment, select a deployment in the Risk view.

4.1.1. Opening the risk view

You can analyze all risks in the Risk view and take corrective action.

Procedure

  • Go to the RHACS portal and select Risk from the navigation menu.

4.2. Creating a security policy from the risk view

While evaluating risks in your deployments in the Risk view, when you apply local page filtering, you can create new security policies based on the filtering criteria you are using.

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.

4.2.1. Understanding how Red Hat Advanced Cluster Security for Kubernetes transforms the filtering criteria into policy criteria

When you create new security policies from the Risk view, based on the filtering criteria you use, not all criteria are directly applied to the new policy.

  • Red Hat Advanced Cluster Security for Kubernetes converts the Cluster, Namespace, and Deployment filters to equivalent policy scopes.

    • Local page filtering on the Risk view combines the search terms by using the following methods:

      • Combines the search terms within the same category with an OR operator. For example, if the search query is Cluster:A,B, the filter matches deployments in cluster A or cluster B.
      • Combines the search terms from different categories with an AND operator. For example, if the search query is Cluster:A+Namespace:Z, the filter matches deployments in cluster A and in namespace Z.
    • When you add multiple scopes to a policy, the policy matches violations from any of the scopes.

      • For example, if you search for (Cluster A OR Cluster B) AND (Namespace Z) it results in two policy scopes, (Cluster=A AND Namespace=Z) OR (Cluster=B AND Namespace=Z).
  • Red Hat Advanced Cluster Security for Kubernetes drops or modifies filters that do not directly map to policy criteria and reports the dropped filters.

The following table lists how the filtering search attributes map to the policy criteria:

Search attributePolicy criteria

Add Capabilities

Add Capabilities

Annotation

Disallowed Annotation

CPU Cores Limit

Container CPU Limit

CPU Cores Request

Container CPU Request

CVE

CVE

CVE Published On

✕ Dropped

CVE Snoozed

✕ Dropped

CVSS

CVSS

Cluster

⟳ Converted to scope

Component

Image Component (name)

Component Version

Image Component (version)

Deployment

⟳ Converted to scope

Deployment Type

✕ Dropped

Dockerfile Instruction Keyword

Dockerfile Line (key)

Dockerfile Instruction Value

Dockerfile Line (value)

Drop Capabilities

✕ Dropped

Environment Key

Environment Variable (key)

Environment Value

Environment Variable (value)

Environment Variable Source

Environment Variable (source)

Exposed Node Port

✕ Dropped

Exposing Service

✕ Dropped

Exposing Service Port

✕ Dropped

Exposure Level

Port Exposure

External Hostname

✕ Dropped

External IP

✕ Dropped

Image

✕ Dropped

Image Command

✕ Dropped

Image Created Time

Days since image was created

Image Entrypoint

✕ Dropped

Image Label

Disallowed Image Label

Image OS

Image OS

Image Pull Secret

✕ Dropped

Image Registry

Image Registry

Image Remote

Image Remote

Image Scan Time

Days since image was last scanned

Image Tag

Image Tag

Image Top CVSS

✕ Dropped

Image User

✕ Dropped

Image Volumes

✕ Dropped

Label

⟳ Converted to scope

Max Exposure Level

✕ Dropped

Memory Limit (MB)

Container Memory Limit

Memory Request (MB)

Container Memory Request

Namespace

⟳ Converted to scope

Namespace ID

✕ Dropped

Pod Label

✕ Dropped

Port

Port

Port Protocol

Protocol

Priority

✕ Dropped

Privileged

Privileged

Process Ancestor

Process Ancestor

Process Arguments

Process Arguments

Process Name

Process Name

Process Path

✕ Dropped

Process Tag

✕ Dropped

Process UID

Process UID

Read Only Root Filesystem

Read-Only Root Filesystem

Secret

✕ Dropped

Secret Path

✕ Dropped

Service Account

✕ Dropped

Service Account Permission Level

Minimum RBAC Permission Level

Toleration Key

✕ Dropped

Toleration Value

✕ Dropped

Volume Destination

Volume Destination

Volume Name

Volume Name

Volume ReadOnly

Writable Volume

Volume Source

Volume Source

Volume Type

Volume Type

4.3. Viewing risk details

When you select a deployment in the Risk view, the Risk Details open in a panel on the right. The Risk Details panel shows detailed information grouped by multiple tabs.

4.3.1. Risk Indicators tab

The Risk Indicators tab of the Risk Details panel explains the discovered risks.

The Risk Indicators tab includes the following sections:

  • Policy Violations: The names of the policies that are violated for the selected deployment.
  • Suspicious Process Executions: Suspicious processes, arguments, and container names that the process ran in.
  • Image Vulnerabilities: Images including total CVEs with their CVSS scores.
  • Service Configurations: Aspects of the configurations that are often problematic, such as read-write (RW) capability, whether capabilities are dropped, and the presence of privileged containers.
  • Service Reachability: Container ports exposed inside or outside the cluster.
  • Components Useful for Attackers: Discovered software tools that are often used by attackers.
  • Number of Components in Image: The number of packages found in each image.
  • Image Freshness: Image names and age, for example, 285 days old.
  • RBAC Configuration: The level of permissions granted to the deployment in Kubernetes role-based access control (RBAC).
Note

Not all sections are visible in the Risk Indicators tab. Red Hat Advanced Cluster Security for Kubernetes displays only relevant sections that affect the selected deployment.

4.4. Deployment Details tab

The sections in the Deployment Details tab of the Deployment Risk panel provide more information so you can make appropriate decisions on how to address the discovered risk.

4.4.1. Overview section

The Overview section shows details about the following:

  • Deployment ID: An alphanumeric identifier for the deployment.
  • Namespace: The Kubernetes or OpenShift Container Platform namespace in which the deployment exists.
  • Updated: A timestamp with date for when the deployment was updated.
  • Deployment Type: The type of deployment, for example, Deployment or DaemonSet.
  • Replicas: The number of pods deployed for this deployment.
  • Labels: The key-value labels attached to the Kubernetes or OpenShift Container Platform application.
  • Cluster: The name of the cluster where the deployment is running.
  • Annotations: The Kubernetes annotations for the deployment.
  • Service Account: Represents an identity for processes that run in a pod. When a process is authenticated through a service account, it can contact the Kubernetes API server and access cluster resources. If a pod does not have an assigned service account, it gets the default service account.

4.4.2. Container configuration section

The container configuration section shows details about the following:

  • Image Name: The name of the image that is deployed.
  • Resources

    • CPU Request (cores): The number of CPUs requested by the container.
    • CPU Limit (cores): The maximum number of CPUs the container can use.
    • Memory Request (MB): The memory size requested by the container.
    • Memory Limit (MB): The maximum amount of memory the container can use without being killed.
  • Mounts

    • Name: The name of the mount.
    • Source: The path from where the data for the mount comes.
    • Destination: The path to which the data for the mount goes.
    • Type: The type of the mount.
  • Secrets: The names of Kubernetes secrets used in the deployment, and basic details for secret values that are X.509 certificates.

4.4.3. Security context section

The Security Context section shows details about the following:

  • Privileged: Lists true if the container is privileged.

4.5. Process discovery tab

The Process Discovery tab provides a comprehensive list of all binaries that have been executed in each container in your environment, summarized by deployment.

The process discovery tab shows details about the following:

  • Binary Name: The name of the binary that was executed.
  • Container: The container in the deployment in which the process executed.
  • Arguments: The specific arguments that were passed with the binary.
  • Time: The date and time of the most recent time the binary was executed in a given container.
  • Pod ID: The identifier of the pod in which the container resides.
  • UID: The Linux user identity under which the process executed.

Use the Process Name:<name> query in the filter bar to find specific processes.

4.5.1. Event timeline section

The Event Timeline section in the Process Discovery tab provides an overview of events for the selected deployment. It shows the number of policy violations, process activities, and container termination or restart events.

You can select Event Timeline to view more details.

The Event Timeline modal box shows events for all pods for the selected deployment.

The events on the timeline are categorized as:

  • Process activities
  • Policy violations
  • Container restarts
  • Container terminations

The events appear as icons on a timeline. To see more details about an event, hold your mouse pointer over the event icon. The details appear in a tooltip.

  • Click Show Legend to see which icon corresponds to which type of event.
  • Select ExportDownload PDF or ExportDownload CSV to download the event timeline information.
  • Select the Show All drop-down menu to filter which type of events are visible on the timeline.
  • Click on the expand icon to see events separately for each container in the selected pod.

All events in the timeline are also visible in the minimap control at the bottom. The minimap controls the number of events visible in the event timeline. You can change the events shown in the timeline by modifying the highlighted area on the minimap. To do this, decrease the highlighted area from left or right sides (or both), and then drag the highlighted area.

Note
  • When containers restart, Red Hat Advanced Cluster Security for Kubernetes:

    • Shows information about container termination and restart events for up to 10 inactive container instances for each container in a pod. For example, for a pod with two containers app and sidecar, Red Hat Advanced Cluster Security for Kubernetes keeps activity for up to 10 app instances and up to 10 sidecar instances.
    • Does not track process activities associated with the previous instances of the container.
  • Red Hat Advanced Cluster Security for Kubernetes only shows the most recent execution of each (process name, process arguments, UID) tuple for each pod.
  • Red Hat Advanced Cluster Security for Kubernetes shows events only for the active pods.
  • Red Hat Advanced Cluster Security for Kubernetes adjusts the reported timestamps based on time reported by Kubernetes and the Collector. Kubernetes timestamps use second-based precision, and it rounds off the time to the nearest second. However, the Collector uses more precise timestamps. For example, if Kubernetes reports the container start time as 10:54:48, and the Collector reports a process in that container started at 10:54:47.5349823, Red Hat Advanced Cluster Security for Kubernetes adjusts the container start time to 10:54:47.5349823.

4.6. Using process baselines

You can minimize risk by using process baselining for infrastructure security. With this approach, Red Hat Advanced Cluster Security for Kubernetes first discovers existing processes and creates a baseline. Then it operates in the default deny-all mode and only allows processes listed in the baseline to run.

Process baselines

When you install Red Hat Advanced Cluster Security for Kubernetes, there is no default process baseline. As Red Hat Advanced Cluster Security for Kubernetes discovers deployments, it creates a process baseline for every container type in a deployment. Then it adds all discovered processes to their own process baselines.

Process baseline states

During the process discovery phase, all baselines are in an unlocked state.

In an unlocked state:

  • When Red Hat Advanced Cluster Security for Kubernetes discovers a new process, it adds that process to the process baseline.
  • Processes do not show up as risks and do not trigger any violations.

After an hour from when Red Hat Advanced Cluster Security for Kubernetes receives the first process indicator from a container in a deployment, it finishes the process discovery phase. At this point:

  • Red Hat Advanced Cluster Security for Kubernetes stops adding processes to the process baselines.
  • New processes that are not in the process baseline show up as risks, but they do not trigger any violations.

To generate violations, you must manually lock the process baseline.

In a locked state:

  • Red Hat Advanced Cluster Security for Kubernetes stops adding processes to the process baselines.
  • New processes that are not in the process baseline trigger violations.

Independent of the locked or unlocked baseline state, you can always add or remove processes from the baseline.

Note

For a deployment, if each pod has multiple containers in it, Red Hat Advanced Cluster Security for Kubernetes creates a process baseline for each container type. For such a deployment, if some baselines are locked and some are unlocked, the baseline status for that deployment shows up as Mixed.

4.6.1. Viewing the process baselines

You can view process baselines from the Risk view.

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.

4.6.2. Adding a process to the baseline

You can add a process to the 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 Running Processes section, click the Add icon for the process you want to add to the process baseline.
Note

The Add icon is available only for the processes that are not in the process baseline.

4.6.3. Removing a process from the baseline

You can remove a process from the 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.

4.6.4. Locking and unlocking the process baselines

You can Lock the baseline to trigger violations for all processes not listed in the baseline and Unlock the baseline to stop triggering violations.

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.

Chapter 5. Using admission controller enforcement

Red Hat Advanced Cluster Security for Kubernetes works with Kubernetes admission controllers and OpenShift Container Platform admission plugins to allow you to enforce security policies before Kubernetes or OpenShift Container Platform creates workloads, for example, deployments, daemon sets or jobs.

The RHACS admission controller prevents users from creating workloads that violate policies you configure in RHACS. Beginning from the RHACS version 3.0.41, you can also configure the admission controller to prevent updates to workloads that violate policies.

RHACS uses the ValidatingAdmissionWebhook controller to verify that the resource being provisioned complies with the specified security policies. To handle this, RHACS creates a ValidatingWebhookConfiguration which contains multiple webhook rules.

When the Kubernetes or OpenShift Container Platform API server receives a request that matches one of the webhook rules, the API server sends an AdmissionReview request to RHACS. RHACS then accepts or rejects the request based on the configured security policies.

Note

To use admission controller enforcement on OpenShift Container Platform, you need the Red Hat Advanced Cluster Security for Kubernetes version 3.0.49 or newer.

5.1. Understanding admission controller enforcement

If you intend to use admission controller enforcement, consider the following:

  • API latency: Using admission controller enforcement increases Kubernetes or OpenShift Container Platform API latency because it involves additional API validation requests. Many standard Kubernetes libraries, such as fabric8, have short Kubernetes or OpenShift Container Platform API timeouts by default. Also, consider API timeouts in any custom automation you might be using.
  • Image scanning: You can choose whether the admission controller scans images while reviewing requests by setting the Contact Image Scanners option in the cluster configuration panel.

    • If you enable this setting, Red Hat Advanced Cluster Security for Kubernetes contacts the image scanners if the scan or image signature verification results are not already available, which adds considerable latency.
    • If you disable this setting, the enforcement decision only considers image scan criteria if cached scan and signature verification results are available.
  • You can use admission controller enforcement for:

    • Options in the pod securityContext.
    • Deployment configurations.
    • Image components and vulnerabilities.
  • You cannot use admission controller enforcement for:

    • Any runtime behavior, such as processes.
    • Any policies based on port exposure.
  • The admission controller might fail if there are connectivity issues between the Kubernetes or OpenShift Container Platform API server and RHACS Sensor. To resolve this issue, delete the ValidatingWebhookConfiguration object as described in the disabling admission controller enforcement section.
  • If you have deploy-time enforcement enabled for a policy and you enable the admission controller, RHACS attempts to block deployments that violate the policy. If a noncompliant deployment is not rejected by the admission controller, for example, in case of a timeout, RHACS still applies other deploy-time enforcement mechanisms, such as scaling to zero replicas.

5.2. Enabling admission controller enforcement

You can enable admission controller enforcement from the Clusters view when you install Sensor or edit an existing cluster configuration.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationClusters.
  2. Select an existing cluster from the list or secure a new cluster by selecting Secure a clusterLegacy installation method.
  3. If you are securing a new cluster, in the Static Configuration section of the cluster configuration panel, enter the details for your cluster.
  4. Red Hat recommends that you only turn on the Configure Admission Controller Webhook to listen on Object Creates toggle if you are planning to use the admission controller to enforce on object create events.
  5. Red Hat recommends that you only turn on the Configure Admission Controller Webhook to listen on Object Updates toggle if you are planning to use the admission controller to enforce on update events.
  6. Red Hat recommends that you only turn on the Enable Admission Controller Webhook to listen on exec and port-forward events toggle if you are planning to use the admission controller to enforce on pod execution and pod port forwards events.
  7. Configure the following options in the Dynamic Configuration section:

    • Enforce on Object Creates: This toggle controls the behavior of the admission control service. You must have the Configure Admission Controller Webhook to listen on Object Creates toggle turned on for this to work.
    • Enforce on Object Updates: This toggle controls the behavior of the admission control service. You must have the Configure Admission Controller Webhook to listen on Object Updates toggle turned on for this to work.
  8. Select Next.
  9. In the Download files section, select Download YAML files and keys.

    Note

    When enabling admission controller for an existing cluster, follow this guidance:

    • If you make any changes in the Static Configuration section, you must download the YAML files and redeploy the Sensor.
    • If you make any changes in the Dynamic Configuration section, you can skip downloading the files and deployment, as RHACS automatically synchronizes the Sensor and applies the changes.
  10. Select Finish.

Verification

  • After you provision a new cluster with the generated YAML, run the following command to verify if admission controller enforcement is configured correctly:

    $ oc get ValidatingWebhookConfiguration 1
    1
    If you use Kubernetes, enter kubectl instead of oc.

    Example output

    NAME       CREATED AT
    stackrox   2019-09-24T06:07:34Z

5.3. Bypassing admission controller enforcement

To bypass the admission controller, add the admission.stackrox.io/break-glass annotation to your configuration YAML. Bypassing the admission controller triggers a policy violation which includes deployment details. Red Hat recommends providing an issue-tracker link or some other reference as the value of this annotation so that others can understand why you bypassed the admission controller.

5.4. Disabling admission controller enforcement

You can disable admission controller enforcement from the Clusters view on the Red Hat Advanced Cluster Security for Kubernetes (RHACS) portal.

Procedure

  1. In the RHACS portal, select Platform ConfigurationClusters.
  2. Select an existing cluster from the list.
  3. Turn off the Enforce on Object Creates and Enforce on Object Updates toggles in the Dynamic Configuration section.
  4. Select Next.
  5. Select Finish.

5.4.1. Disabling associated policies

You can turn off the enforcement on relevant policies, which in turn instructs the admission controller to skip enforcements.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationPolicy Management.
  2. Disable enforcement on the default policies:

    • In the policies view, locate the Kubernetes Actions: Exec into Pod policy. Click the overflow menu, kebab , and then select Disable policy.
    • In the policies view, locate the Kubernetes Actions: Port Forward to Pod policy. Click the overflow menu, kebab , 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.

5.4.2. Disabling the webhook

You can disable admission controller enforcement from the Clusters view in the RHACS portal.

Important

If you disable the admission controller by turning off the webhook, you must redeploy the Sensor bundle.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationClusters.
  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.
Note

When you disable the admission controller, RHACS does not delete the ValidatingWebhookConfiguration parameter. However, instead of checking requests for violations, it accepts all AdmissionReview requests.

To remove the ValidatingWebhookConfiguration object, run the following command in the secured cluster:

  • On OpenShift Container Platform:

    $ oc delete ValidatingWebhookConfiguration/stackrox
  • On Kubernetes:

    $ kubectl delete ValidatingWebhookConfiguration/stackrox

5.5. ValidatingWebhookConfiguration YAML file changes

With Red Hat Advanced Cluster Security for Kubernetes you can enforce security policies on:

  • Object creation
  • Object update
  • Pod execution
  • Pod port forward
If Central or Sensor is unavailable

The admission controller requires an initial configuration from Sensor to work. Kubernetes or OpenShift Container Platform saves this configuration, and it remains accessible even if all admission control service replicas are rescheduled onto other nodes. If this initial configuration exists, the admission controller enforces all configured deploy-time policies.

If Sensor or Central becomes unavailable later:

  • you will not be able to run image scans, or query information about cached image scans. However, admission controller enforcement still functions based on the available information gathered before the timeout expires, even if the gathered information is incomplete.
  • you will not be able to disable the admission controller from the RHACS portal or modify enforcement for an existing policy as the changes will not get propagated to the admission control service.
Note

If you need to disable admission control enforcement, you can delete the validating webhook configuration by running the following command:

  • On OpenShift Container Platform:

    $ oc delete ValidatingWebhookConfiguration/stackrox
  • On Kubernetes:

    $ kubectl delete ValidatingWebhookConfiguration/stackrox
Make the admission controller more reliable

Red Hat recommends that you schedule the admission control service on the control plane and not on worker nodes. The deployment YAML file includes a soft preference for running on the control plane, however it is not enforced.

By default, the admission control service runs 3 replicas. To increase reliability, you can increase the replicas by running the following command:

$ oc -n stackrox scale deploy/admission-control --replicas=<number_of_replicas> 1
1
If you use Kubernetes, enter kubectl instead of oc.
Using with the roxctl CLI

You can use the following options when you generate a Sensor deployment YAML file:

  • --admission-controller-listen-on-updates: If you use this option, Red Hat Advanced Cluster Security for Kubernetes generates a Sensor bundle with a ValidatingWebhookConfiguration pre-configured to receive update events from the Kubernetes or OpenShift Container Platform API server.
  • --admission-controller-enforce-on-updates: If you use this option, Red Hat Advanced Cluster Security for Kubernetes configures Central such that the admission controller also enforces security policies object updates.

Both these options are optional, and are false by default.

Chapter 6. Managing security policies

Red Hat Advanced Cluster Security for Kubernetes allows you to use out-of-the-box security policies and define custom multi-factor policies for your container environment. Configuring these policies enables you to automatically prevent high-risk service deployments in your environment and respond to runtime security incidents.

6.1. Using default security policies

Red Hat Advanced Cluster Security for Kubernetes includes a set of default policies that provide broad coverage to identify security issues and ensure best practices for security in your environment.

To view the default policies:

  • In the RHACS portal, go to Platform ConfigurationPolicy Management.

The Policies view also enables you to configure the policies.

The policy information is organized into the following groups:

  • Policy: A name for the policy.
  • Description: A longer, more detailed description of the alert for the policy.
  • Status: The current status of the policy, either Enabled or Disabled.
  • Notifiers: The list of notifiers that are configured for the policy.
  • Severity: A ranking of the policy, either critical, high, medium, or low, for the amount of attention required.
  • Lifecycle: The phase of the container lifecycle (build, deploy, or runtime) that this policy applies to, and the phase at which enforcement applies, when the policy is enabled.

The Policy categories view lists the categories and enables you to manage the categories for your policies. By default, all the categories are listed. You optionally filter the categories by using the category name.

The following categories are listed:

  • Anomalous Activity
  • Cryptocurrency Mining
  • DevOps Best Practices
  • Docker CIS
  • Kubernetes
  • Kubernetes Events
  • Network Tools
  • Package Management
  • Privileges
  • Security Best Practices
  • Supply Chain Security
  • System Modification
  • Vulnerability Management
  • Zero Trust
Note

You cannot delete default policies or edit policy criteria for default policies.

6.2. Modifying existing security policies

You can edit the policies you have created and the existing default policies provided by Red Hat Advanced Cluster Security for Kubernetes.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationPolicy Management.
  2. From the Policies page, select the policy you want to edit.
  3. Select ActionsEdit policy.
  4. Modify the Policy details. You can modify the policy name, severity, categories, description, rationale, and guidance. You can also attach notifiers to the policy by selecting from the available Notifiers under the Attach notifiers section.
  5. Click Next.
  6. In the Policy behavior section, select the Lifecycle stages and Event sources for the policy.
  7. Select a Response method to address violations for the policy.
  8. Click Next.
  9. In the Policy criteria section, expand the categories under the Drag out policy fields section. Use the drag-and-drop policy fields to specify logical conditions for the policy criteria.

    Note

    You cannot edit policy criteria for default policies.

  10. Click Next.
  11. In the Policy scope section, modify Restrict by scope, Exclude by scope, and Exclude images settings.
  12. Click Next.
  13. In the Review policy section, preview the policy violations.
  14. Click Save.

6.3. Creating and managing policy categories

6.3.1. Creating policy categories by using the Policy categories tab

Beginning with version 3.74, RHACS provides a new method to create and manage policy categories in Red Hat Advanced Cluster Security Cloud Service or in RHACS if you have the PostgreSQL database enabled. All policy workflows other than policy creation remain unchanged when using this feature.

You can also configure policy categories by using the PolicyCategoryService API object. For more information, go to HelpAPI reference in the RHACS portal.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationPolicy 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.

6.3.2. Modifying policy categories by using the Policy categories tab

Beginning with version 3.74, RHACS provides a new method to create and manage policy categories in Red Hat Advanced Cluster Security Cloud Service or in RHACS if you have the PostgreSQL database enabled. All policy workflows other than policy creation remain unchanged when using this feature.

You can also configure policy categories by using the PolicyCategoryService API object. For more information, go to HelpAPI reference in the RHACS portal.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationPolicy 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.

6.4. Creating custom policies

In addition to using the default policies, you can also create custom policies in Red Hat Advanced Cluster Security for Kubernetes.

To build a new policy, you can clone an existing policy or create a new one from scratch.

  • You can also create policies based on the filter criteria in the Risk view in the RHACS portal.
  • You can also use AND, OR, and NOT logical operators for policy criteria to create advanced policies.

6.4.1. Creating a security policy from the system policies view

You can create new security policies from the system policies view.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationPolicy 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.
6.4.1.1. Security policy enforcement for the deploy stage

Red Hat Advanced Cluster Security for Kubernetes supports two forms of security policy enforcement for deploy-time policies: hard enforcement through the admission controller and soft enforcement by RHACS Sensor. The admission controller blocks creation or updating of deployments that violate policy. If the admission controller is disabled or unavailable, Sensor can perform enforcement by scaling down replicas for deployments that violate policy to 0.

Warning

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

6.4.1.1.1. Hard enforcement

Hard enforcement is performed by the RHACS admission controller. In clusters with admission controller enforcement, the Kubernetes or OpenShift Container Platform API server blocks all noncompliant deployments. The admission controller blocks CREATE and UPDATE operations. Any pod create or update request that satisfies a policy configured with deploy-time enforcement enabled will fail.

Note

Kubernetes admission webhooks support only CREATE, UPDATE, DELETE, or CONNECT operations. The RHACS admission controller supports only CREATE and UPDATE operations. Operations such as kubectl patch, kubectl set, and kubectl scale are PATCH operations, not UPDATE operations. Because PATCH operations are not supported in Kubernetes, RHACS cannot perform enforcement on PATCH operations.

For blocking enforcement, you must enable the following settings for the cluster in RHACS:

  • Enforce on Object Creates: This toggle in the Dynamic Configuration section controls the behavior of the admission control service. You must have the Configure Admission Controller Webhook to listen on Object Creates toggle in the Static Configuration section turned on for this to work.
  • Enforce on Object Updates: This toggle in the Dynamic Configuration section controls the behavior of the admission control service. You must have the Configure Admission Controller Webhook to listen on Object Updates toggle in the Static Configuration section turned on for this to work.

If you make changes to settings in the Static Configuration setting, you must redeploy the secured cluster for those changes to take effect.

6.4.1.1.2. Soft enforcement

Soft enforcement is performed by RHACS Sensor. This enforcement prevents an operation from being initiated. With soft enforcement, Sensor scales the replicas to 0, and prevents pods from being scheduled. In this enforcement, a non-ready deployment is available in the cluster.

If soft enforcement is configured, and Sensor is down, then RHACS cannot perform enforcement.

6.4.1.1.3. Namespace exclusions

By default, RHACS excludes certain administrative namespaces, such as the stackrox, kube-system, and istio-system namespaces, from enforcement blocking. The reason for this is that some items in these namespaces must be deployed for RHACS to work correctly.

6.4.1.1.4. Enforcement on existing deployments

For existing deployments, policy changes only result in enforcement at the next detection of the criteria, when a Kubernetes event occurs. If you make changes to a policy, you must reassess policies by selecting Policy Management and clicking Reassess All. This action applies deploy policies on all existing deployments regardless of whether there are any new incoming Kubernetes events. If a policy is violated, then RHACS performs enforcement.

6.4.2. Creating a security policy from the risk view

While evaluating risks in your deployments in the Risk view, when you apply local page filtering, you can create new security policies based on the filtering criteria you are using.

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.

6.4.3. Policy criteria

In the Policy Criteria section you can configure the data on which you want to trigger a policy.

You can configure the policy based on the attributes listed in the following table.

In this table:

  • The Regular expressions, AND, OR, and NOT columns indicate whether you can use regular expressions and other logical operators along with the specific attribute.

    • ! for Regex (Regular expressions) indicates that you can only use regular expressions for the listed fields.
    • ! for AND, or OR indicates that you can only use the mentioned logical operator for the attribute.
    • ✕ in the Regex / NOT / AND, OR column indicates that the attribute does not support any of those (regex, negation, logical operators).
  • The RHACS version column indicates the version of Red Hat Advanced Cluster Security for Kubernetes that you must have to use the attribute.
  • You cannot use logical combination operators AND and OR for attributes that have:

    • Boolean values true and false
    • Minimum-value semantics, for example:

      • Minimum RBAC permissions
      • Days since image was created
  • You cannot use the NOT logical operator for attributes that have:

    • Boolean values true and false
    • Numeric values that already use comparison, such as the <, >, <=, >= operators.
    • Compound criteria that can have multiple values, for example:

      • Dockerfile Line, which includes both instructions and arguments.
      • Environment Variable, which consists of both name and value.
    • Other meanings, including Add Capabilities, Drop Capabilities, Days since image was created, and Days since image was last scanned.
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

Section: Image registry

Image Registry

The name of the image registry.

Image Registry

String

Regex,
NOT,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Image Name

The full name of the image in registry, for example library/nginx.

Image Remote

String

Regex,
NOT,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Image Tag

Identifier for an image.

Image Tag

String

Regex,
NOT,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Image Signature

The list of signature integrations you can use to verify an image’s signature. Create alerts on images that either do not have a signature or their signature is not verifiable by at least one of the provided signature integrations.

Image Signature Verified By

A valid ID of an already configured image signature integration

! OR only

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Section: Image contents

The Common Vulnerabilities and Exposures (CVE) is fixable

This criterion results in a violation only if the image in the deployment you are evaluating has a fixable CVE.

Fixable

Boolean

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Days Since CVE Was First Discovered In Image

This criterion results in a violation only if it has been more than a specified number of days since RHACS discovered the CVE in a specific image.

Days Since CVE Was First Discovered In Image

Integer

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Days Since CVE Was First Discovered In System

This criterion results in a violation only if it has been more than a specified number of days since RHACS discovered the CVE across all deployed images in all clusters that RHACS monitors.

Days Since CVE Was First Discovered In System

Integer

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Image age

The minimum number of days from image creation date.

Image Age

Integer

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Image scan age

The minimum number of days since the image was last scanned.

Image Scan Age

Integer

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Image User

Matches the USER directive in the Dockerfile. See https://docs.docker.com/engine/reference/builder/#user for details .

Image User

String

Regex,
NOT,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Dockerfile Line

A specific line in the Dockerfile, including both instructions and arguments.

Dockerfile Line

One of: LABEL, RUN, CMD, EXPOSE, ENV, ADD, COPY, ENTRYPOINT, VOLUME, USER, WORKDIR, ONBUILD

! Regex only for values,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Image scan status

Check if an image was scanned.

Unscanned Image

Boolean

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Common Vulnerability Scoring System (CVSS)

CVSS: Use it to match images with vulnerabilities whose scores are greater than >, less than <, or equal to = the specified CVSS.

CVSS

<, >, <=, >= or nothing (which implies equal to)
 — and — 
a decimal (a number with an optional fractional value).

Examples:
>=5, or
9.5

AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Severity

The severity of the vulnerability based on the CVSS or the vendor. Can be one of Low, Moderate, Important or Critical.

Severity

<, >, ⇐, >= or nothing (which implies equal to)
 — and — 
One of:
UNKNOWN
LOW
MODERATE
IMPORTANT
CRITICAL

Examples:
>=IMPORTANT, or
CRITICAL

AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Fixed By

The version string of a package that fixes a flagged vulnerability in an image. This criterion may be used in addition to other criteria that identify a vulnerability, for example using the CVE criterion.

Fixed By

String

Regex,
NOT,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

CVE

Common Vulnerabilities and Exposures, use it with specific CVE numbers.

CVE

String

Regex,
NOT,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Image Component

Name and version number of a specific software component present in an image.

Image Component

key=value

Value is optional.

If value is missing, it must be in format "key=".

Regex,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Image OS

Name and version number of the base operating system of the image. For example, alpine:3.17.3

Image OS

String

Regex,
NOT,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Require image label

Ensure the presence of a Docker image label. The policy triggers if any image in the deployment does not have the specified label. You can use regular expressions for both key and value fields to match labels. The Require Image Label policy criteria only works when you integrate with a Docker registry. For details about Docker labels see Docker documentation, https://docs.docker.com/config/labels-custom-metadata/.

Required Image Label

key=value

Value is optional.

If value is missing, it must be in format "key=".

Regex,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Disallow image label

Ensure that a particular Docker image label is NOT used. The policy triggers if any image in the deployment has the specified label. You can use regular expressions for both key and value fields to match labels. The 'Disallow Image Label policy' criteria only works when you integrate with a Docker registry. For details about Docker labels see Docker documentation, https://docs.docker.com/config/labels-custom-metadata/.

Disallowed Image Label

key=value

Value is optional.

If value is missing, it must be in format "key=".

Regex,
AND, OR

Build,
Deploy,
Runtime (when used with a Runtime criterion)

Section: Container configuration

Environment Variable

Check environment variables by name or value. When you create a policy that includes the environment variable attribute, you can choose which types of environment variables the policy should match. For example, you can specify raw values, which are provided directly in the deployment YAML, or you can specify references to values from config maps, secrets, fields, or resource requests or limits. For any type other than a raw value specified directly in the deployment YAML, the corresponding value attribute of the policy rule is ignored. In this case, the policy match is evaluated on the existence of the specified environment variable type. Additionally, this criteria disallows the creation of policies with a non-empty value attribute for types other than raw values.

Environment Variable

RAW=key=value to match an environment variable as directly specified in the deployment YAML with a specific key and value. You can omit the value attribute to match on only the key.

If the environment variable is not defined in the configuration YAML, then you can use the format SOURCE=KEY, where SOURCE is one of the following objects:

  • SECRET_KEY (SecretKeyRef)
  • CONFIG_MAP_KEY (ConfigMapRef)
  • FIELD (FieldRef)
  • RESOURCE_FIELD (ResourceFieldRef)

The preceding list provides the API object label first, and then provides the user interface label in parentheses.

! Regex only for key and value (if using RAW)
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Container CPU Request

Check for the number of cores reserved for a given resource.

Container CPU Request

<, >, ⇐, >= or nothing (which implies equal to)
 — and — 
A decimal (a number with an optional fractional value)

Examples:
>=5, or
9.5

AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Container CPU Limit

Check for the maximum number of cores a resource is allowed to use.

Container CPU Limit

(Same as Container CPU Request)

AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Container Memory Request

Number, including fraction, of MB requested.

Container Memory Request

(Same as Container CPU Request)

AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Container Memory Limit

Check for the maximum amount of memory a resource is allowed to use.

Container Memory Limit

(Same as Container CPU Request)

AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Privileged container

Check if a deployment is configured in privileged mode. This criterion only checks the value of the privileged field in the respective Pod Security Context.

Privileged Container

Boolean: true when the value of the privileged field in the respective PodSecurityContext is set to true

Deploy,
Runtime (when used with a Runtime criterion)

Root filesystem writeability

Check if a deployment is configured in the readOnlyFilesystem mode.

Read-Only Root Filesystem

Boolean: true when the value of the readOnlyRootFilesystem field in the respective PodSecurityContext is set to true

Deploy,
Runtime (when used with a Runtime criterion)

Seccomp Profile Type

The type of seccomp profile defined for the deployment. If seccomp options are provided at both the pod and container level, the container options override the pod options. See Security Context.

Seccomp Profile Type

One of:

UNCONFINED
RUNTIME_DEFAULT
LOCALHOST

Deploy,
Runtime (when used with a Runtime criterion)

Privilege escalation

Provides alerts when a deployment allows a container process to gain more privileges than its parent process.

Allow Privilege Escalation

Boolean

Deploy,
Runtime (when used with a Runtime criterion)

Drop Capabilities

Linux capabilities that must be dropped from the container. Provides alerts when the specified capabilities are not dropped. For example, if configured with SYS_ADMIN AND SYS_BOOT, and the deployment drops only one or neither of these two capabilities, the alert occurs.

Drop Capabilities

One of:

ALL
AUDIT_CONTROL
AUDIT_READ
AUDIT_WRITE
BLOCK_SUSPEND
CHOWN
DAC_OVERRIDE
DAC_READ_SEARCH
FOWNER
FSETID
IPC_LOCK
IPC_OWNER
KILL
LEASE
LINUX_IMMUTABLE
MAC_ADMIN
MAC_OVERRIDE
MKNOD
NET_ADMIN
NET_BIND_SERVICE
NET_BROADCAST
NET_RAW
SETGID
SETFCAP
SETPCAP
SETUID
SYS_ADMIN
SYS_BOOT
SYS_CHROOT
SYS_MODULE
SYS_NICE
SYS_PACCT
SYS_PTRACE
SYS_RAWIO
SYS_RESOURCE
SYS_TIME
SYS_TTY_CONFIG
SYSLOG
WAKE_ALARM

AND

Deploy,
Runtime (when used with a Runtime criterion)

Add Capabilities

Linux capabilities that must not be added to the container, such as the ability to send raw packets or override file permissions. Provides alerts when the specified capabilities are added. For example, if configured with NET_ADMIN or NET_RAW, and the deployment manifest YAML file includes at least one of these two capabilities, the alert occurs.

Add Capabilities

AUDIT_CONTROL
AUDIT_READ
AUDIT_WRITE
BLOCK_SUSPEND
CHOWN
DAC_OVERRIDE
DAC_READ_SEARCH
FOWNER
FSETID
IPC_LOCK
IPC_OWNER
KILL
LEASE
LINUX_IMMUTABLE
MAC_ADMIN
MAC_OVERRIDE
MKNOD
NET_ADMIN
NET_BIND_SERVICE
NET_BROADCAST
NET_RAW
SETGID
SETFCAP
SETPCAP
SETUID
SYS_ADMIN
SYS_BOOT
SYS_CHROOT
SYS_MODULE
SYS_PACCT
SYS_PTRACE
SYS_RAWIO
SYS_RESOURCE
SYS_TIME
SYS_TTY_CONFIG
SYSLOG
WAKE_ALARM

OR

Deploy,
Runtime (when used with a Runtime criterion)

Container Name

The name of the container.

Container Name

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

AppArmor Profile

The Application Armor ("AppArmor") profile used in the container.

AppArmor Profile

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Liveness Probe

Whether the container defines a liveness probe.

Liveness Probe

Boolean

Deploy,
Runtime (when used with a Runtime criterion)

Readiness Probe

Whether the container defines a readiness probe.

Readiness Probe

Boolean

Deploy,
Runtime (when used with a Runtime criterion)

Section: Deployment metadata

Disallowed Annotation

An annotation which is not allowed to be present on Kubernetes resources in a specified environment.

Disallowed Annotation

key=value

Value is optional.

If value is missing, it must be in format "key=".

Regex,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Required Label

Check for the presence of a required label in Kubernetes.

Required Label

key=value

Value is optional.

If value is missing, it must be in format "key=".

Regex,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Required Annotation

Check for the presence of a required annotation in Kubernetes.

Required Annotation

key=value

Value is optional.

If value is missing, it must be in format "key=".

Regex,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Runtime Class

The RuntimeClass of the deployment.

Runtime Class

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Host Network

Check if HostNetwork is enabled which means that the container is not placed inside a separate network stack (for example, the container’s networking is not containerized). This implies that the container has full access to the host’s network interfaces.

Host Network

Boolean

Deploy,
Runtime (when used with a Runtime criterion)

Host PID

Check if the Process ID (PID) namespace is isolated between the containers and the host. This allows for processes in different PID namespaces to have the same PID.

Host PID

Boolean

Deploy,
Runtime (when used with a Runtime criterion)

Host IPC

Check if the IPC (POSIX/SysV IPC) namespace (which provides separation of named shared memory segments, semaphores and message queues) on the host is shared with containers.

Host IPC

Boolean

Deploy,
Runtime (when used with a Runtime criterion)

Namespace

The name of the namespace the deployment belongs to.

Namespace

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Replicas

The number of deployment replicas. If you use oc scale to scale the deployment replicas from 0 to a number, then the admission controller blocks this action if the deployment violates a policy.

Replicas

<, >, ⇐, >= or nothing (which implies equal to)
 — and — 
a decimal (a number with an optional fractional value).

Examples:
>=5, or
9.5

NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Section: Storage

Volume Name

Name of the storage.

Volume Name

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Volume Source

Indicates the form in which the volume is provisioned. For example, persistentVolumeClaim or hostPath.

Volume Source

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Volume Destination

The path where the volume is mounted.

Volume Destination

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Volume Type

The type of volume.

Volume Type

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Mounted volume writability

Volumes that are mounted as writable.

Writable Mounted Volume

Boolean

Deploy,
Runtime (when used with a Runtime criterion)

Mount Propagation

Check if container is mounting volumes in Bidirectional, Host to Container, or None modes.

Mount Propagation

One of:

NONE
HOSTTOCONTAINER
BIDIRECTIONAL

NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Host mount writability

Resource has mounted a path on the host with write permissions.

Writable Host Mount

Boolean

Deploy,
Runtime (when used with a Runtime criterion)

Section: Networking

Protocol

Protocol, such as, TCP or UDP, that is used by the exposed port.

Exposed Port Protocol

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Port

Port numbers exposed by a deployment.

Exposed Port

<, >, ⇐, >= or nothing (which implies equal to)
 — and — 
an integer.

Examples:
>=1024, or
22

NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Exposed Node Port

Port numbers exposed externally by a deployment.

Exposed Node Port

(Same as Exposed Port)

NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Port Exposure

Exposure method of the service, for example, load balancer or node port.

Port Exposure Method

One of:

UNSET
EXTERNAL
NODE
HOST
INTERNAL
ROUTE

NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Unexpected Network Flow Detected

Check if the detected network traffic is part of the network baseline for the deployment.

Unexpected Network Flow Detected

Boolean

Runtime ONLY - Network

Ingress Network Policy

Check the presence or absence of ingress Kubernetes network policies.

Has Ingress Network Policy

Boolean

Regex,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Egress Network Policy

Check the presence or absence of egress Kubernetes network policies.

Has Egress Network Policy

Boolean

Regex,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Section: Process activity

Process Name

Name of the process executed in a deployment.

Process Name

String

Regex,
NOT,
AND, OR

Runtime ONLY - Process

Process Ancestor

Name of any parent process for a process executed in a deployment.

Process Ancestor

String

Regex,
NOT,
AND, OR

Runtime ONLY - Process

Process Arguments

Command arguments for a process executed in a deployment.

Process Arguments

String

Regex,
NOT,
AND, OR

Runtime ONLY - Process

Process UID

Unix user ID for a process executed in a deployment.

Process UID

Integer

NOT,
AND, OR

Runtime ONLY - Process

Unexpected Process Executed

Check deployments for which process executions are not listed in the deployment’s locked process baseline.

Unexpected Process Executed

Boolean

Runtime ONLY - Process

Section: Kubernetes access

Service Account

The name of the service account.

Service Account

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Automount Service Account Token

Check if the deployment configuration automatically mounts the service account token.

Automount Service Account Token

Boolean

Deploy,
Runtime (when used with a Runtime criterion)

Minimum RBAC Permissions

Match if the deployment’s Kubernetes service account has Kubernetes RBAC permission level equal to = or greater than > the specified level.

Minimum RBAC Permissions

One of:

DEFAULT
ELEVATED_IN_NAMESPACE
ELEVATED_CLUSTER_WIDE
CLUSTER_ADMIN

NOT

Deploy,
Runtime (when used with a Runtime criterion)

Section: Kubernetes events

Kubernetes Action

The name of the Kubernetes action, such as Pod Exec.

Kubernetes Resource

One of:

PODS_EXEC
PODS_PORTFORWARD

! OR only

Runtime ONLY - Kubernetes Events

Kubernetes User Name

The name of the user who accessed the resource.

Kubernetes User Name

Alphanumeric with hyphens (-) and colon (:) only

Regex,
NOT,
! OR only

Runtime ONLY - Kubernetes Events

Kubernetes User Group

The name of the group to which the user who accessed the resource belongs to.

Kubernetes User Groups

Alphanumeric with hyphens (-) and colon (:) only

Regex,
NOT,
! OR only

Runtime ONLY - Kubernetes Events

Kubernetes Resource Type

Type of the accessed Kubernetes resource.

Kubernetes Resource

One of:

Config maps
Secrets
ClusterRoles
ClusterRoleBindings
NetworkPolicies
SecurityContextConstraints
EgressFirewalls

! OR only

Runtime ONLY - Audit Log

Kubernetes API Verb

The Kubernetes API verb that is used to access the resource, such as GET or POST.

Kubernetes API Verb

One of:

CREATE
DELETE
GET
PATCH
UPDATE

! OR only

Runtime ONLY - Audit Log

Kubernetes Resource Name

The name of the accessed Kubernetes resource.

Kubernetes Resource Name

Alphanumeric with hyphens (-) and colon (:) only

Regex,
NOT,
! OR only

Runtime ONLY - Audit Log

User Agent

The user agent that the user used to access the resource. For example oc, or kubectl.

User Agent

String

Regex,
NOT,
! OR only

Runtime ONLY - Audit Log

Source IP Address

The IP address from which the user accessed the resource.

Source IP Address

IPV4 or IPV6 address

Regex,
NOT,
! OR only

Runtime ONLY - Audit Log

Is Impersonated User

Check if the request was made by a user that is impersonated by a service account or some other account.

Is Impersonated User

Boolean

Runtime ONLY - Audit Log

6.4.3.1. Adding logical conditions for the policy criteria

You can use the drag-and-drop policy fields panel to specify logical conditions for the policy criteria.

Prerequisites

  • You must be using Red Hat Advanced Cluster Security for Kubernetes version 3.0.45 or newer.

Procedure

  1. In the Policy Criteria section, select Add a new condition to add a new policy section.

    • You can click on the Edit icon to rename the policy section.
    • The Drag out a policy field section lists available policy criteria in multiple categories. You can expand and collapse these categories to view the policy criteria attributes.
  2. Drag an attribute to the Drop a policy field inside area of the policy section.
  3. Depending on the type of the attribute you select, you get different options to configure the conditions for the selected attribute. For example:

    • If you select an attribute with Boolean values Read-Only Root Filesystem, you will see READ-ONLY and WRITABLE options.
    • If you select an attribute with compound values Environment variable, you will see options to enter values for Key, Value, and Value From fields, and an icon to add more values for the available options.

      1. To combine multiple values for an attribute, click the Add icon.
      2. You can also click on the logical operator AND or OR listed in a policy section, to toggle between AND and OR operators. Toggling between operators only works inside a policy section and not between two different policy sections.
  4. You can specify more than one AND and OR condition by repeating these steps. After you configure the conditions for the added attributes, click Next to continue with the policy creation.

6.5. Sharing security policies

Beginning from Red Hat Advanced Cluster Security for Kubernetes version 3.0.44, you can share your security policies between different Central instances, by exporting and importing policies. It helps you enforce the same standards for all your clusters. To share policies, you export them as JSON files, and then import them back into another Central instance.

Note

Currently, you cannot export multiple security policies at once by using the RHACS portal. However, you can use the API for exporting multiple security policies. In the RHACS portal, go to HelpAPI reference to see the API reference.

6.5.1. Exporting a security policy

When you export a policy, it includes all the policy contents and also includes cluster scopes, cluster exclusions, and all configured notifications.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationPolicy Management.
  2. From the Policies page, select the policy you want to edit.
  3. Select ActionsExport policy to JSON.

6.5.2. Importing a security policy

You can import a security policy from the System Policies view on the RHACS portal.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationPolicy 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.

Each security policy in RHACS has a unique ID (UID) and a unique name. When you import a policy, RHACS handles the uploaded policy as follows:

  • If the imported policy UID and name do not match any existing policy, RHACS creates a new policy.
  • If the imported policy has the same UID as an existing policy, but a different name, you can either:

    • Keep both policies. RHACS saves the imported policy with a new UID.
    • Replace the existing policy with the imported policy.
  • If the imported policy has the same name as an existing policy, but a different UID, you can either:

    • Keep both policies by providing a new name for the imported policy.
    • Replace the existing policy with the imported policy.
  • If the imported policy has the same name and UID as an existing policy, the Red Hat Advanced Cluster Security for Kubernetes checks if the policy criteria match to the existing policy. If the policy criteria match, RHACS keeps the existing policy and shows a success message. If the policy criteria do not match, you can either:

    • Keep both policies by providing a new name for the imported policy.
    • Replace the existing policy with the imported policy.
Important
  • If you import into the same Central instance, RHACS uses all the exported fields.
  • If you import into a different Central instance, RHACS omits certain fields, such as cluster scopes, cluster exclusions, and notifications. RHACS shows these omitted fields in a message. These fields vary for every installation, and you cannot migrate them from one Central instance to another.

Chapter 7. Default security policies

The default security policies in Red Hat Advanced Cluster Security for Kubernetes provide broad coverage to identify security issues and ensure best practices for security in your environment. By configuring those policies, you can automatically prevent high-risk service deployments in your environment and respond to runtime security incidents.

Note

The severity levels for policies in Red Hat Advanced Cluster Security for Kubernetes are different from the severity levels that Red Hat Product Security assigns.

The Red Hat Advanced Cluster Security for Kubernetes policy severity levels are Critical, High, Medium, and Low. Red Hat Product Security rates vulnerability severity levels as Critical, Important, Moderate, and Low.

While a policy’s severity level and the Red Hat Product Security severity levels can interact, it is important to distinguish between them. For more information about the Red Hat Product Security severity levels, see Severity Ratings.

7.1. Critical severity security policies

The following table lists the default security policies in Red Hat Advanced Cluster Security for Kubernetes that are of critical severity. The policies are organized by life cycle stage.

Table 7.1. Critical severity security policies
Life cycle stageNameDescriptionStatus

Build or Deploy

Apache Struts: CVE-2017-5638

Alerts when deployments have images that contain the CVE-2017-5638 Apache Struts vulnerability.

Enabled

Build or Deploy

Log4Shell: log4j Remote Code Execution vulnerability

Alerts when deployments include images that contain the CVE-2021-44228 and CVE-2021-45046 Log4Shell vulnerabilities. Flaws exist in the Apache Log4j Java logging library in versions 2.0-beta9 - 2.15.0, excluding version 2.12.2.

Enabled

Build or Deploy

Spring4Shell (Spring Framework Remote Code Execution) and Spring Cloud Function vulnerabilities

Alerts when deployments include images that contain either the CVE-2022-22965 vulnerability, which affects Spring MVC, and the CVE-2022-22963 vulnerability, which affects Spring Cloud. In versions 3.16, 3.2.2, and older unsupported versions, Spring Cloud contains flaws. Flaws exist in Spring Framework in versions 5.3.0 - 5.3.17, versions 5.2.0 - 5.2.19, and in older unsupported versions.

Enabled

Runtime

Iptables Executed in Privileged Container

Alerts when privileged pods run iptables.

Enabled

7.2. High severity security policies

The following table lists the default security policies in Red Hat Advanced Cluster Security for Kubernetes that are of high severity. The policies are organized by life cycle stage.

Table 7.2. High severity security policies
Life cycle stageNameDescriptionStatus

Build or Deploy

Fixable Common Vulnerability Scoring System (CVSS) >= 7

Alerts when deployments with fixable vulnerabilities have a CVSS of at least 7. However, Red Hat recommends that you create policies using Common Vulnerabilities and Exposures (CVE) severity instead of CVSS score.

Disabled

Build or Deploy

Fixable Severity at least Important

Alerts when deployments with fixable vulnerabilities have a severity rating of at least Important.

Enabled

Build or Deploy

Rapid Reset: Denial of Service Vulnerability in HTTP/2 Protocol

Alerts on deployments with images containing components that are susceptible to a Denial of Service (DoS) vulnerability for HTTP/2 servers. This addresses a flaw in the handling of multiplexed streams in HTTP/2. A client can rapidly create a request and immediately reset them, which creates extra work for the server while avoiding hitting any server-side limits, resulting in a denial of service attack. To use this policy, consider cloning the policy and adding the Fixable policy criteria before enabling it.

Disabled

Build or Deploy

Secure Shell (ssh) Port Exposed in Image

Alerts when deployments expose port 22, which is commonly reserved for SSH access.

Enabled

Deploy

Emergency Deployment Annotation

Alerts when deployments use the emergency annotation, such as "admission.stackrox.io/break-glass":"ticket-1234" to circumvent StackRox Admission controller checks.

Enabled

Deploy

Environment Variable Contains Secret

Alerts when deployments have environment variables that contain 'SECRET'.

Enabled

Deploy

Fixable CVSS >= 6 and Privileged

Alerts when deployments run in privileged mode with fixable vulnerabilities that have a CVSS of at least 6. However, Red Hat recommends that you create policies using CVE severity instead of CVSS score.

Disabled by default in version 3.72.0 and later

Deploy

Privileged Containers with Important and Critical Fixable CVEs

Alerts when containers that run in privileged mode have important or critical fixable vulnerabilities.

Enabled

Deploy

Secret Mounted as Environment Variable

Alerts when a deployment has a Kubernetes secret that is mounted as an environment variable.

Disabled

Deploy

Secure Shell (ssh) Port Exposed

Alerts when deployments expose port 22, which is commonly reserved for SSH access.

Enabled

Runtime

Cryptocurrency Mining Process Execution

Spawns the crypto-currency mining process.

Enabled

Runtime

iptables Execution

Detects when someone runs iptables, which is a deprecated way of managing network states in containers.

Enabled

Runtime

Kubernetes Actions: Exec into Pod

Alerts when the Kubernetes API receives a request to run a command in a container.

Enabled

Runtime

Linux Group Add Execution

Detects when someone runs the addgroup or groupadd binary to add a Linux group.

Enabled

Runtime

Linux User Add Execution

Detects when someone runs the useradd or adduser binary to add a Linux user.

Enabled

Runtime

Login Binaries

Indicates when someone tries to log in.

Disabled

Runtime

Network Management Execution

Detects when someone runs binary files that can manipulate network configuration and management.

Enabled

Runtime

nmap Execution

Alerts when someone starts the nmap process in a container during run time.

Enabled

Runtime

OpenShift: Kubeadmin Secret Accessed

Alerts when someone accesses the kubeadmin secret.

Enabled

Runtime

Password Binaries

Indicates when someone attempts to change a password.

Disabled

Runtime

Process Targeting Cluster Kubelet Endpoint

Detects the misuse of the healthz, kubelet API, or heapster endpoint.

Enabled

Runtime

Process Targeting Cluster Kubernetes Docker Stats Endpoint

Detects the misuse of the Kubernetes docker stats endpoint.

Enabled

Runtime

Process Targeting Kubernetes Service Endpoint

Detects the misuse of the Kubernetes Service API endpoint.

Enabled

Runtime

Process with UID 0

Alerts when deployments contain processes that run with UID 0.

Disabled

Runtime

Secure Shell Server (sshd) Execution

Detects containers that run the SSH daemon.

Enabled

Runtime

SetUID Processes

Use setuid binary files, which permit people to run certain programs with escalated privileges.

Disabled

Runtime

Shadow File Modification

Indicates when someone tries to modify shadow files.

Disabled

Runtime

Shell Spawned by Java Application

Detects when a shell, such as bash, csh, sh, or zsh, is run as a subprocess of a Java application.

Enabled

Runtime

Unauthorized Network Flow

Generates a violation for any network flows that fall outside of the baselines of the "alert on anomalous violations" setting.

Enabled

Runtime

Unauthorized Processed Execution

Generates a violation for any process execution that is not explicitly allowed by a locked process baseline for a container specification in a Kubernetes deployment.

Enabled

7.3. Medium severity security policies

The following table lists the default security policies in Red Hat Advanced Cluster Security for Kubernetes that are of medium severity. The policies are organized by life cycle stage.

Table 7.3. Medium severity security policies
Life cycle stageNameDescriptionStatus

Build

Docker CIS 4.4: Ensure images are scanned and rebuilt to include security patches

Alerts when images are not scanned and rebuilt to include security patches. It is important to scan images often to find vulnerabilities, rebuild the images to include security patches, and then instantiate containers for the images.

Disabled

Deploy

30-Day Scan Age

Alerts when a deployment has not been scanned in 30 days.

Enabled

Deploy

CAP_SYS_ADMIN capability added

Alerts when a deployment includes containers that are escalating with CAP_SYS_ADMIN.

Enabled

Deploy

Container using read-write root filesystem

Alerts when a deployment includes containers that have read-write root file systems.

Disabled

Deploy

Container with privilege escalation allowed

Alerts when a container might be running with unintended privileges, creating a security risk. This situation can happen when a container process that has more privileges than its parent process allows the container to run with unintended privileges.

Enabled

Deploy

Deployments should have at least one Ingress Network Policy

Alerts if deployments are missing an Ingress Network Policy.

Disabled

Deploy

Deployments with externally exposed endpoints

Detects if a deployment has any service that is externally exposed through any methods. Deployments with services exposed outside of the cluster are at a higher risk of attempted intrusions because they are reachable outside of the cluster. This policy provides an alert so that you can verify that service exposure outside of the cluster is required. If the service is only needed for intra-cluster communication, use service type ClusterIP.

Disabled

Deploy

Docker CIS 5.1: Ensure that, if applicable, an AppArmor profile is enabled

Uses AppArmor to protect the Linux operating system and applications by enforcing a security policy that is known as an AppArmor profile. AppArmor is a Linux application security system that is available on some Linux distributions by default, such as Debian and Ubuntu.

Enabled

Deploy

Docker CIS 5.15: Ensure that the host’s process namespace is not shared

Creates process-level isolation between the containers and the host. The Process ID (PID) namespace isolates the process ID space, which means that processes in different PID namespaces can have the same PID.

Enabled

Deploy

Docker CIS 5.16: Ensure that the host’s IPC namespace is not shared

Alerts when the IPC namespace on the host is shared with containers. The IPC (POSIX/SysV IPC) namespace separates named shared memory segments, semaphores, and message queues.

Enabled

Deploy

Docker CIS 5.19: Ensure mount propagation mode is not enabled

Alerts when mount propagation mode is enabled. When mount propagation mode is enabled, you can mount container volumes in Bidirectional, Host to Container, and None modes. Do not use Bidirectional mount propagation mode unless it is explicitly needed.

Enabled

Deploy

Docker CIS 5.21: Ensure the default seccomp profile is not disabled

Alerts when the seccomp profile is disabled. The seccomp profile uses an allowlist to permit common system calls and blocks all others.

Disabled

Deploy

Docker CIS 5.7: Ensure privileged ports are not mapped within containers

Alerts when privileged ports are mapped within containers. The TCP/IP port numbers that are lower than 1024 are privileged ports. Normal users and processes can not use them for security reasons, but containers might map their ports to privileged ports.

Enabled

Deploy

Docker CIS 5.9 and 5.20: Ensure that the host’s network namespace is not shared

Alerts when the host’s network namespace is shared. When HostNetwork is enabled, the container is not placed inside a separate network stack, and the container’s networking is not containerized. As a result, the container has full access to the host’s network interfaces, and a shared UTS namespace is enabled. The UTS namespace provides isolation between the hostname and the NIS domain name, and it sets the hostname and the domain, which are visible to running processes in that namespace. Processes that run within containers do not typically require to know the hostname or the domain name, so the UTS namespace should not be shared with the host.

Enabled

Deploy

Images with no scans

Alerts when a deployment includes images that were not scanned.

Disabled

Runtime

Kubernetes Actions: Port Forward to Pod

Alerts when the Kubernetes API receives a port forward request.

Enabled

Deploy

Mount Container Runtime Socket

Alerts when a deployment has a volume mount on the container runtime socket.

Enabled

Deploy

Mounting Sensitive Host Directories

Alerts when a deployment mounts sensitive host directories.

Enabled

Deploy

No resource requests or limits specified

Alerts when a deployment includes containers that do not have resource requests and limits.

Enabled

Deploy

Pod Service Account Token Automatically Mounted

Protects pod default service account tokens from being compromised by minimizing the mounting of the default service account token to only those pods whose applications require interaction with the Kubernetes API.

Enabled

Deploy

Privileged Container

Alerts when a deployment includes containers that run in privileged mode.

Enabled

Runtime

crontab Execution

Detects the usage of the crontab scheduled jobs editor.

Enabled

Runtime

Netcat Execution Detected

Detects when netcat runs in a container.

Enabled

Runtime

OpenShift: Advanced Cluster Security Central Admin Secret Accessed

Alerts when someone accesses the Red Hat Advanced Cluster Security Central secret.

Enabled

Runtime

OpenShift: Kubernetes Secret Accessed by an Impersonated User

Alerts when someone impersonates a user to access a secret in the cluster.

Enabled

Runtime

Remote File Copy Binary Execution

Alerts when a deployment runs a remote file copy tool.

Enabled

7.4. Low severity security policies

The following table lists the default security policies in Red Hat Advanced Cluster Security for Kubernetes that are of low severity. The policies are organized by life cycle stage.

Table 7.4. Low severity security policies
Life cycle stageNameDescriptionStatus

Build or Deploy

90-Day Image Age

Alerts when a deployment has not been updated in 90 days.

Enabled

Build or Deploy

ADD Command used instead of COPY

Alerts when a deployment uses an ADD command.

Disabled

Build or Deploy

Alpine Linux Package Manager (apk) in Image

Alerts when a deployment includes the Alpine Linux package manager (apk).

Enabled

Build or Deploy

Curl in Image

Alerts when a deployment includes curl.

Disabled

Build or Deploy

Docker CIS 4.1: Ensure That a User for the Container Has Been Created

Ensures that containers are running as non-root users.

Enabled

Build or Deploy

Docker CIS 4.7: Alert on Update Instruction

Ensures that update instructions are not used alone in the Dockerfile.

Enabled

Build or Deploy

Insecure specified in CMD

Alerts when a deployment uses 'insecure' in the command.

Enabled

Build or Deploy

Latest tag

Alerts when a deployment includes images that use the 'latest' tag.

Enabled

Build or Deploy

Red Hat Package Manager in Image

Alerts when a deployment includes components of the Red Hat, Fedora, or CentOS package management system.

Enabled

Build or Deploy

Required Image Label

Alerts when a deployment includes images that are missing the specified label.

Disabled

Build or Deploy

Ubuntu Package Manager Execution

Detects the usage of the Ubuntu package management system.

Enabled

Build or Deploy

Ubuntu Package Manager in Image

Alerts when a deployment includes components of the Debian or Ubuntu package management system in the image.

Enabled

Build or Deploy

Wget in Image

Alerts when a deployment includes wget.

Disabled

Deploy

Drop All Capabilities

Alerts when a deployment does not drop all capabilities.

Disabled

Deploy

Improper Usage of Orchestrator Secrets Volume

Alerts when a deployment uses a Dockerfile with 'VOLUME /run/secrets'.

Enabled

Deploy

Kubernetes Dashboard Deployed

Alerts when a Kubernetes dashboard service is detected.

Enabled

Deploy

Required Annotation: Email

Alerts when a deployment is missing the 'email' annotation.

Disabled

Deploy

Required Annotation: Owner/Team

Alerts when a deployment is missing the 'owner' or 'team' annotation.

Disabled

Deploy

Required Label: Owner/Team

Alerts when a deployment is missing the 'owner' or 'team' label.

Disabled

Runtime

Alpine Linux Package Manager Execution

Alerts when the Alpine Linux package manager (apk) is run at run time.

Enabled

Runtime

chkconfig Execution

Detects the usage of the ckconfig service manager, which is typically not used in a container.

Enabled

Runtime

Compiler Tool Execution

Alerts when binary files that compile software are run at run time.

Enabled

Runtime

Red Hat Package Manager Execution

Alerts when Red Hat, Fedora, or CentOS package manager programs are run at run time.

Enabled

Runtime

Shell Management

Alerts when commands are run to add or remove a shell.

Disabled

Runtime

systemctl Execution

Detects the usage of the systemctl service manager.

Enabled

Runtime

systemd Execution

Detects the usage of the systemd service manager.

Enabled

Chapter 8. Managing network policies

A Kubernetes network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints. These network policies are configured as YAML files. By looking at these files alone, it is often hard to identify whether the applied network policies achieve the desired network topology.

Red Hat Advanced Cluster Security for Kubernetes (RHACS) gathers all defined network policies from your orchestrator and provides tools to make these policies easier to use.

To support network policy enforcement, RHACS provides the following tools:

  • Network graph
  • Network policy generator
  • Network policy simulator
  • Build-time network policy generator

8.1. Network graph

8.1.1. About the network graph

The network graph provides high-level and detailed information about deployments, network flows, and network policies in your environment.

RHACS processes all network policies in each secured cluster to show you which deployments can contact each other and which can reach external networks. It also monitors running deployments and tracks traffic between them. You can view the following items in the network graph:

Internal entities
These represent a connection between a deployment and an IP address that belongs to the private address space as defined in RFC 1918. For more information, see "Connections involving internal entities".
External entities
These represent a connection between a deployment and an IP address that does not belong to the private address space as defined in RFC 1918. For more information, see "External entities and connections in the network graph".
Network components
From the top menu, you can select namespaces (indicated by the NS label) and deployments (indicated by the D label) to display on the graph for a chosen cluster (indicated by the CL label). You can further filter deployments by using the drop-down list and selecting criteria on which to filter, such as common vulnerabilities and exposures (CVEs), labels, and images.
Network flows
You can select one of the following flows for the graph:
Active traffic
Selecting this default option shows observed traffic, focused on the namespace or specific deployment that you selected. You can select the time period for which to display information.
Inactive flows
Selecting this option shows potential flows allowed by your network policies, helping you identify missing network policies needed to achieve tighter isolation. You can select the time period for which to display information.
Network policies
You can view existing policies for a selected component or view components that have no policies. You can also simulate network policies from the network graph view. See "Simulating network policies from the network graph" for more information.
8.1.1.2. External entities and connections in the network graph

The network graph view shows network connections between managed clusters and external sources. In addition, RHACS automatically discovers and highlights public Classless Inter-Domain Routing (CIDR) address blocks, such as Google Cloud, AWS, Microsoft Azure, Oracle Cloud, and Cloudflare. Using this information, you can identify deployments with active external connections and decide if they are making or receiving unauthorized connections from outside your network.

By default, the external connections point to a common External Entities icon and different CIDR address blocks in the network graph. However, you can choose not to show auto-discovered CIDR blocks by clicking Manage CIDR blocks and deselecting Auto-discovered CIDR blocks.

RHACS includes IP ranges for the following cloud providers:

  • Google Cloud
  • AWS
  • Microsoft Azure
  • Oracle Cloud
  • Cloudflare

RHACS fetches and updates the cloud providers' IP ranges every 7 days, and updates CIDR blocks daily. If you are using offline mode, you can update these ranges by installing new support packages.

The following image provides an example of the network graph. In this example, based on the options that the user has chosen, the graph depicts deployments in the selected namespace. Traffic flows are not displayed until you click on an item such as a deployment. The graph uses a red badge to indicate deployments that are missing policies and therefore allowing all network traffic.

8.1.1.3. Connections involving internal entities

The network graph is useful for identifying deployments with active connections to entities that do not belong to any known deployment or CIDR block. Some of these connections never reach outside of the cluster and are made within the cluster’s private network. The network graph represents those as connections to or from internal entities.

Connections with internal entities represent a connection between a deployment and an IP address that belongs to the private address space as defined in RFC 1918. In some cases, Sensor is unable to identify one or both deployments involved in a connection. In that case, the system analyzes the IP address and decides whether the connection is internal or external.

The following scenarios can lead to a connection being categorized as one involving internal entities:

  • A change of IP address or the deletion of a deployment accepting connections (the server) while the party initiating the connection (the client) still attempts to reach it
  • A deployment communicating with the orchestrator API
  • A deployment communicating using a networking CNI plugin, for example, Calico
  • A restart of Sensor, resulting in a reset of the mapping of IP addresses to past deployments, for example, when Sensor does not recognize the IP addresses of past entities or past IP addresses of existing entities
  • A connection that involves an entity not managed by the orchestrator (in some cases, that might be seen as outside of the cluster) but is using an IP address from the private address space as defined in RFC 1918

Internal entities are indicated with an icon as shown in the following graphic. Clicking on Internal entities shows the flows for these entities.

Figure 8.4. Internal entities example

Network graph showing internal entities

8.1.2. Access control and permissions

To view network graphs, the user must have at least the permissions granted to the Network Graph Viewer default permission set.

The following permissions are granted to the Network Graph Viewer permission set:

  • Read Deployment
  • Read NetworkGraph
  • Read NetworkPolicy

For more information, see "System permission sets" in the "Additional resources" section.

Additional resources

8.1.3. Viewing deployment information

The network graph provides a visual map of deployments, namespaces, and connections that RHACS has discovered. By clicking on a deployment in the graph, you can view information about the deployment, including the following details:

  • Network security, such as the number of flows, existing or missing network policy rules, and listening ports
  • Labels and annotations
  • Port configurations
  • Container information
  • Anomalous and baseline flows for ingress and egress connections, including protocols and port numbers
  • Network policies

Procedure

To view details for deployments in a namespace:

  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.

8.1.4. Viewing network policies in the network graph

Network policies specify how groups of pods are allowed to communicate with each other and with other network endpoints. Kubernetes NetworkPolicy resources use labels to select pods and define rules that specify what traffic is allowed to or from the selected pods. RHACS discovers and displays network policy information for all your Kubernetes clusters, namespaces, deployments, and pods, in the network graph.

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.

8.1.5. Configuring CIDR blocks in the network graph

You can specify custom CIDR blocks or configure the display of auto-discovered CIDR blocks in the network graph.

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.

8.2. Using the network graph to generate and simulate network policies

8.2.1. About generating policies from the network graph

A Kubernetes network policy controls which pods receive incoming network traffic, and which pods can send outgoing traffic. By using network policies to enable and disable traffic to or from pods, you can limit your network attack surface.

These network policies are YAML configuration files. It is often difficult to gain insights into the network flow and manually create these files. You can use RHACS to generate these files. When you automatically generate network policies, RHACS follows these guidelines:

  • RHACS generates a single network policy for each deployment in the namespace. The pod selector for the policy is the pod selector of the deployment.

    • If a deployment already has a network policy, RHACS does not generate new policies or delete existing policies.

      Generated policies only restrict traffic to existing deployments.

    • Deployments that you create later will not have any restrictions unless you create or generate new network policies for them.
    • If a new deployment needs to contact a deployment with a network policy, you might need to edit the network policy to allow access.
  • Each policy has the same name as the deployment name, prefixed with stackrox-generated-. For example, the policy name for the deployment depABC in the generated network policy is stackrox-generated-depABC. All generated policies also have an identifying label.
  • RHACS generates a single rule allowing traffic from any IP address if one of the following conditions are met:

    • The deployment has an incoming connection from outside the cluster within the selected time
    • The deployment is exposed through a node port or load balancer service
  • RHACS generates one ingress rule for every deployment from which there is an incoming connection.

    • For deployments in the same namespace, this rule uses the pod selector labels from the other deployment.
    • For deployments in different namespaces, this rule uses a namespace selector. To make this possible, RHACS automatically adds a label, namespace.metadata.stackrox.io/name, to each namespace.
Important

In rare cases, if a standalone pod does not have any labels, the generated policy allows traffic from or to the pod’s entire namespace.

8.2.2. Generating network policies in the network graph

RHACS lets you automatically generate network policies based on the actual observed network communication flows in your environment.

You can generate policies based on the cluster, namespaces, and deployments that you have selected in the network graph. Policies are generated for any deployments that are included in the current Network Graph scope. For example, the current scope could include the entire cluster, a cluster and namespaces, or individually selected deployments in the selected namespaces. You can also further reduce the scope by applying one of the filters from the Filter deployments field with any combination of the cluster, namespace, and deployment selections. For example, you could narrow the scope to deployments in a specific cluster and namespace that are affected by a specific CVE. Policies are generated from the traffic observed during the baseline discovery period.

  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 ConfigurationIntegrations. 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.

8.2.3. Saving generated policies in the network graph

You can download and save the generated network policies from RHACS. Use this option to download policies so that you can commit the policies into a version control system such as Git.

Procedure

  • After generating a network policy, click the Download YAML icon in the Network Policy Simulator panel.

8.2.4. Testing generated policies in the network graph

After you download the network policies that RHACS generates, you can test them by applying them to your cluster by using the CLI or your automated deployment procedures. You cannot apply generated network policies directly in the network graph.

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.
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.

8.2.5. Reverting to a previously applied policy in the network graph

You can remove a policy and revert to a previously applied policy.

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.

8.2.6. Deleting all policies autogenerated in the network graph

You can delete all automatically generated policies from your cluster that you have created by using RHACS.

Procedure

  • Run the following command:

    $ oc get ns -o jsonpath='{.items[*].metadata.name}' | \
    xargs -n 1 oc delete networkpolicies -l \
    'network-policy-generator.stackrox.io/generated=true' -n 1
    1
    If you use Kubernetes, enter kubectl instead of oc.

8.2.7. Simulating network policies from the network graph

Your current network policies might allow unneeded network communications. You can use the network policy generator to create network policies that restrict ingress traffic to the computed baselines for a set of deployments.

Note

The Network Graph does not display the generated policies in the visualization. Generated policies are only for ingress traffic and policies that restrict egress traffic are not generated.

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".

8.3. About network baselining in the network graph

In RHACS, you can minimize your risks by using network baselining. It is a proactive approach to keep your infrastructure secure. RHACS first discovers existing network flows and creates a baseline, and then it treats network flows outside of this baseline as anomalous.

When you install RHACS, there is no default network baseline. As RHACS discovers network flows, it creates a baseline and then it adds all discovered network flows to it, following these guidelines:

  • When RHACS discovers new network activity, it adds that network flow to the network baseline.
  • Network flows do not show up as anomalous flows and do not trigger any violations.

After the discovery phase, the following actions occur:

  • RHACS stops adding network flows to the network baselines.
  • New network flows that are not in the network baseline show up as anomalous flows but they do not trigger any violations.

8.3.1. Viewing network baselines from the network graph

You can view network baselines from the network graph view.

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, kebab , 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.

8.3.2. Downloading network baselines from the network graph

You can download network baselines as YAML files from the network graph view.

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.

8.3.3. Configuring network baselining time frame

You can use the ROX_NETWORK_BASELINE_OBSERVATION_PERIOD and the ROX_BASELINE_GENERATION_DURATION environment variables to configure the observation period and the network baseline generation duration.

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.

8.3.4. Enabling alerts on baseline violations in the network graph

You can configure RHACS to detect anomalous network flows and trigger violations for traffic that is not in the baseline. This can help you determine if the network contains unwanted traffic before you block traffic with a network policy.

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.

Chapter 9. Build-time network policy tools

Build-time network policy tools let you automate the creation and validation of Kubernetes network policies in your development and operations workflows using the roxctl CLI. These tools work with a specified file directory containing your project’s workload and network policy manifests and do not require RHACS authentication.

Table 9.1. Network policy tools
CommandDescription

roxctl netpol generate

Generates Kubernetes network policies by analyzing your project’s YAML manifests in a specified directory. For more information, see Using the build-time network policy generator.

roxctl netpol connectivity map

Lists the allowed connections between workloads in your project directory by examining the workload and Kubernetes network policy manifests. You can generate the output in various text formats or in a graphical .dot format. For more information, see Connectivity mapping using the roxctl netpol connectivity map command.

roxctl netpol connectivity diff

Creates a list of variations in the allowed connections between two project versions. This is determined by the workload and Kubernetes network policy manifests in each version’s directory. This feature shows the semantic differences which are not obvious when performing a source code (syntactic) diff. For more information, see Identifying the differences in allowed connections between project versions.

9.1. Using the build-time network policy generator

The build-time network policy generator can automatically generate Kubernetes network policies based on application YAML manifests. You can use it to develop network policies as part of the continuous integration/continuous deployment (CI/CD) pipeline before deploying applications on your cluster.

Red Hat developed this feature in partnership with the developers of the NP-Guard project. First, the build-time network policy generator analyzes Kubernetes manifests in a local folder, including service manifests, config maps, and workload manifests such as Pod, Deployment, ReplicaSet, Job, DaemonSet, and StatefulSet. Then, it discovers the required connectivity and creates the Kubernetes network policies to achieve pod isolation. These policies allow no more and no less than the needed ingress and egress traffic.

9.1.1. Generating build-time network policies

The build-time network policy generator is included in the roxctl CLI. For the build-time network policy generation feature, roxctl CLI does not need to communicate with RHACS Central so you can use it in any development environment.

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.

  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.

Next steps

  • After generating the policies, you must inspect them for completeness and accuracy, in case any relevant network address was not specified as expected in the YAML files.
  • Most importantly, verify that required connections are not blocked by the isolating policies. To help with this inspection you can use the roxctl netpol connectivity map tool.
Note

Applying network policies to the cluster as part of the workload deployment using automation saves time and ensures accuracy. You can follow a GitOps approach by submitting the generated policies using pull requests, providing the team an opportunity to review the policies before deploying them as part of the pipeline.

9.1.2. roxctl netpol generate command options

The roxctl netpol generate command supports the following options:

OptionDescription

-h, --help

View the help text for the netpol command.

-d, --output-dir <dir>

Save the generated policies into a target folder. One file per policy.

-f, --output-file <filename>

Save and merge the generated policies into a single YAML file.

--fail

Fail on the first encountered error. The default value is false.

--remove

Remove the output path if it already exist.

--strict

Treat warnings as errors. The default value is false.

9.2. Connectivity mapping using the roxctl netpol connectivity map command

Connectivity mapping provides details on the allowed connections between different workloads based on network policies defined in Kubernetes manifests. You can visualize and understand how different workloads in your Kubernetes environment are allowed to communicate with each other according to the network policies you set up.

To retrieve connectivity mapping information, the roxctl netpol connectivity map command requires a directory path that contains Kubernetes workloads and network policy manifests. The output provides details about connectivity details within the Kubernetes resources analyzed.

9.2.1. Retrieving connectivity mapping information from a Kubernetes manifest directory

Procedure

  • Run the following command to retrieve the connectivity mapping information:

    $ roxctl netpol connectivity map <folder_path> [flags] 1
    1
    Specify the path to the folder, which can include sub-folders that contain YAML resources and network policies for analysis, for example, netpol-analysis-example-minimal/. 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 connectivity map command options.

    Example 9.1. Example output

    srcdstconn

    0.0.0.0-255.255.255.255

    default/frontend[Deployment]

    TCP 8080

    default/frontend[Deployment]

    0.0.0.0-255.255.255.255

    UDP 53

    default/frontend[Deployment]

    default/backend[Deployment]

    TCP 9090

The output shows you a table with a list of allowed connectivity lines. Each connectivity line consists of three parts: source (src), destination (dst), and allowed connectivity attributes (conn).

You can interpret src as the source endpoint, dst as the destination endpoint, and conn as the allowable connectivity attributes. An endpoint has the format namespace/name[Kind], for example, default/backend[Deployment].

9.2.2. Connectivity map output formats and visualizations

You can use various output formats, including txt, md, csv, json, and dot. The dot format is ideal for visualizing the output as a connectivity graph. It can be viewed using graph visualization software such as Graphviz tool, and extensions to VSCode. You can convert the dot output to formats such as svg, jpeg, or png using Graphviz, whether it is installed locally or through an online viewer.

9.2.3. Generating svg graphs from the dot output using Graphviz

Follow these steps to create a graph in svg format from the dot output.

Prerequisites

  • Graphviz is installed on your local system.

Procedure

9.2.4. roxctl netpol connectivity map command options

The roxctl netpol connectivity map command supports the following options:

OptionDescription

--fail

Fail on the first encountered error. The default value is false.

--focus-workload string

Focus on connections of a specified workload name in the output.

-h, --help

View the help text for the roxctl netpol connectivity map command.

-f, --output-file string

Save the connections list output into a specific file.

-o, --output-format string

Configure the output format. The supported formats are txt, json, md, dot, and csv. The default value is txt.

--remove

Remove the output path if it already exists. The default value is false.

--save-to-file

Save the connections list output into a default file. The default value is false.

--strict

Treat warnings as errors. The default value is false.

9.3. Identifying the differences in allowed connections between project versions

This command helps you understand the differences in allowed connections between two project versions. It analyses the workload and Kubernetes network policy manifests located in each version’s directory and creates a representation of the differences in text format.

You can view connectivity difference reports in a variety of output formats, including text, md, dot, and csv.

9.3.1. Generating connectivity difference reports with the roxctl netpol connectivity diff command

To produce a connectivity difference report, the roxctl netpol connectivity diff command requires two folders, dir1 and dir2, each containing Kubernetes manifests, including network policies.

Procedure

  • Run the following command to determine the connectivity differences between the Kubernetes manifests in the specified directories:

    $ roxctl netpol connectivity diff --dir1=<folder_path_1> --dir2=<folder_path_2> [flags] 1
    1
    Specify the path to the folders, which can include sub-folders that contain YAML resources and network policies for analysis. The command scans the entire sub-folder trees for both the directories. For example, <folder_path_1> is netpol-analysis-example-minimal/ and <folder_path_2> is netpol-diff-example-minimal/. Optionally, you can also specify parameters to modify the behavior of the command.

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

    Note

    The command considers all YAML files that you can accept using kubectl apply -f, and then these become valid inputs for your roxctl netpol connectivity diff command.

    Example 9.2. Example output

    diff-typesourcedestinationdir 1dir 2workloads-diff-info

    changed

    default/frontend[Deployment]

    default/backend[Deployment]

    TCP 9090

    TCP 9090,UDP 53

     

    added

    0.0.0.0-255.255.255.255

    default/backend[Deployment]

    No Connections

    TCP 9090

     

The semantic difference report gives you an overview of the connections that were changed, added, or removed in dir2 compared to the connections allowed in dir1. When you review the output, each line represents one allowed connection that was added, removed, or changed in dir2 compared to dir1.

The following are example outputs generated by the roxctl netpol connectivity diff command in various formats:

If applicable, the workloads-diff-info provides additional details about added or removed workloads related to the added or removed connection.

For example, if a connection from workload A to workload B is removed because workload B was deleted, the workloads-diff-info indicates that workload B was removed. However, if such a connection was removed only because of network policy changes and neither workload A nor B was deleted, the workloads-diff-info is empty.

9.3.2. roxctl netpol connectivity diff command options

The roxctl netpol connectivity diff command supports the following options:

OptionDescription

--dir1 string

First directory path of the input resources. This is a mandatory option.

--dir2 string

Second directory path of the input resources to be compared with the first directory path. This is a mandatory option.

--fail

Fail on the first encountered error. The default value is false.

-h, --help

View the help text for the roxctl netpol connectivity diff command.

-f, --output-file string

Save the connections difference output into a specific file.

-o, --output-format string

Configure the output format. The supported formats are txt, md, dot, and csv. The default value is txt.

--remove

Remove the output path if it already exists. The default value is false.

--save-to-file

Save the connections difference output into default a file. The default value is false.

--strict

Treat warnings as errors. The default value is false.

9.3.3. Distinguishing between syntactic and semantic difference outputs

In the following example, dir1 is netpol-analysis-example-minimal/, and dir2 is netpol-diff-example-minimal/. The difference between the directories is a small change in the network policy backend-netpol.

Example policy from dir1:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  creationTimestamp: null
  name: backend-netpol
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 9090
      protocol: TCP
  podSelector:
    matchLabels:
      app: backendservice
  policyTypes:
  - Ingress
  - Egress
status: {}

The change in dir2 is an added - before the ports attribute, which produces a difference output.

9.3.3.1. Syntactic difference output

Procedure

  • Run the following command to compare the contents of the netpols.yaml files in the two specified directories:

    $ diff netpol-diff-example-minimal/netpols.yaml netpol-analysis-example-minimal/netpols.yaml

    Example output

    12c12
    <   - ports:
    ---
    >     ports:

9.3.3.2. Semantic difference output

Procedure

  • Run the following command to analyze the connectivity differences between the Kubernetes manifests and network policies in the two specified directories:

    $ roxctl netpol connectivity diff --dir1=roxctl/netpol/connectivity/diff/testdata/netpol-analysis-example-minimal/ --dir2=roxctl/netpol/connectivity/diff/testdata/netpol-diff-example-minimal

    Example output

    Connectivity diff:
    diff-type: changed, source: default/frontend[Deployment], destination: default/backend[Deployment], dir1:  TCP 9090, dir2: TCP 9090,UDP 53
    diff-type: added, source: 0.0.0.0-255.255.255.255, destination: default/backend[Deployment], dir1:  No Connections, dir2: TCP 9090

Chapter 10. Auditing listening endpoints

Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides the ability to audit the processes that are listening on ports in your secured clusters and filter this data by deployment, namespace, or cluster.

You can view information about processes and ports that they are listening on by using the following methods:

  • In the RHACS web portal, go to NetworkListening Endpoints.
  • Connect to the ListeningEndpointsService object in the API. For more information on the API, go to HelpAPI reference in the RHACS web portal.

The page provides a list of processes by deployment, with the following information displayed for each process on the list:

  • Deployment name
  • Cluster
  • Namespace
  • Count, or the number of processes listening on the ports in the deployment

You can further filter the information displayed on the page by using the filter field and entering individual deployments, namespaces, and clusters.

Click the expand icon at the top of the list to expand all sections for all deployments listed, or click the expand icon on a single deployment line to view additional information about that deployment. The following information is provided:

  • Exec file path: Location of the process
  • PID: System ID of the process
  • Port: Port on which the process is listening
  • Protocol: Protocol in use by the process
  • Pod ID: Name of the pod where the process is contained
  • Container name: Name of the container in which the process that is listening is located

Clicking on a deployment name brings you to the Risk page in the RHACS web portal, where you can view information about the deployment, including risk indicators such as policy violations and additional deployment details.

Chapter 11. Reviewing cluster configuration

Learn how to use the Configuration Management view and understand the correlation between various entities in your cluster to manage your cluster configuration efficiently.

Every OpenShift Container Platform cluster includes many different entities distributed throughout the cluster, which makes it more challenging to understand and act on the available information.

Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides efficient configuration management that combines all these distributed entities on a single page. It brings together information about all your clusters, namespaces, nodes, deployments, images, secrets, users, groups, service accounts, and roles in a single Configuration Management view, helping you visualize different entities and the connections between them.

11.1. Using the Configuration Management view

To open the Configuration Management view, select Configuration Management from the navigation menu. Similar to the Dashboard, it displays some useful widgets.

These widgets are interactive and show the following information:

  • Security policy violations by severity
  • The state of CIS (Center for Information Security) for Kubernetes benchmark controls
  • Users with administrator rights in the most clusters
  • Secrets used most widely in your clusters

The header in the Configuration Management view shows you the number of policies and CIS controls in your cluster.

Note

Only policies in the Deploy life cycle phase are included in the policy count and policy list view.

The header includes drop-down menus that allow you to switch between entities. For example, you can:

  • Click Policies to view all policies and their severity, or select CIS Controls to view detailed information about all controls.
  • Click Application and Infrastructure and select clusters, namespaces, nodes, deployments, images, and secrets to view detailed information.
  • Click RBAC Visibility and Configuration and select users and groups, service accounts, and roles to view detailed information.

11.2. Identifying misconfigurations in Kubernetes roles

You can use the Configuration Management view to identify potential misconfigurations, such as users, groups, or service accounts granted the cluster-admin role, or roles that are not granted to anyone.

11.2.1. Finding Kubernetes roles and their assignment

Use the Configuration Management view to get information about the Kubernetes roles that are assigned to specific users and groups.

Procedure

  1. Go to the RHACS portal and click Configuration Management.
  2. Select Role-Based Access ControlUsers 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.

11.2.2. Finding service accounts and their permissions

Use the Configuration Management view to find out where service accounts are in use and their permissions.

Procedure

  1. In the RHACS portal, go to Configuration Management.
  2. Select RBAC Visibility and ConfigurationService 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.

11.2.3. Finding unused Kubernetes roles

Use the Configuration Management view to get more information about your Kubernetes roles and find unused roles.

Procedure

  1. In the RHACS portal, go to Configuration Management.
  2. Select RBAC Visibility and ConfigurationRoles 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.

11.3. Viewing Kubernetes secrets

View Kubernetes secrets in use in your environment and identify deployments using those secrets.

Procedure

  1. In the RHACS portal, go to Configuration Management.
  2. On the Secrets Most Used Across Deployments widget, select View All. The Secrets view displays a list of Kubernetes secrets.
  3. Select a row to view more details.

Use the available information to identify if the secrets are in use in deployments where they are not needed.

11.4. Finding policy violations

The Policy Violations by Severity widget in the Configuration Management view displays policy violations in a sunburst chart. Each level of the chart is represented by one ring or circle.

  • The innermost circle represents the total number of violations.
  • The next ring represents the Low, Medium, High, and Critical policy categories.
  • The outermost ring represents individual policies in a particular category.

The Configuration Management view only shows the information about policies that have the Lifecycle Stage set to Deploy. It does not include policies that address runtime behavior or those configured for assessment in the Build stage.

Procedure

  1. In the RHACS portal, go to Configuration Management.
  2. On the Policy Violations by Severity widget, move your mouse over the sunburst chart to view details about policy violations.
  3. Select n rated as high, where n is a number, to view detailed information about high-priority policy violations. The Policies view displays a list of policy violations filtered on the selected category.
  4. Select a row to view more details, including policy description, remediation, deployments with violations, and more. The details are visible in a panel.
  5. The Policy Findings section in the information panel lists deployments where these violations occurred.
  6. Select a deployment under the Policy Findings section to view related details including Kubernetes labels, annotations, and service account.

You can use the detailed information to plan a remediation for violations.

11.5. Finding failing CIS controls

Similar to the Policy Violations sunburst chart in the Configuration Management view, the CIS Kubernetes v1.5 widget provides information about failing Center for Information Security (CIS) controls.

Each level of the chart is represented by one ring or circle.

  • The innermost circle represents the percentage of failing controls.
  • The next ring represents the control categories.
  • The outermost ring represents individual controls in a particular category.

Procedure

  1. To view details about failing controls, hover over the sunburst chart.
  2. To view detailed information about failing controls, select n Controls Failing, where n is a number. The Controls view displays a list of failing controls filtered based on the compliance state.
  3. Select a row to view more details, including control descriptions and nodes where the controls are failing.
  4. The Control Findings section in the information panel lists nodes where the controls are failing. Select a row to view more details, including Kubernetes labels, annotations, and other metadata.

You can use the detailed information to focus on a subset of nodes, industry standards, or failing controls. You can also assess, check, and report on the compliance status of your containerized infrastructure.

Chapter 12. Examining images for vulnerabilities

With Red Hat Advanced Cluster Security for Kubernetes, you can analyze images for vulnerabilities using the RHACS scanners, or you can configure an integration to use another supported scanner.

The scanners in RHACS analyze each image layer to find packages and match them against known vulnerabilities by comparing them with a vulnerability database populated from different sources. Depending on the scanner used, sources include the National Vulnerability Database (NVD), the Open Source Vulnerabilities (OSV) database, and operating system vulnerability feeds.

Note

The RHACS Scanner V4 uses the OSV database available at OSV.dev under this license.

RHACS contains two scanners: the StackRox Scanner and Scanner V4.

The StackRox Scanner originates from a fork of the Clair v2 open source scanner and is the default scanner. In version 4.4, RHACS introduced Scanner V4, built on ClairCore, which provides additional image scanning features.

Note

This documentation uses the term "RHACS scanner" or "Scanner" to refer to the combined scanning capabilities provided by the two scanners: the StackRox Scanner and Scanner V4. When referring to the capabilities of a specific scanner, the name of the specific scanner is used.

When the RHACS scanner finds any vulnerabilities, it performs the following actions:

  • Shows them in the Vulnerability Management view for detailed analysis
  • Ranks vulnerabilities according to risk and highlights them in the RHACS portal for risk assessment
  • Checks them against enabled security policies

The RHACS scanner inspects the images and identifies the installed components based on the files in the images. It might fail to identify installed components or vulnerabilities if the final images are modified to remove the following files:

ComponentsFiles

Package managers

  • /etc/alpine-release
  • /etc/apt/sources.list
  • /etc/lsb-release
  • /etc/os-release or /usr/lib/os-release
  • /etc/oracle-release, /etc/centos-release, /etc/redhat-release, or /etc/system-release
  • Other similar system files.

Language-level dependencies

  • package.json for JavaScript.
  • dist-info or egg-info for Python.
  • MANIFEST.MF in Java Archive (JAR) for Java.

Application-level dependencies

  • dotnet/shared/Microsoft.AspNetCore.App/
  • dotnet/shared/Microsoft.NETCore.App/

12.1. About RHACS Scanner V4

RHACS provides its own scanner, or you can configure an integration to use RHACS with another vulnerability scanner.

Beginning with version 4.4, Scanner V4, built on ClairCore, provides scanning for language and operating system-specific image components. For version 4.4, RHACS also uses the StackRox Scanner to provide some scanning functionality until that functionality is implemented in a future release.

12.2. Scanning images

For version 4.4, RHACS provides two scanners: the StackRox Scanner and Scanner V4. Both scanners can examine images in secured clusters connected in your network. Secured cluster scanning is enabled by default in Red Hat OpenShift environments deployed by using the Operator or when delegated scanning is used. See "Accessing delegated image scanning" for more information.

Important

Even if you have Scanner V4 enabled, at this time, the StackRox Scanner must still be enabled to provide scanning of RHCOS nodes and platform vulnerabilities such as Red Hat OpenShift, Kubernetes, and Istio. Support for that functionality in Scanner V4 is planned for a future release. Do not disable the StackRox Scanner.

When using the StackRox Scanner, RHACS performs the following actions:

  • Central submits image scanning requests to the StackRox Scanner.
  • Upon receiving these requests, the StackRox Scanner pulls the image layers from the relevant registry, checks the images, and identifies installed packages in each layer. Then it compares the identified packages and programming language-specific dependencies with the vulnerability lists and sends information back to Central
  • The StackRox Scanner identifies the vulnerabilities in the following areas:

    • Base image operating system
    • Packages that are installed by the package managers
    • Programming language specific dependencies
    • Programming runtimes and frameworks

When using Scanner V4, RHACS performs the following actions:

  • Central requests the Scanner V4 Indexer to download and index (analyze) given images.
  • Scanner V4 Indexer pulls image metadata from registries to determine the layers of the image, and downloads each previously unindexed layer.
  • Scanner V4 Indexer requests mapping files from Central that assist the indexing process. Scanner V4 Indexer produces in an index report.
  • Central requests that Scanner V4 Matcher match given images to known vulnerabilities. This process results in the final scan result: a vulnerability report. Scanner V4 Matcher requests the latest vulnerabilities from Central.
  • Scanner V4 Matcher requests the results of the image indexing, the index report, from Scanner V4 Indexer. It then uses the report to determine relevant vulnerabilities. This interaction occurs only when the image is indexed in the Central cluster. This interaction does not occur when Scanner V4 is matching vulnerabilities for images indexed in secured clusters.
  • The Indexer stores data in the Scanner V4 DB that is related to the indexing results to ensure that image layers are only downloaded and indexed once. This prevents unnecessary network traffic and other resource utilization.
  • When secured cluster scanning is enabled, Sensor requests Scanner V4 to index images. Scanner V4 Indexer requests mapping files from Sensor that assist the indexing process unless Central exists in the same namespace. In that case, Central is contacted instead.

12.2.1. Understanding and addressing common Scanner warning messages

When scanning images with Red Hat Advanced Cluster Security for Kubernetes (RHACS), you might see the CVE DATA MAY BE INACCURATE warning message. Scanner displays this message when it cannot retrieve complete information about the operating system or other packages in the image.

The following table shows some common Scanner warning messages:

Table 12.1. Warning messages
MessageDescription

Unable to retrieve the OS CVE data, only Language CVE data is available

Indicates that Scanner does not officially support the base operating system of the image; therefore, it cannot retrieve CVE data for the operating system-level packages.

Stale OS CVE data

Indicates that the base operating system of the image has reached end-of-life, which means the vulnerability data is outdated. For example, Debian 8 and 9.

For more information about the files needed to identify the components in the images, see Examining images for vulnerabilities.

Failed to get the base OS information

Indicates that Scanner scanned the image, but was unable to determine the base operating system used for the image.

Failed to retrieve metadata from the registry

Indicates that the target registry is unreachable on the network. The cause could be a firewall blocking docker.io, or an authentication issue preventing access.

To analyze the root cause, create a special registry integration for private registries or repositories to get the pod logs for RHACS Central. For instructions on how to do this, see Integrating with image registries.

Image out of scope for Red Hat Vulnerability Scanner Certification

Indicates that Scanner scanned the image, but the image is old and does not fall within the scope of Red Hat Scanner Certification. For more information, see Partner Guide for Red Hat Vulnerability Scanner Certification.

Important

If you are using a Red Hat container image, consider using a base image newer than June 2020.

12.2.2. Supported package formats

Scanner can check for vulnerabilities in images that use the following package formats:

  • apt
  • apk
  • dpkg
  • rpm

12.2.3. Supported programming languages

Scanner can check for vulnerabilities in dependencies for the following programming languages:

  • Go (Scanner V4 only)

    • Binaries: The standard library version used to build the binary is analyzed. If the binaries are built with module support (go.mod), then the dependencies are also analyzed.
  • Java

    • JAR
    • WAR
    • EAR
  • JavaScript

    • Node.js
    • npm package.json
  • Python

    • egg and wheel formats
  • Ruby

    • gem

12.2.4. Supported runtimes and frameworks

Beginning from Red Hat Advanced Cluster Security for Kubernetes 3.0.50 (Scanner version 2.5.0), the StackRox Scanner identifies vulnerabilities in the following developer platforms:

  • .NET Core
  • ASP.NET Core

These are not supported by Scanner V4.

12.2.5. Supported operating systems

The supported platforms listed in this section are the distributions in which Scanner identifies vulnerabilities, and it is different from the supported platforms on which you can install Red Hat Advanced Cluster Security for Kubernetes.

Scanner identifies vulnerabilities in images that contain the following Linux distributions. For more information about the vulnerability databases used, see "Vulnerability sources" in "RHACS Architecture".

DistributionVersion

Alpine Linux

alpine:3.2[1],alpine:3.3, alpine:3.4, alpine:3.5, alpine:3.6, alpine:3.7, alpine:3.8, alpine:3.9, alpine:3.10, alpine:3.11, alpine:3.12, alpine:3.13, alpine:3.14, alpine:3.15, alpine:3.16, alpine:3.17, alpine:3.18, alpine:3.19, alpine:3.20, alpine:edge

Amazon Linux

amzn:2018.03, amzn:2, amzn:2023[2]

CentOS

centos:6[1], centos:7[1], centos:8[1]

Debian

debian:10, debian:11, debian:12, debian:unstable[1], distroless

Oracle Linux

ol:5[2], ol:6[2], ol:7[2], ol:8[2], ol:9[2]

Photon OS

photon:1.0[2], photon:2.0[2], photon:3.0[2]

Red Hat Enterprise Linux (RHEL)

rhel:6[3], rhel:7[3], rhel:8[3], rhel:9[3]

SUSE

sles:11[2], sles:12[2], sles:15[2], opensuse-leap:15.0[2], opensuse-leap:15.1[2]

Ubuntu

ubuntu:14.04, ubuntu:16.04, ubuntu:18.04, ubuntu:20.04,ubuntu:22.04, ubuntu:23.10, ubuntu:24.04

The following vulnerability sources are not updated by the vendor: ubuntu:12.04, ubuntu:12.10, ubuntu:13.04, ubuntu:14.10, ubuntu:15.04, ubuntu::15.10, ubuntu::16.10, ubuntu:17.04, ubuntu:17.10, ubuntu:18.10, ubuntu:19.04, ubuntu:19.10, ubuntu:20.10, ubuntu:21.04, ubuntu:21.10, ubuntu:22.10, ubuntu:23.04, debian:8[1], debian:9[1], debian:10[1]

  1. Only supported in the StackRox Scanner.
  2. Only supported in Scanner V4.
  3. Images older than June 2020 are not supported in Scanner V4.
Note
  • Scanner does not support the Fedora operating system because Fedora does not maintain a vulnerability database. However, Scanner still detects language-specific vulnerabilities in Fedora-based images.

12.2.6. Redirecting image pulls from a source registry to a mirrored registry

Red Hat Advanced Cluster Security for Kubernetes (RHACS) supports scanning images from registry mirrors that you have configured by using one of the following OpenShift Container Platform custom resources (CRs):

  • ImageContentSourcePolicy (ICSP)
  • ImageDigestMirrorSet (IDMS)
  • ImageTagMirrorSet (ITMS)

For more information about how to configure image registry repository mirroring, see "Configuring image registry repository mirroring".

You can automatically scan images from registry mirrors by using delegated image scanning.

For more information about how to configure delegated image scanning, see "Scanning images by using secured clusters".

12.3. Accessing delegated image scanning

You can have isolated container image registries that are only accessible from your secured clusters. The delegated image scanning feature enables you to scan images from any registry in your secured clusters.

12.3.1. Enhancing image scanning by accessing delegated image scanning

Currently, by default, Central Services Scanner performs both indexing (identification of components) and vulnerability matching (enrichment of components with vulnerability data) for images observed in your secured clusters, with the exception of images from the OpenShift Container Platform integrated registry.

For images from the OpenShift Container Platform integrated registry, Scanner-slim installed in your secured cluster performs the indexing, and the Central Services Scanner performs the vulnerability matching.

The delegated image scanning feature extends scanning functionality by allowing Scanner-slim to index images from any registry and then send them to Central for vulnerability matching. To use this feature, ensure that Scanner-slim is installed in your secured clusters. If Scanner-slim is not present, scan requests are sent directly to Central.

12.3.2. Scanning images by using secured clusters

To scan images by using the secured clusters instead of the Central services, you can use the delegated image scanning feature.

A new delegated scanning configuration specifies the registries from which you can delegate image scans. For images that Sensor observes, you can use the delegated registry configuration to delegate scans from no registries, all registries, or specific registries.

To enable delegation of scans by using the roxctl CLI, Jenkins plugin, or API, you must also specify a destination cluster and source registry.

Prerequisites

  • You have installed Scanner in the secured cluster to scan images.

    Note

    Enabling Scanner is supported on OpenShift Container Platform and Kubernetes secured clusters.

Procedure

  1. In the RHACS portal, click Platform Configuration → Clusters.
  2. In the Clusters view header, click Delegated scanning.
  3. In the Delegated Image Scanning page, provide the following information:

    • Delegate scanning for: To choose the scope of the image delegation, select one of the following options:

      • None: The default option. This option specifies that the secured clusters do not scan any images, except for images from the integrated OpenShift image registry.
      • All registries: This option indicates that the secured clusters scan all the images.
      • Specified registries: This option specifies the images that secured clusters should scan based on the registries list.
    • Select default cluster to delegate to: From the drop-down list, select the name of the default cluster. The default cluster processes the scan requests coming from the command-line interface (CLI) and API. This is optional and you can select None if required.
    • Optional: To specify the source registry and destination cluster details, click Add registry.

      For example, specify the source registry as example.com, and select remote from the drop-down list for the destination cluster. You can add more than one source registry and destination cluster if required.

      Important

      You can select the destination cluster as None if the scan requests are not coming from the CLI and API.

  4. Click Save.

Image integrations are now synchronized between Central and Sensor, and Sensor captures pull secrets from each namespace. Sensor then uses these credentials to authenticate to the image registries.

12.3.3. Installing and configuring Scanner-slim on secured clusters

12.3.3.1. Using the Operator

RHACS Operator installs a Scanner-slim version on each secured cluster to scan images in the OpenShift Container Platform integrated registry and optionally other registries.

For more information, see Installing RHACS on secured clusters by using the Operator.

12.3.3.2. Using Helm

Secured Cluster Services Helm chart (secured-cluster-services) installs a Scanner-slim version on each secured cluster. In Kubernetes, the secured cluster services include Scanner-slim as an optional component. On OpenShift Container Platform, however, RHACS installs a Scanner-slim version on each secured cluster to scan images in the OpenShift Container Platform integrated registry and optionally other registries.

12.3.3.3. Verifying after installation

Procedure

  • Verify that the status of the secured cluster indicates that Scanner is present and healthy:

    1. In the RHACS portal, go to Platform Configuration → Clusters.
    2. In the Clusters view, select a cluster to view its details.
    3. In the Health Status card, ensure that Scanner is present and is marked as Healthy.
12.3.3.4. Using image scanning

You can scan images stored in a cluster specific OpenShift Container Platform integrated image registry by using roxctl CLI, Jenkins, and API. You can specify the appropriate cluster in the delegated scanning configuration or use the cluster parameter available in roxctl CLI, Jenkins, and API.

For more information about how to scan images by using the roxctl CLI, see Image scanning by using the roxctl CLI.

12.4. Setting up scanning

You can configure settings for scanning, such as automatic scanning of active and inactive images.

12.4.1. Automatic scanning of active images

Red Hat Advanced Cluster Security for Kubernetes periodically scans all active images and updates the image scan results to reflect the latest vulnerability definitions. Active images are the images you have deployed in your environment.

Note

From Red Hat Advanced Cluster Security for Kubernetes 3.0.57, you can enable automatic scanning of inactive images by configuring the Watch setting for images.

Central fetches the image scan results for all active images from Scanner or other integrated image scanners that you use and updates the results every 4 hours.

You can also use the roxctl CLI to check the image scan results on demand.

12.4.2. Scanning inactive images

Red Hat Advanced Cluster Security for Kubernetes (RHACS) scans all active (deployed) images every 4 hours and updates the image scan results to reflect the latest vulnerability definitions.

You can also configure RHACS to scan inactive (not deployed) images automatically.

Procedure

  1. In the RHACS portal, click Vulnerability ManagementWorkload CVEs.
  2. Click Manage watched images.
  3. In the Image name field, enter the fully-qualified image name that begins with the registry and ends with the image tag, for example, docker.io/library/nginx:latest.
  4. Click Add image to watch list.
  5. Optional: To remove a watched image, locate the image in the Manage watched images window, and click Remove watch.

    Important

    In the RHACS portal, click Platform ConfigurationSystem Configuration to view the data retention configuration.

    All the data related to the image removed from the watched image list continues to appear in the RHACS portal for the number of days mentioned on the System Configuration page and is only removed after that period is over.

  6. Click Close to return to the Workload CVEs page.

12.5. About vulnerabilities

RHACS fetches vulnerability definitions and updates from multiple vulnerability feeds. These feeds are both general in nature, such as NVD, or distribution-specific, such as Alpine, Debian, and Ubuntu. For more information on viewing and addressing vulnerabilities that are found, see Vulnerability management.

12.5.1. Fetching vulnerability definitions

In online mode, Central fetches the vulnerability definitions every 5 minutes from a single feed. This feed combines vulnerability definitions from upstream sources, and it refreshes every 3 hours.

  • The address of the feed is https://definitions.stackrox.io.
  • You can change the default query frequency for Central and the StackRox Scanner by setting the ROX_SCANNER_VULN_UPDATE_INTERVAL environment variable:

    $ oc -n stackrox set env deploy/central ROX_SCANNER_VULN_UPDATE_INTERVAL=<value> 1
    1
    If you use Kubernetes, enter kubectl instead of oc.

Note the following guidance:

  • The StackRox Scanner’s configuration map still has an updater.interval parameter for configuring the scanner’s updating frequency, but it no longer includes the fetchFromCentral parameter.
  • Setting this environment variable is not supported for Scanner V4.

For more information about the vulnerability sources that RHACS uses, see "Vulnerability sources" in "Red Hat Advanced Cluster Security for Kubernetes architecture".

Additional resources

12.5.2. Understanding vulnerability scores in the dashboard

The vulnerability management dashboard in the Red Hat Advanced Cluster Security for Kubernetes portal shows a single Common Vulnerability Scoring System (CVSS) base score for each vulnerability. RHACS shows the CVSS score based on the following criteria:

  • If a CVSS v3 score is available, RHACS shows the score and lists v3 along with it. For example, 6.5 (v3).

    Note

    CVSS v3 scores are only available if you are using the StackRox Scanner version 1.3.5 and later or Scanner V4.

  • If a CVSS v3 score is not available, RHACS might show only the CVSS v2 score. For example, 6.5.

You can use the API to get the CVSS scores. If CVSS v3 information is available for a vulnerability, the response might include both CVSS v3 and CVSS v2 information.

For a Red Hat Security Advisory (RHSA), the CVSS score is set to the highest CVSS score among all the related CVEs. One RHSA can contain multiple CVEs, and Red Hat sometimes assigns a different score based on how a vulnerability affects other Red Hat products.

12.6. Disabling language-specific vulnerability scanning

Scanner identifies the vulnerabilities in the programming language-specific dependencies by default. You can disable the language-specific dependency scanning.

Procedure

  • To disable language-specific vulnerability scanning, run the following command:

    $ oc -n stackrox set env deploy/scanner \ 1
      ROX_LANGUAGE_VULNS=false 2
    1
    If you use Kubernetes, enter kubectl instead of oc.
    2
    If you are using Red Hat Advanced Cluster Security for Kubernetes version 3.0.47 or older, replace the environment variable name ROX_LANGUAGE_VULNS with LANGUAGE_VULNS.

12.7. Additional resources

Chapter 13. Verifying image signatures

You can use Red Hat Advanced Cluster Security for Kubernetes (RHACS) to ensure the integrity of the container images in your clusters by verifying image signatures against pre-configured keys.

You can create policies to block unsigned images and images that do not have a verified signature. You can also enforce the policy by using the RHACS admission controller to stop unauthorized deployment creation.

Note
  • RHACS only supports Cosign signatures and Cosign Public Keys/Certificates verification. For more information about Cosign, see Cosign overview.
  • For Cosign signature verification, RHACS does not support communication with the transparency log Rekor.
  • You must configure signature integration with at least 1 Cosign verification method for signature verification.
  • For all deployed and watched images:

    • RHACS fetches and verifies the signatures every 4 hours.
    • RHACS verifies the signatures whenever you change or update your signature integration verification data.

13.1. Configuring signature integration

Before performing image signature verification, you must first create a signature integration in RHACS.

A signature integration can be configured with multiple verification methods. The following verification methods are supported:

  • Cosign public keys
  • Cosign certificates

13.1.1. Configuring Cosign public keys

Prerequisites

  • You must already have a PEM-encoded Cosign public key. For more information about Cosign, see Cosign overview.

Procedure

  1. In the RHACS portal, select Platform ConfigurationIntegrations.
  2. Scroll to Signature Integrations and click Signature.
  3. Click New integration.
  4. Enter a name for the Integration name.
  5. Click Cosign public KeysAdd a new public key.
  6. Enter the Public key name.
  7. For the Public key value field, enter the PEM-encoded public key.
  8. (Optional) You can add more than one key by clicking Add a new public key and entering the details.
  9. Click Save.

13.1.2. Configuring Cosign certificates

Prerequisites

  • You must already have the certificate identity and issuer. Optionally, you also need a PEM-encoded certificate and chain. For more information about Cosign certificates, see Cosign certificate verification

Procedure

  1. In the RHACS portal, select Platform ConfigurationIntegrations.
  2. Scroll to Signature Integrations and click Signature.
  3. Click New integration.
  4. Enter a name for the Integration name.
  5. Click Cosign certificatesAdd a new certificate verification.
  6. Enter the Certificate OIDC Issuer. You can optionally use regular expressions in RE2 Syntax.
  7. Enter the Certificate identity. You can optionally use regular expressions in RE2 Syntax.
  8. (Optional) Enter the Certificate Chain PEM encoded to verify certificates. If no chain is provided, certificates are verified against the Fulcio root.
  9. (Optional) Enter the Certificate PEM encoded to verify the signature.
  10. (Optional) You can add more than one certificate verification by clicking Add a new certificate verification and entering the details.
  11. Click Save.

13.2. Using signature verification in a policy

When creating custom security policies, you can use the Trusted image signers policy criteria to verify image signatures.

Prerequisites

  • You must have already configured a signature integration with at least 1 Cosign public key.

Procedure

  1. When creating or editing a policy, drag the Not verified by trusted image signers policy criteria in the policy field drop area for the Policy criteria section.
  2. Click Select.
  3. Select the trusted image signers from the list and click Save.

13.3. Enforcing signature verification

To prevent the users from using unsigned images, you can enforce signature verification by using the RHACS admission controller. You must first enable the Contact Image Scanners feature in your cluster configuration settings. Then, while creating a security policy to enforce signature verification, you can use the Inform and enforce option.

For more information, see Enabling admission controller enforcement.

Chapter 14. Managing vulnerabilities

14.1. Vulnerability management overview

Security vulnerabilities in your environment might be exploited by an attacker to perform unauthorized actions such as carrying out a denial of service attack, executing remote code, or gaining unauthorized access to sensitive data. Therefore, the management of vulnerabilities is a foundational step towards a successful Kubernetes security program.

14.1.1. Vulnerability management process

Vulnerability management is a continuous process to identify and remediate vulnerabilities. Red Hat Advanced Cluster Security for Kubernetes helps you to facilitate a vulnerability management process.

A successful vulnerability management program often includes the following critical tasks:

  • Performing asset assessment
  • Prioritizing the vulnerabilities
  • Assessing the exposure
  • Taking action
  • Continuously reassessing assets

Red Hat Advanced Cluster Security for Kubernetes helps organizations to perform continuous assessments on their OpenShift Container Platform and Kubernetes clusters. It provides organizations with the contextual information they need to prioritize and act on vulnerabilities in their environment more effectively.

14.1.1.1. Performing asset assessment

Performing an assessment of an organization’s assets involve the following actions:

  • Identifying the assets in your environment
  • Scanning these assets to identify known vulnerabilities
  • Reporting on the vulnerabilities in your environment to impacted stakeholders

When you install Red Hat Advanced Cluster Security for Kubernetes on your Kubernetes or OpenShift Container Platform cluster, it first aggregates the assets running inside of your cluster to help you identify those assets. RHACS allows organizations to perform continuous assessments on their OpenShift Container Platform and Kubernetes clusters. RHACS provides organizations with the contextual information to prioritize and act on vulnerabilities in their environment more effectively.

Important assets that should be monitored by the organization’s vulnerability management process using RHACS include:

  • Components: Components are software packages that may be used as part of an image or run on a node. Components are the lowest level where vulnerabilities are present. Therefore, organizations must upgrade, modify or remove software components in some way to remediate vulnerabilities.
  • Images: A collection of software components and code that create an environment to run an executable portion of code. Images are where you upgrade components to fix vulnerabilities.
  • Nodes: A server used to manage and run applications using OpenShift or Kubernetes and the components that make up the OpenShift Container Platform or Kubernetes service.

RHACS groups these assets into the following structures:

  • Deployment: A definition of an application in Kubernetes that may run pods with containers based on one or many images.
  • Namespace: A grouping of resources such as Deployments that support and isolate an application.
  • Cluster: A group of nodes used to run applications using OpenShift or Kubernetes.

RHACS scans the assets for known vulnerabilities and uses the Common Vulnerabilities and Exposures (CVE) data to assess the impact of a known vulnerability.

14.1.1.2. Prioritizing the vulnerabilities

Answer the following questions to prioritize the vulnerabilities in your environment for action and investigation:

  • How important is an affected asset for your organization?
  • How severe does a vulnerability need to be for investigation?
  • Can the vulnerability be fixed by a patch for the affected software component?
  • Does the existence of the vulnerability violate any of your organization’s security policies?

The answers to these questions help security and development teams decide if they want to gauge the exposure of a vulnerability.

Red Hat Advanced Cluster Security for Kubernetes provides you the means to facilitate the prioritization of the vulnerabilities in your applications and components.

14.1.1.3. Assessing the exposure

To assess your exposure to a vulnerability, answer the following questions:

  • Is your application impacted by a vulnerability?
  • Is the vulnerability mitigated by some other factor?
  • Are there any known threats that could lead to the exploitation of this vulnerability?
  • Are you using the software package which has the vulnerability?
  • Is spending time on a specific vulnerability and the software package worth it?

Take some of the following actions based on your assessment:

  • Consider marking the vulnerability as a false positive if you determine that there is no exposure or that the vulnerability does not apply in your environment.
  • Consider if you would prefer to remediate, mitigate or accept the risk if you are exposed.
  • Consider if you want to remove or change the software package to reduce your attack surface.
14.1.1.4. Taking action

Once you have decided to take action on a vulnerability, you can take one of the following actions:

  • Remediate the vulnerability
  • Mitigate and accept the risk
  • Accept the risk
  • Mark the vulnerability as a false positive

You can remediate vulnerabilities by performing one of the following actions:

  • Remove a software package
  • Update a software package to a non-vulnerable version

14.2. Viewing and addressing vulnerabilities

Common vulnerability management tasks involve identifying and prioritizing vulnerabilities, remedying them, and monitoring for new threats.

14.2.1. Viewing vulnerabilities

Historically, RHACS provided a view of vulnerabilities discovered in your system in the vulnerability management dashboard. The dashboard is deprecated in RHACS 4.5 and will be removed in a future release. For more information about the dashboard, see Using the vulnerability management dashboard.

The Vulnerability ManagementWorkload CVEs page provides information about vulnerabilities in applications running on clusters in your system. You can view vulnerability information across images and deployments. The Workload CVEs page provides advanced filtering capabilities, including the ability to view images and deployments with vulnerabilities and filter by image, deployment, namespace, cluster, CVE, component, and component source.

14.2.2. Viewing workload CVEs

The Vulnerability ManagementWorkload CVEs page provides information about vulnerabilities in applications running on clusters in your system. You can view vulnerability information across images and deployments. The Workload CVEs page provides more advanced filtering capabilities than the dashboard, including the ability to view images and deployments with vulnerabilities and filter by image, deployment, namespace, cluster, CVE, component, and component source.

Procedure

  1. To show all CVEs across all images, select Image vulnerabilities from the View image vulnerabilities list.
  2. From the View image vulnerabilities list, select how you want to view the images. The following options are provided:

    • Image vulnerabilities: Displays images and deployments in which RHACS has discovered CVEs.
    • Images without vulnerabilities: Displays images that meet at least one of the following conditions:

      • Images that do not have CVEs
      • Images that report a scanner error that may result in a false negative of no CVEs

        Note

        An image that actually contains vulnerabilities can appear in this list inadvertently. For example, if Scanner was able to scan the image and it is known to RHACS, but the scan was not successfully completed, vulnerabilities cannot be detected. This scenario occurs if an image has an operating system that is not supported by the RHACS scanner. Scan errors are displayed when you hover over an image in the image list or click the image name for more information.

  3. To filter CVEs by entity, select the appropriate filters and attributes.

    To select multiple entities and attributes, click the right arrow icon to add another criteria. Depending on your choices, enter the appropriate information such as text, or select a date or object.

    The filter entities and attributes are listed in the following table.

    Table 14.1. CVE filtering
    EntityAttributes

    Image

    • Name: The name of the image.
    • Operating system: The operating system of the image.
    • Tag: The tag for the image.
    • Label: The label for the image.
    • Registry: The registry where the image is located.

    CVE

    • Name: The name of the CVE.
    • Discovered time: The date when RHACS discovered the CVE.
    • CVSS: The severity level for the CVE. You can select from the following options for the severity level:

      • is greater than
      • is greater than or equal to
      • is equal to
      • is less than or equal to
      • is less than

    Image Component

    • Name: The name of the image component, for example, activerecord-sql-server-adapter
    • Source:

      • OS
      • Python
      • Java
      • Ruby
      • Node.js
      • Go
      • Dotnet Core Runtime
      • Infrastructure
    • Version: Version of the image component; for example, 3.4.21. You can use this to search for a specific version of a component, for example, in conjunction with a component name.

    Deployment

    • Name: Name of the deployment.
    • Label: Label for the deployment.
    • Annotation: The annotation for the deployment.

    Namespace

    • Name: The name of the namespace.
    • Label: The label for the namespace.
    • Annotation: The annotation for the namespace.

    Cluster

    • Name: The name of the cluster.
    • Label: The label for the cluster.
    • Type: The cluster type, for example, OCP.
    • Platform type: The platform type, for example, OpenShift 4 cluster.
  4. You can select the following options to refine the list of results:

    • Prioritize by namespace view: Displays a list of namespaces sorted according to the risk priority. You can use this view to quickly identify and address the most critical areas. In this view, click <number> deployments in a table row to return to the workload CVE list view, with filters applied to show only deployments, images and CVEs for the selected namespace.
    • Default filters: You can select filters for CVE severity and CVE status that are automatically applied when you visit the Workload CVEs page. These filters only apply to this page, and are applied when you visit the page from another section of the RHACS web portal or from a bookmarked URL. They are saved in the local storage of your browser.
    • CVE severity: You can select one or more levels.
    • CVE status: You can select Fixable or Not fixable.
Note

The Filtered view icon indicates that the displayed results were filtered based on the criteria that you selected. You can click Clear filters to remove all filters, or remove individual filters by clicking on them.

In the list of results, click a CVE, image name, or deployment name to view more information about the item. For example, depending on the item type, you can view the following information:

  • Whether a CVE is fixable
  • Whether an image is active
  • The Dockerfile line in the image that contains the CVE
  • External links to information about the CVE in Red Hat and other CVE databases

Search example

The following graphic shows an example of search criteria for a cluster called staging-secured-cluster to view CVEs of critical and important severity with a fixable status in that cluster.

Workload CVE showing a search on the `staging-secured-cluster` for CVEs with critical and important severity and fixable status

14.2.3. Viewing Node CVEs

You can identify vulnerabilities in your nodes by using RHACS. The vulnerabilities that are identified include the following:

  • Vulnerabilities in core Kubernetes components
  • Vulnerabilities in container runtimes such as Docker, CRI-O, runC, and containerd

For more information about operating systems that RHACS can scan, see "Supported operating systems".

Procedure

  1. In the RHACS portal, click Vulnerability ManagementNode CVEs.
  2. To view the data, do any of the following tasks:

    • To view a list of all the CVEs affecting all of your nodes, select <number> CVEs.
    • To view a list of nodes that contain CVEs, select <number> Nodes.
  3. Optional: To filter CVEs according to entity, select the appropriate filters and attributes. To add more filtering criteria, follow these steps:

    1. Select the entity or attribute from the list.
    2. Depending on your choices, enter the appropriate information such as text, or select a date or object.
    3. Click the right arrow icon.
    4. Optional: Select additional entities and attributes, and then click the right arrow icon to add them. The filter entities and attributes are listed in the following table.

      Table 14.2. CVE filtering
      EntityAttributes

      Node

      • Name: The name of the node.
      • Operating system: The operating system of the node, for example, Red Hat Enterprise Linux (RHEL).
      • Label: The label of the node.
      • Annotation: The annotation for the node.
      • Scan time: The scan date of the node.

      CVE

      • Name: The name of the CVE.
      • Discovered time: The date when RHACS discovered the CVE.
      • CVSS: The severity level for the CVE. You can select from the following options for the severity level:

        • is greater than
        • is greater than or equal to
        • is equal to
        • is less than or equal to
        • is less than

      Node Component

      • Name: The name of the component.
      • Version: The version of the component, for example, 4.15.0-2024. You can use this to search for a specific version of a component, for example, in conjunction with a component name.

      Cluster

      • Name: The name of the cluster.
      • Label: The label for the cluster.
      • Type: The type of cluster, for example, OCP.
      • Platform type: The type of platform, for example, OpenShift 4 cluster.
  4. Optional: To refine the list of results, do any of the following tasks:

    • Click CVE severity, and then select one or more levels.
    • Click CVE status, and then select Fixable or Not fixable.
  5. Optional: To view the details of the node and information about the CVEs according to the CVSS score and fixable CVEs for that node, click a node name in the list of nodes.
14.2.3.1. Disabling identifying vulnerabilities in nodes

Identifying vulnerabilities in nodes is enabled by default. You can disable it from the RHACS portal.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationIntegrations.
  2. Under Image Integrations, select StackRox Scanner.
  3. From the list of scanners, select StackRox Scanner to view its details.
  4. Click Edit.
  5. To use only the image scanner and not the node scanner, click Image Scanner.
  6. Click Save.

Additional resources

14.2.4. Viewing platform CVEs

The platform CVEs page provides information about vulnerabilities in clusters in your system.

Procedure

  1. Click Vulnerability ManagementPlatform CVEs.
  2. You can filter CVEs by entity by selecting the appropriate filters and attributes. You can select multiple entities and attributes by clicking the right arrow icon to add another criteria. Depending on your choices, enter the appropriate information such as text, or select a date or object. The filter entities and attributes are listed in the following table.

    Table 14.3. CVE filtering
    EntityAttributes

    Cluster

    • Name: The name of the cluster.
    • Label: The label for the cluster.
    • Type: The cluster type, for example, OCP.
    • Platform type: The platform type, for example, OpenShift 4 cluster.

    CVE

    • Name: The name of the CVE.
    • Discovered time: The date when RHACS discovered the CVE.
    • CVSS: The severity level for the CVE. You can select from the following options for the severity level:

      • is greater than
      • is greater than or equal to
      • is equal to
      • is less than or equal to
      • is less than
    • Type: The type of CVE:

      • Kubernetes CVE
      • Istio CVE
      • OpenShift CVE
  3. To filter by CVE status, click CVE status and select Fixable or Not fixable.
Note

The Filtered view icon indicates that the displayed results were filtered based on the criteria that you selected. You can click Clear filters to remove all filters, or remove individual filters by clicking on them.

In the list of results, click a CVE to view more information about the item. For example, you can view the following information if it is populated:

  • Documentation for the CVE
  • External links to information about the CVE in Red Hat and other CVE databases
  • Whether the CVE is fixable or unfixable
  • A list of affected clusters

14.2.5. Excluding CVEs

You can exclude or ignore CVEs in RHACS by snoozing node and platform CVEs and deferring or marking node, platform, and image CVEs as false positives. You might want to exclude CVEs if you know that the CVE is a false positive or you have already taken steps to mitigate the CVE. Snoozed CVEs do not appear in vulnerability reports or trigger policy violations.

You can snooze a CVE to ignore it globally for a specified period of time. Snoozing a CVE does not require approval.

Note

Snoozing node and platform CVEs requires that the ROX_VULN_MGMT_LEGACY_SNOOZE environment variable is set to true.

Deferring or marking a CVE as a false positive is done through the exception management workflow. This workflow provides the ability to view pending, approved, and denied deferral and false positive requests. You can scope the CVE exception to a single image, all tags for a single image, or globally for all images.

When approving or denying a request, you must add a comment. A CVE remains in the observed status until the exception request is approved. A pending request for deferral that is denied by another user is still visible in reports, policy violations, and other places in the system, but is indicated by a Pending exception label next to the CVE when visiting Vulnerability ManagementWorkload CVEs.

An approved exception for a deferral or false positive has the following effects:

  • Removes the CVE from the Observed tab in Vulnerability ManagementWorkflow CVEs to either the Deferred or False positive tab
  • Prevents the CVE from triggering policy violations that are related to the CVE
  • Prevents the CVE from showing up in automatically generated vulnerability reports
14.2.5.1. Snoozing platform and node CVEs

You can snooze platform and node CVEs that do not relate to your infrastructure. You can snooze CVEs for 1 day, 1 week, 2 weeks, 1 month, or indefinitely, until you unsnooze them. Snoozing a CVE takes effect immediately and does not require an additional approval step.

Note

The ability to snooze a CVE is not enabled by default in the web portal or in the API. To enable the ability to snooze CVEs, set the runtime environment variable ROX_VULN_MGMT_LEGACY_SNOOZE to true.

Procedure

  1. In the RHACS portal, do any of the following tasks:

    • To view platform CVEs, click Vulnerability ManagementPlatform CVEs.
    • To view node CVEs, click Vulnerability ManagementNode CVEs.
  2. Select one or more CVEs.
  3. Select the appropriate method to snooze the CVE:

    • If you selected a single CVE, click the overflow menu, kebab , and then select Snooze CVE.
    • If you selected multiple CVEs, click Bulk actionsSnooze CVEs.
  4. Select the duration of time to snooze.
  5. Click Snooze CVEs.

    You receive a confirmation that you have requested to snooze the CVEs.

14.2.5.2. Unsnoozing platform and node CVEs

You can unsnooze platform and node CVEs that you have previously snoozed.

Note

The ability to snooze a CVE is not enabled by default in the web portal or in the API. To enable the ability to snooze CVEs, set the runtime environment variable ROX_VULN_MGMT_LEGACY_SNOOZE to true.

Procedure

  1. In the RHACS portal, do any of the following tasks:

    • To view the list of platform CVEs, click Vulnerability ManagementPlatform CVEs.
    • To view the list of node CVEs, click Vulnerability ManagementNode CVEs.
  2. To view the list of snoozed CVEs, click Show snoozed CVEs in the header view.
  3. Select one or more CVEs from the list of snoozed CVEs.
  4. Select the appropriate method to unsnooze the CVE:

    • If you selected a single CVE, click the overflow menu, kebab , and then select Unsnooze CVE.
    • If you selected multiple CVEs, click Bulk actionsUnsnooze CVEs.
  5. Click Unsnooze CVEs again.

    You receive a confirmation that you have requested to unsnooze the CVEs.

14.2.5.3. Viewing snoozed CVEs

You can view a list of platform and node CVEs that have been snoozed.

Note

The ability to snooze a CVE is not enabled by default in the web portal or in the API. To enable the ability to snooze CVEs, set the runtime environment variable ROX_VULN_MGMT_LEGACY_SNOOZE to true.

Procedure

  1. In the RHACS portal, do any of the following tasks:

    • To view the list of platform CVEs, click Vulnerability ManagementPlatform CVEs.
    • To view the list of node CVEs, click Vulnerability ManagementNode CVEs.
  2. Click Show snoozed CVEs to view the list.
14.2.5.4. Marking a vulnerability as a false positive globally

You can create an exception for a vulnerability by marking it as a false positive globally, or across all images. You must get requests to mark a vulnerability as a false positive approved in the exception management workflow.

Prerequisites

  • You have the write permission for the VulnerabilityManagementRequests resource.

Procedure

  1. In the RHACS portal, click Vulnerability ManagementWorkload CVEs.
  2. Choose the appropriate method to mark the CVEs:

    • If you want to mark a single CVE, perform the following steps:

      1. Find the row which contains the CVE that you want to take action on.
      2. Click the overflow menu, kebab , for the CVE that you identified, and then select Mark as false positive.
    • If you want to mark multiple CVEs, perform the following steps:

      1. Select each CVE.
      2. From the Bulk actions drop-down list, select Mark as false positives.
  3. Enter a rationale for requesting the exception.
  4. Optional: To review the CVEs that are included in the exception request, click CVE selections.
  5. Click Submit request.

    You receive a confirmation that you have requested an exception.

  6. Optional: To copy the approval link and share it with your organization’s exception approver, click the copy icon.
  7. Click Close.
14.2.5.5. Marking a vulnerability as a false positive for an image or image tag

To create an exception for a vulnerability, you can mark it as a false positive for a single image, or across all tags associated with an image. You must get requests to mark a vulnerability as a false positive approved in the exception management workflow.

Prerequisites

  • You have the write permission for the VulnerabilityManagementRequests resource.

Procedure

  1. In the RHACS portal, click Vulnerability ManagementWorkload CVEs.
  2. To view the list of images, click <number> Images.
  3. Find the row that lists the image that you want to mark as a false positive, and click the image name.
  4. Choose the appropriate method to mark the CVEs:

    • If you want to mark a single CVE, perform the following steps:

      1. Find the row which contains the CVE that you want to take action on.
      2. Click the overflow menu, kebab , for the CVE that you identified, and then select Mark as false positive.
    • If you want to mark multiple CVEs, perform the following steps:

      1. Select each CVE.
      2. From the Bulk actions drop-down list, select Mark as false positives.
  5. Select the scope. You can select either all tags associated with the image or only the image.
  6. Enter a rationale for requesting the exception.
  7. Optional: To review the CVEs that are included in the exception request, click CVE selections.
  8. Click Submit request.

    You receive a confirmation that you have requested an exception.

  9. Optional: To copy the approval link and share it with your organization’s exception approver, click the copy icon.
  10. Click Close.
14.2.5.6. Viewing deferred and false positive CVEs

You can view the CVEs that have been deferred or marked as false positives by using the Workload CVEs page.

Procedure

  1. To see CVEs that have been deferred or marked as false positives, with the exceptions approved by an approver, click Vulnerability ManagementWorkload CVEs. Complete any of the following actions:

    • To see CVEs that have been deferred, click the Deferred tab.
    • To see CVEs that have been marked as false positives, click the False positives tab.

      Note

      To approve, deny, or change deferred or false positive CVEs, click Vulnerability ManagementException Management.

  2. Optional: To view additional information about the deferral or false positive, click View in the Request details column. The Exception Management page is displayed.
14.2.5.7. Deferring CVEs

You can accept risk with or without mitigation and defer CVEs. You must get deferral requests approved in the exception management workflow.

Prerequisites

  • You have write permission for the VulnerabilityManagementRequests resource.

Procedure

  1. In the RHACS portal, click Vulnerability ManagementWorkload CVEs.
  2. Choose the appropriate method to defer a CVE:

    • If you want to defer a single CVE, perfom the following steps:

      1. Find the row which contains the CVE that you want to mark as a false positive.
      2. Click the overflow menu, kebab , for the CVE that you identified, and then click Defer CVE.
    • If you want to defer multiple CVEs, perform the following steps:

      1. Select each CVE.
      2. Click Bulk actionsDefer CVEs.
  3. Select the time period for the deferral.
  4. Enter a rationale for requesting the exception.
  5. Optional: To review the CVEs that are included in the exception menu, click CVE selections.
  6. Click Submit request.

    You receive a confirmation that you have requested a deferral.

  7. Optional: To copy the approval link to share it with your organization’s exception approver, click the copy icon.
  8. Click Close.
14.2.5.7.1. Configuring vulnerability exception expiration periods

You can configure the time periods available for vulnerability management exceptions. These options are available when users request to defer a CVE.

Prerequisites

  • You have write permission for the VulnerabilityManagementRequests resource.

Procedure

  1. In the RHACS portal, go to Platform ConfigurationException Configuration.
  2. You can configure expiration times that users can select when they request to defer a CVE. Enabling a time period makes it available to users and disabling it removes it from the user interface.
14.2.5.8. Reviewing and managing an exception request to defer or mark a CVE as false positive

You can review, update, approve, or deny an exception requests for deferring and marking CVEs as false positives.

Prerequisites

  • You have the write permission for the VulnerabilityManagementRequests resource.

Procedure

  1. To view the list of pending requests, do any of the following tasks:

    • Paste the approval link into your browser.
    • Click Vulnerability ManagementException Management, and then click the request name in the Pending requests tab.
  2. Review the scope of the vulnerability and decide whether or not to approve it.
  3. Choose the appropriate option to manage a pending request:

    • If you want to deny the request and return the CVE to observed status, click Deny request.

      Enter a rationale for the denial, and click Deny.

    • If you want to approve the request, click Approve request.

      Enter a rationale for the approval, and click Approve.

  4. To cancel a request that you have created and return the CVE to observed status, click Cancel request. You can only cancel requests that you have created.
  5. To update the deferral time period or rationale for a request that you have created, click Update request. You can only update requests that you have created.

    After you make changes, click Submit request.

    You receive a confirmation that you have submitted a request.

14.2.6. Identifying Dockerfile lines in images that introduced components with CVEs

You can identify specific Dockerfile lines in an image that introduced components with CVEs.

Procedure

To view a problematic line:

  1. In the RHACS portal, click Vulnerability ManagementWorkload CVEs.
  2. Click the tab to view the type of CVEs. The following tabs are available:

    • Observed
    • Deferred
    • False positives
  3. In the list of CVEs, click the CVE name to open the page containing the CVE details. The Affected components column lists the components that include the CVE.
  4. Expand the CVE to display additional information, including the Dockerfile line that introduced the component.

14.2.7. Finding a new component version

The following procedure finds a new component version to upgrade to.

Procedure

  1. In the RHACS portal, click Vulnerability ManagementWorkload CVEs.
  2. Click <number> Images and select an image.
  3. To view additional information, locate the CVE and click the expand icon.

    The additional information includes the component that the CVE is in and the version in which the CVE is fixed, if it is fixable.

  4. Update your image to a later version.

14.2.8. Exporting workload vulnerabilities by using the API

You can export workload vulnerabilities in Red Hat Advanced Cluster Security for Kubernetes by using the API.

For these examples, workloads are composed of deployments and their associated images. The export uses the /v1/export/vuln-mgmt/workloads streaming API. It allows the combined export of deployments and images. The images payload contains the full vulnerability information. The output is streamed and has the following schema:

{"result": {"deployment": {...}, "images": [...]}}
...
{"result": {"deployment": {...}, "images": [...]}}

The following examples assume that these environment variables have been set:

  • ROX_API_TOKEN: API token with view permissions for the Deployment and Image resources
  • ROX_ENDPOINT: Endpoint under which Central’s API is available
  • To export all workloads, enter the following command:

    $ curl -H "Authorization: Bearer $ROX_API_TOKEN" $ROX_ENDPOINT/v1/export/vuln-mgmt/workloads
  • To export all workloads with a query timeout of 60 seconds, enter the following command:

    $ curl -H "Authorization: Bearer $ROX_API_TOKEN" $ROX_ENDPOINT/v1/export/vuln-mgmt/workloads?timeout=60
  • To export all workloads matching the query Deployment:app Namespace:default, enter the following command:

    $ curl -H "Authorization: Bearer $ROX_API_TOKEN" $ROX_ENDPOINT/v1/export/vuln-mgmt/workloads?query=Deployment%3Aapp%2BNamespace%3Adefault

Additional resources

14.2.8.1. Scanning inactive images

Red Hat Advanced Cluster Security for Kubernetes (RHACS) scans all active (deployed) images every 4 hours and updates the image scan results to reflect the latest vulnerability definitions.

You can also configure RHACS to scan inactive (not deployed) images automatically.

Procedure

  1. In the RHACS portal, click Vulnerability ManagementWorkload CVEs.
  2. Click Manage watched images.
  3. In the Image name field, enter the fully-qualified image name that begins with the registry and ends with the image tag, for example, docker.io/library/nginx:latest.
  4. Click Add image to watch list.
  5. Optional: To remove a watched image, locate the image in the Manage watched images window, and click Remove watch.

    Important

    In the RHACS portal, click Platform ConfigurationSystem Configuration to view the data retention configuration.

    All the data related to the image removed from the watched image list continues to appear in the RHACS portal for the number of days mentioned on the System Configuration page and is only removed after that period is over.

  6. Click Close to return to the Workload CVEs page.

14.3. Vulnerability reporting

You can create and download an on-demand image vulnerability report from the Vulnerability ManagementVulnerability Reporting menu in the RHACS web portal. This report contains a comprehensive list of common vulnerabilities and exposures in images and deployments, referred to as workload CVEs in RHACS.

To share this report with auditors or internal stakeholders, you can schedule emails in RHACS or download the report and share it by using other methods.

14.3.1. Reporting vulnerabilities to teams

As organizations must constantly reassess and report on their vulnerabilities, some organizations find it helpful to have scheduled communications to key stakeholders to help in the vulnerability management process.

You can use Red Hat Advanced Cluster Security for Kubernetes to schedule these reoccurring communications through e-mail. These communications should be scoped to the most relevant information that the key stakeholders need.

For sending these communications, you must consider the following questions:

  • What schedule would have the most impact when communicating with the stakeholders?
  • Who is the audience?
  • Should you only send specific severity vulnerabilities in your report?
  • Should you only send fixable vulnerabilities in your report?

14.3.2. Creating vulnerability management report configurations

RHACS guides you through the process of creating a vulnerability management report configuration. This configuration determines the information that will be included in a report job that runs at a scheduled time or that you run on demand.

Procedure

  1. In the RHACS portal, click Vulnerability ManagementVulnerability Reporting.
  2. Click Create report.
  3. Enter a name for your report configuration in the Report name field.
  4. Optional: Enter text describing the report configuration in the Report description field.
  5. In the CVE severity field, select the severity of common vulnerabilities and exposures (CVEs) that you want to include in the report configuration.
  6. Select the CVE status. You can select Fixable, Unfixable, or both.
  7. In the Image type field, select whether you want to include CVEs from deployed images, watched images, or both.
  8. In the CVEs discovered since field, select the time period for which you want CVEs to be included in the report configuration.
  9. In the Configure collection included field, you must configure at least one collection. Complete any of the following actions:

    • Select an existing collection to include. To view the collection information, edit the collection, and get a preview of collection results, click View. When viewing the collection, entering text in the field searches for collections matching that text string.
    • Click Create collection to create a new collection.

      Note

      For more information about collections, see "Creating and using deployment collections" in the "Additional resources" section.

  10. Click Next to configure the delivery destinations and optionally set up a schedule for delivery.
14.3.2.1. Configuring delivery destinations and scheduling

Configuring destinations and delivery schedules for vulnerability reports is optional, unless on the previous page, you selected the option to include CVEs that were discovered since the last scheduled report. If you selected that option, configuring destinations and delivery schedules for vulnerability reports is required.

Procedure

  1. To configure destinations for delivery, in the Configure delivery destinations section, you can add a delivery destination and set up a schedule for reporting.
  2. To email reports, you must configure at least one email notifier. Select an existing notifier or create a new email notifier to send your report by email. For more information about creating an email notifier, see "Configuring the email plugin" in the "Additional resources" section.

    When you select a notifier, the email addresses configured in the notifier as Default recipients appear in the Distribution list field. You can add additional email addresses that are separated by a comma.

  3. A default email template is automatically applied. To edit this default template, perform the following steps:

    1. Click the edit icon and enter a customized subject and email body in the Edit tab.
    2. Click the Preview tab to see your proposed template.
    3. Click Apply to save your changes to the template.

      Note

      When reviewing the report jobs for a specific report, you can see whether the default template or a customized template was used when creating the report.

  4. In the Configure schedule section, select the frequency and day of the week for the report.
  5. Click Next to review your vulnerability report configuration and finish creating it.
14.3.2.2. Reviewing and creating the report configuration

You can review the details of your vulnerability report configuration before creating it.

Procedure

  1. In the Review and create section, you can review the report configuration parameters, delivery destination, email template that is used if you selected email delivery, delivery schedule, and report format. To make any changes, click Back to go to the previous section and edit the fields that you want to change.
  2. Click Create to create the report configuration and save it.

14.3.3. Vulnerability report permissions

The ability to create, view, and download reports depends on the access control settings, or roles and permission sets, for your user account.

For example, you can only view, create, and download reports for data that your user account has permission to access. In addition, the following restrictions apply:

  • You can only download reports that you have generated; you cannot download reports generated by other users.
  • Report permissions are restricted depending on the access settings for user accounts. If the access settings for your account change, old reports do not reflect the change. For example, if you are given new permissions and want to view vulnerability data that is now allowed by those permissions, you must create a new vulnerability report.

14.3.4. Editing vulnerability report configurations

You can edit existing vulnerability report configurations from the list of report configurations, or by selecting an individual report configuration first.

Procedure

  1. In the RHACS web portal, click Vulnerability ManagementVulnerability Reporting.
  2. To edit an existing vulnerability report configuration, complete any of the following actions:

    • Locate the report configuration that you want to edit in the list of report configurations. Click the overflow menu, kebab , and then select Edit report.
    • Click the report configuration name in the list of report configurations. Then, click Actions and select Edit report.
  3. Make changes to the report configuration and save.

14.3.5. Downloading vulnerability reports

You can generate an on-demand vulnerability report and then download it.

Note

You can only download reports that you have generated; you cannot download reports generated by other users.

Procedure

  1. In the RHACS web portal, click Vulnerability ManagementVulnerability Reporting.
  2. In the list of report configurations, locate the report configuration that you want to use to create the downloadable report.
  3. Generate the vulnerability report by using one of the following methods:

    • To generate the report from the list:

      1. Click the overflow menu, kebab , and then select Generate download. The My active job status column displays the status of your report creation. After the Processing status goes away, you can download the report.
    • To generate the report from the report window:

      1. Click the report configuration name to open the configuration detail window.
      2. Click Actions and select Generate download.
  4. To download the report, if you are viewing the list of report configurations, click the report configuration name to open it.
  5. Click All report jobs from the menu on the header.
  6. If the report is completed, click the Ready for download link in the Status column. The report is in .csv format and is compressed into a .zip file for download.

14.3.6. Sending vulnerability reports on-demand

You can send vulnerability reports immediately, rather than waiting for the scheduled send time.

Procedure

  1. In the RHACS web portal, click Vulnerability ManagementVulnerability Reporting.
  2. In the list of report configurations, locate the report configuration for the report that you want to send.
  3. Click the overflow menu, kebab , and then select Send report now.

14.3.7. Cloning vulnerability report configurations

You can make copies of vulnerability report configurations by cloning them. This is useful when you want to reuse report configurations with minor changes, such as reporting vulnerabilities in different deployments or namespaces.

Procedure

  1. In the RHACS web portal, click Vulnerability ManagementVulnerability Reporting.
  2. Locate the report configuration that you want to clone in the list of report configurations.
  3. Click Clone report.
  4. Make any changes that you want to the report parameters and delivery destinations.
  5. Click Create.

14.3.8. Deleting vulnerability report configurations

Deleting a report configuration deletes the configuration and any reports that were previously run using this configuration.

Procedure

  1. In the RHACS web portal, click Vulnerability ManagementVulnerability Reporting.
  2. Locate the report configuration that you want to delete in the list of reports.
  3. Click the overflow menu, kebab , and then select Delete report.

14.3.9. Configuring vulnerability management report job retention settings

You can configure settings that determine when vulnerability report job requests expire and other retention settings for report jobs.

Note

These settings do not affect the following vulnerability report jobs:

  • Jobs in the WAITING or PREPARING state (unfinished jobs)
  • The last successful scheduled report job
  • The last successful on-demand emailed report job
  • The last successful downloadable report job
  • Downloadable report jobs for which the report file has not been deleted by either manual deletion or by configuring the downloadable report pruning settings

Procedure

  1. In the RHACS web portal, go to Platform ConfigurationSystem Configuration. You can configure the following settings for vulnerability report jobs:

    • Vulnerability report run history retention: The number of days that a record is kept of vulnerability report jobs that have been run. This setting controls how many days that report jobs are listed in the All report jobs tab under Vulnerability ManagementVulnerability Reporting when a report configuration is selected. The entire report history after the exclusion date is deleted, with the exception of the following jobs:

      • Unfinished jobs.
      • Jobs for which prepared downloadable reports still exist in the system.
      • The last successful report job for each job type (scheduled email, on-demand email, or download). This ensures users have information about the last run job for each type.
    • Prepared downloadable vulnerability reports retention days: The number of days that prepared, on-demand downloadable vulnerability report jobs are available for download on the All report jobs tab under Vulnerability ManagementVulnerability Reporting when a report configuration is selected.
    • Prepared downloadable vulnerability reports limit: The limit, in MB, of space allocated to prepared downloadable vulnerability report jobs. After the limit is reached, the oldest report job in the download queue is removed.
  2. To change these values, click Edit, make your changes, and then click Save.

14.3.10. Additional resources

14.4. Using the vulnerability management dashboard (deprecated)

Historically, RHACS has provided a view of vulnerabilities discovered in your system in the vulnerability management dashboard. With the dashboard, you can view vulnerabilities by image, node, or platform. You can also view vulnerabilities by clusters, namespaces, deployments, node components, and image components. The dashboard is deprecated in RHACS 4.5 and will be removed in a future release.

Important

To perform actions on vulnerabilities, such as view additional information about a vulnerability, defer a vulnerability, or mark a vulnerability as a false positive, click Vulnerability ManagementWorkload CVEs. To review requests for deferring and marking CVEs as false positives, click Vulnerability ManagementException Management.

14.4.1. Viewing application vulnerabilities by using the dashboard

You can view application vulnerabilities in Red Hat Advanced Cluster Security for Kubernetes by using the dashboard.

Procedure

  1. In the RHACS portal, go to Vulnerability ManagementDashboard.
  2. On the Dashboard view header, select Application & InfrastructureNamespaces or Deployments.
  3. From the list, search for and select the Namespace or Deployment you want to review.
  4. To get more information about the application, select an entity from Related entities on the right.

14.4.2. Viewing image vulnerabilities by using the dashboard

You can view image vulnerabilities in Red Hat Advanced Cluster Security for Kubernetes by using the dashboard.

Procedure

  1. In the RHACS portal, go to Vulnerability ManagementDashboard.
  2. On the Dashboard view header, select <number> Images.
  3. From the list of images, select the image you want to investigate. You can also filter the list by performing one of the following steps:

    1. Enter Image in the search bar and then select the Image attribute.
    2. Enter the image name in the search bar.
  4. In the image details view, review the listed CVEs and prioritize taking action to address the impacted components.
  5. Select Components from Related entities on the right to get more information about all the components that are impacted by the selected image. Or select Components from the Affected components column under the Image findings section for a list of components affected by specific CVEs.

14.4.3. Viewing cluster vulnerabilities by using the dashboard

You can view vulnerabilities in clusters by using Red Hat Advanced Cluster Security for Kubernetes.

Procedure

  1. In the RHACS portal, go to Vulnerability ManagementDashboard.
  2. On the Dashboard view header, select Application & InfrastructureClusters.
  3. From the list of clusters, select the cluster you want to investigate.
  4. Review the cluster’s vulnerabilities and prioritize taking action on the impacted nodes on the cluster.

14.4.4. Viewing node vulnerabilities by using the dashboard

You can view vulnerabilities in specific nodes by using Red Hat Advanced Cluster Security for Kubernetes.

Procedure

  1. In the RHACS portal, go to Vulnerability ManagementDashboard.
  2. On the Dashboard view header, select Nodes.
  3. From the list of nodes, select the node you want to investigate.
  4. Review vulnerabilities for the selected node and prioritize taking action.
  5. To get more information about the affected components in a node, select Components from Related entities on the right.

14.4.5. Finding the most vulnerable image components by using the dashboard

Use the Vulnerability Management view for identifying highly vulnerable image components.

Procedure

  1. Go to the RHACS portal and click Vulnerability ManagementDashboard from the navigation menu.
  2. From the Vulnerability Management view header, select Application & InfrastructureImage Components.
  3. In the Image Components view, select the Image CVEs column header to arrange the components in descending order (highest first) based on the CVEs count.

14.4.6. Viewing details only for fixable CVEs by using the dashboard

Use the Vulnerability Management view to filter and show only the fixable CVEs.

Procedure

  1. In the RHACS portal, go to Vulnerability ManagementDashboard.
  2. From the Vulnerability Management view header, under Filter CVEs, click Fixable.

14.4.7. Identifying the operating system of the base image by using the dashboard

Use the Vulnerability Management view to identify the operating system of the base image.

Procedure

  1. Go to the RHACS portal and click Vulnerability ManagementDashboard from the navigation menu.
  2. From the Vulnerability Management view header, select Images.
  3. View the base operating system (OS) and OS version for all images under the Image OS column.
  4. Select an image to view its details. The base operating system is also available under the Image SummaryDetails and Metadata section.
Note

Red Hat Advanced Cluster Security for Kubernetes lists the Image OS as unknown when either:

  • The operating system information is not available, or
  • If the image scanner in use does not provide this information.

Docker Trusted Registry, Google Container Registry, and Anchore do not provide this information.

14.4.8. Identifying top risky objects by using the dashboard

Use the Vulnerability Management view for identifying the top risky objects in your environment. The Top Risky widget displays information about the top risky images, deployments, clusters, and namespaces in your environment. The risk is determined based on the number of vulnerabilities and their CVSS scores.

Procedure

  1. Go to the RHACS portal and click Vulnerability ManagementDashboard from the navigation menu.
  2. Select the Top Risky widget header to choose between riskiest images, deployments, clusters, and namespaces.

    The small circles on the chart represent the chosen object (image, deployment, cluster, namespace). Hover over the circles to see an overview of the object they represent. And select a circle to view detailed information about the selected object, its related entities, and the connections between them.

    For example, if you are viewing Top Risky Deployments by CVE Count and CVSS score, each circle on the chart represents a deployment.

    • When you hover over a deployment, you see an overview of the deployment, which includes deployment name, name of the cluster and namespace, severity, risk priority, CVSS, and CVE count (including fixable).
    • When you select a deployment, the Deployment view opens for the selected deployment. The Deployment view shows in-depth details of the deployment and includes information about policy violations, common vulnerabilities, CVEs, and riskiest images for that deployment.
  3. Select View All on the widget header to view all objects of the chosen type. For example, if you chose Top Risky Deployments by CVE Count and CVSS score, you can select View All to view detailed information about all deployments in your infrastructure.

14.4.9. Identifying top riskiest images and components by using the dashboard

Similar to the Top Risky, the Top Riskiest widget lists the names of the top riskiest images and components. This widget also includes the total number of CVEs and the number of fixable CVEs in the listed images.

Procedure

  1. Go to the RHACS portal and click Vulnerability Management from the navigation menu.
  2. Select the Top Riskiest Images widget header to choose between the riskiest images and components. If you are viewing Top Riskiest Images:

    • When you hover over an image in the list, you see an overview of the image, which includes image name, scan time, and the number of CVEs along with severity (critical, high, medium, and low).
    • When you select an image, the Image view opens for the selected image. The Image view shows in-depth details of the image and includes information about CVEs by CVSS score, top riskiest components, fixable CVEs, and Dockerfile for the image.
  3. Select View All on the widget header to view all objects of the chosen type. For example, if you chose Top Riskiest Components, you can select View All to view detailed information about all components in your infrastructure.

14.4.10. Viewing the Dockerfile for an image by using the dashboard

Use the Vulnerability Management view to find the root cause of vulnerabilities in an image. You can view the Dockerfile and find exactly which command in the Dockerfile introduced the vulnerabilities and all components that are associated with that single command.

The Dockerfile section shows information about:

  • All the layers in the Dockerfile
  • The instructions and their value for each layer
  • The components included in each layer
  • The number of CVEs in components for each layer

When there are components introduced by a specific layer, you can select the expand icon to see a summary of its components. If there are any CVEs in those components, you can select the expand icon for an individual component to get more details about the CVEs affecting that component.

Procedure

  1. In the RHACS portal, go to Vulnerability ManagementDashboard.
  2. Select an image from either the Top Riskiest Images widget or click the Images button at the top of the dashboard and select an image.
  3. In the Image details view, next to Dockerfile, select the expand icon to see a summary of instructions, values, creation date, and components.
  4. Select the expand icon for an individual component to view more information.

14.4.11. Identifying the container image layer that introduces vulnerabilities by using the dashboard

You can use the Vulnerability Management dashboard to identify vulnerable components and the image layer they appear in.

Procedure

  1. Go to the RHACS portal and click Vulnerability ManagementDashboard from the navigation menu.
  2. Select an image from either the Top Riskiest Images widget or click the Images button at the top of the dashboard and select an image.
  3. In the Image details view, next to Dockerfile, select the expand icon to see a summary of image components.
  4. Select the expand icon for specific components to get more details about the CVEs affecting the selected component.

14.4.12. Viewing recently detected vulnerabilities by using the dashboard

The Recently Detected Vulnerabilities widget on the Vulnerability ManagementDashboard view shows a list of recently discovered vulnerabilities in your scanned images, based on the scan time and CVSS score. It also includes information about the number of images affected by the CVE and its impact (percentage) on your environment.

  • When you hover over a CVE in the list, you see an overview of the CVE, which includes scan time, CVSS score, description, impact, and whether it’s scored by using CVSS v2 or v3.
  • When you select a CVE, the CVE details view opens for the selected CVE. The CVE details view shows in-depth details of the CVE and the components, images, and deployments and deployments in which it appears.
  • Select View All on the Recently Detected Vulnerabilities widget header to view a list of all the CVEs in your infrastructure. You can also filter the list of CVEs.

14.4.13. Viewing the most common vulnerabilities by using the dashboard

The Most Common Vulnerabilities widget on the Vulnerability ManagementDashboard view shows a list of vulnerabilities that affect the largest number of deployments and images arranged by their CVSS score.

  • When you hover over a CVE in the list, you see an overview of the CVE which includes, scan time, CVSS score, description, impact, and whether it is scored by using CVSS v2 or v3.
  • When you select a CVE, the CVE details view opens for the selected CVE. The CVE details view shows in-depth details of the CVE and the components, images, and deployments and deployments in which it appears.
  • Select View All on the Most Common Vulnerabilities widget header to view a list of all the CVEs in your infrastructure. You can also filter the list of CVEs. To export the CVEs as a CSV file, select ExportDownload CVES as CSV.

14.4.14. Finding clusters with most Kubernetes and Istio vulnerabilities by using the dashboard

You can identify the clusters with most Kubernetes, Red Hat OpenShift, and Istio vulnerabilities (deprecated) in your environment by using the vulnerability management dashboard.

Procedure

  1. In the RHACS portal, click Vulnerability ManagementDashboard. The Clusters with most orchestrator and Istio vulnerabilities widget shows a list of clusters, ranked by the number of Kubernetes, Red Hat OpenShift, and Istio vulnerabilities (deprecated) in each cluster. The cluster on top of the list is the cluster with the highest number of vulnerabilities.
  2. Click on one of the clusters from the list to view details about the cluster. The Cluster view includes:

    • Cluster Summary section, which shows cluster details and metadata, top risky objects (deployments, namespaces, and images), recently detected vulnerabilities, riskiest images, and deployments with the most severe policy violations.
    • Cluster Findings section, which includes a list of failing policies and list of fixable CVEs.
    • Related Entities section, which shows the number of namespaces, deployments, policies, images, components, and CVEs the cluster contains. You can select these entities to view more details.
  3. Click View All on the widget header to view the list of all clusters.

14.4.15. Identifying vulnerabilities in nodes by using the dashboard

You can use the Vulnerability Management view to identify vulnerabilities in your nodes. The identified vulnerabilities include vulnerabilities in core Kubernetes components and container runtimes such as Docker, CRI-O, runC, and containerd. For more information on operating systems that RHACS can scan, see "Supported operating systems".

Procedure

  1. In the RHACS portal, go to Vulnerability ManagementDashboard.
  2. Select Nodes on the header to view a list of all the CVEs affecting your nodes.
  3. Select a node from the list to view details of all CVEs affecting that node.

    1. When you select a node, the Node details panel opens for the selected node. The Node view shows in-depth details of the node and includes information about CVEs by CVSS score and fixable CVEs for that node.
    2. Select View All on the CVEs by CVSS score widget header to view a list of all the CVEs in the selected node. You can also filter the list of CVEs.
    3. To export the fixable CVEs as a CSV file, select Export as CSV under the Node Findings section.

Additional resources

14.4.16. Creating policies to block specific CVEs by using the dashboard

You can create new policies or add specific CVEs to an existing policy from the Vulnerability Management view.

Procedure

  1. Click CVEs from the Vulnerability Management view header.
  2. You can select the checkboxes for one or more CVEs, and then click Add selected CVEs to Policy (add icon) or move the mouse over a CVE in the list, and select the Add icon.
  3. For Policy Name:

    • To add the CVE to an existing policy, select an existing policy from the drop-down list box.
    • To create a new policy, enter the name for the new policy, and select Create <policy_name>.
  4. Select a value for Severity, either Critical, High, Medium, or Low.
  5. Choose the Lifecycle Stage to which your policy is applicable, from Build, or Deploy. You can also select both life-cycle stages.
  6. Enter details about the policy in the Description box.
  7. Turn off the Enable Policy toggle if you want to create the policy but enable it later. The Enable Policy toggle is on by default.
  8. Verify the listed CVEs which are included in this policy.
  9. Click Save Policy.

14.5. Scanning RHCOS node hosts

For OpenShift Container Platform, Red Hat Enterprise Linux CoreOS (RHCOS) is the only supported operating system for control plane. Whereas, for node hosts, OpenShift Container Platform supports both RHCOS and Red Hat Enterprise Linux (RHEL). With Red Hat Advanced Cluster Security for Kubernetes (RHACS), you can scan RHCOS nodes for vulnerabilities and detect potential security threats.

RHACS scans RHCOS RPMs installed on the node host, as part of the RHCOS installation, for any known vulnerabilities.

First, RHACS analyzes and detects RHCOS components. Then it matches vulnerabilities for identified components by using RHEL and OpenShift 4.X Open Vulnerability and Assessment Language (OVAL) v2 security data streams.

Note
  • If you installed RHACS by using the roxctl CLI, you must manually enable the RHCOS node scanning features. When you use Helm or Operator installation methods on OpenShift Container Platform, this feature is enabled by default.

14.5.1. Enabling RHCOS node scanning

If you use OpenShift Container Platform, you can enable scanning of Red Hat Enterprise Linux CoreOS (RHCOS) nodes for vulnerabilities by using Red Hat Advanced Cluster Security for Kubernetes (RHACS).

Prerequisites

Procedure

  1. Run one of the following commands to update the compliance container.

    • For a default compliance container with metrics disabled, run the following command:

      $ oc -n stackrox patch daemonset/collector -p '{"spec":{"template":{"spec":{"containers":[{"name":"compliance","env":[{"name":"ROX_METRICS_PORT","value":"disabled"},{"name":"ROX_NODE_SCANNING_ENDPOINT","value":"127.0.0.1:8444"},{"name":"ROX_NODE_SCANNING_INTERVAL","value":"4h"},{"name":"ROX_NODE_SCANNING_INTERVAL_DEVIATION","value":"24m"},{"name":"ROX_NODE_SCANNING_MAX_INITIAL_WAIT","value":"5m"},{"name":"ROX_RHCOS_NODE_SCANNING","value":"true"},{"name":"ROX_CALL_NODE_INVENTORY_ENABLED","value":"true"}]}]}}}}'
    • For a compliance container with Prometheus metrics enabled, run the following command:

      $ oc -n stackrox patch daemonset/collector -p '{"spec":{"template":{"spec":{"containers":[{"name":"compliance","env":[{"name":"ROX_METRICS_PORT","value":":9091"},{"name":"ROX_NODE_SCANNING_ENDPOINT","value":"127.0.0.1:8444"},{"name":"ROX_NODE_SCANNING_INTERVAL","value":"4h"},{"name":"ROX_NODE_SCANNING_INTERVAL_DEVIATION","value":"24m"},{"name":"ROX_NODE_SCANNING_MAX_INITIAL_WAIT","value":"5m"},{"name":"ROX_RHCOS_NODE_SCANNING","value":"true"},{"name":"ROX_CALL_NODE_INVENTORY_ENABLED","value":"true"}]}]}}}}'
  2. Update the Collector DaemonSet (DS) by taking the following steps:

    1. Add new volume mounts to Collector DS by running the following command:

      $ oc -n stackrox patch daemonset/collector -p '{"spec":{"template":{"spec":{"volumes":[{"name":"tmp-volume","emptyDir":{}},{"name":"cache-volume","emptyDir":{"sizeLimit":"200Mi"}}]}}}}'
    2. Add the new NodeScanner container by running the following command:

      $ oc -n stackrox patch daemonset/collector -p '{"spec":{"template":{"spec":{"containers":[{"command":["/scanner","--nodeinventory","--config=",""],"env":[{"name":"ROX_NODE_NAME","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"spec.nodeName"}}},{"name":"ROX_CLAIR_V4_SCANNING","value":"true"},{"name":"ROX_COMPLIANCE_OPERATOR_INTEGRATION","value":"true"},{"name":"ROX_CSV_EXPORT","value":"false"},{"name":"ROX_DECLARATIVE_CONFIGURATION","value":"false"},{"name":"ROX_INTEGRATIONS_AS_CONFIG","value":"false"},{"name":"ROX_NETPOL_FIELDS","value":"true"},{"name":"ROX_NETWORK_DETECTION_BASELINE_SIMULATION","value":"true"},{"name":"ROX_NETWORK_GRAPH_PATTERNFLY","value":"true"},{"name":"ROX_NODE_SCANNING_CACHE_TIME","value":"3h36m"},{"name":"ROX_NODE_SCANNING_INITIAL_BACKOFF","value":"30s"},{"name":"ROX_NODE_SCANNING_MAX_BACKOFF","value":"5m"},{"name":"ROX_PROCESSES_LISTENING_ON_PORT","value":"false"},{"name":"ROX_QUAY_ROBOT_ACCOUNTS","value":"true"},{"name":"ROX_ROXCTL_NETPOL_GENERATE","value":"true"},{"name":"ROX_SOURCED_AUTOGENERATED_INTEGRATIONS","value":"false"},{"name":"ROX_SYSLOG_EXTRA_FIELDS","value":"true"},{"name":"ROX_SYSTEM_HEALTH_PF","value":"false"},{"name":"ROX_VULN_MGMT_WORKLOAD_CVES","value":"false"}],"image":"registry.redhat.io/advanced-cluster-security/rhacs-scanner-slim-rhel8:4.5.5","imagePullPolicy":"IfNotPresent","name":"node-inventory","ports":[{"containerPort":8444,"name":"grpc","protocol":"TCP"}],"volumeMounts":[{"mountPath":"/host","name":"host-root-ro","readOnly":true},{"mountPath":"/tmp/","name":"tmp-volume"},{"mountPath":"/cache","name":"cache-volume"}]}]}}}}'

14.5.2. Analysis and detection

When you use RHACS with OpenShift Container Platform, RHACS creates two coordinating containers for analysis and detection, the Compliance container and the Node-inventory container. The Compliance container was already a part of earlier RHACS versions. However, the Node-inventory container is new with RHACS 4.0 and works only with OpenShift Container Platform cluster nodes.

Upon start-up, the Compliance and Node-inventory containers begin the first inventory scan of Red Hat Enterprise Linux CoreOS (RHCOS) software components within five minutes. Next, the Node-inventory container scans the node’s file system to identify installed RPM packages and report on RHCOS software components. Afterward, inventory scanning occurs at periodic intervals, typically every four hours. You can customize the default interval by configuring the ROX_NODE_SCANNING_INTERVAL environment variable for the Compliance container.

14.5.3. Vulnerability matching

Central services, which include Central and Scanner, perform vulnerability matching. Scanner uses Red Hat’s Open Vulnerability and Assessment Language (OVAL) v2 security data streams to match vulnerabilities on Red Hat Enterprise Linux CoreOS (RHCOS) software components.

Unlike the earlier versions, RHACS 4.0 no longer uses the Kubernetes node metadata to find the kernel and container runtime versions. Instead, it uses the installed RHCOS RPMs to assess that information.

14.5.4. Related environment variables

You can use the following environment variables to configure RHCOS node scanning on RHACS.

Table 14.4. Node-inventory configuration
Environment VariableDescription

ROX_NODE_SCANNING_CACHE_TIME

The time after which a cached inventory is considered outdated. Defaults to 90% of ROX_NODE_SCANNING_INTERVAL that is 3h36m.

ROX_NODE_SCANNING_INITIAL_BACKOFF

The initial time in seconds a node scan will be delayed if a backoff file is found. The default value is 30s.

ROX_NODE_SCANNING_MAX_BACKOFF

The upper limit of backoff. The default value is 5m, being 50% of Kubernetes restart policy stability timer.

Table 14.5. Compliance configuration
Environment VariableDescription

ROX_NODE_SCANNING_INTERVAL

The base value of the interval duration between node scans. The deafult value is 4h.

ROX_NODE_SCANNING_INTERVAL_DEVIATION

The duration of node scans may differ from the base interval time. However, the maximum value is limited by the ROX_NODE_SCANNING_INTERVAL.

ROX_NODE_SCANNING_MAX_INITIAL_WAIT

The maximum wait time before the first node scan, which is randomly generated. You can set this value to 0 to disable the initial node scanning wait time. The default value is 5m.

14.5.5. Identifying vulnerabilities in nodes by using the dashboard

You can use the Vulnerability Management view to identify vulnerabilities in your nodes. The identified vulnerabilities include vulnerabilities in core Kubernetes components and container runtimes such as Docker, CRI-O, runC, and containerd. For more information on operating systems that RHACS can scan, see "Supported operating systems".

Procedure

  1. In the RHACS portal, go to Vulnerability ManagementDashboard.
  2. Select Nodes on the header to view a list of all the CVEs affecting your nodes.
  3. Select a node from the list to view details of all CVEs affecting that node.

    1. When you select a node, the Node details panel opens for the selected node. The Node view shows in-depth details of the node and includes information about CVEs by CVSS score and fixable CVEs for that node.
    2. Select View All on the CVEs by CVSS score widget header to view a list of all the CVEs in the selected node. You can also filter the list of CVEs.
    3. To export the fixable CVEs as a CSV file, select Export as CSV under the Node Findings section.

14.5.6. Viewing Node CVEs

You can identify vulnerabilities in your nodes by using RHACS. The vulnerabilities that are identified include the following:

  • Vulnerabilities in core Kubernetes components
  • Vulnerabilities in container runtimes such as Docker, CRI-O, runC, and containerd

For more information about operating systems that RHACS can scan, see "Supported operating systems".

Procedure

  1. In the RHACS portal, click Vulnerability ManagementNode CVEs.
  2. To view the data, do any of the following tasks:

    • To view a list of all the CVEs affecting all of your nodes, select <number> CVEs.
    • To view a list of nodes that contain CVEs, select <number> Nodes.
  3. Optional: To filter CVEs according to entity, select the appropriate filters and attributes. To add more filtering criteria, follow these steps:

    1. Select the entity or attribute from the list.
    2. Depending on your choices, enter the appropriate information such as text, or select a date or object.
    3. Click the right arrow icon.
    4. Optional: Select additional entities and attributes, and then click the right arrow icon to add them. The filter entities and attributes are listed in the following table.

      Table 14.6. CVE filtering
      EntityAttributes

      Node

      • Name: The name of the node.
      • Operating system: The operating system of the node, for example, Red Hat Enterprise Linux (RHEL).
      • Label: The label of the node.
      • Annotation: The annotation for the node.
      • Scan time: The scan date of the node.

      CVE

      • Name: The name of the CVE.
      • Discovered time: The date when RHACS discovered the CVE.
      • CVSS: The severity level for the CVE. You can select from the following options for the severity level:

        • is greater than
        • is greater than or equal to
        • is equal to
        • is less than or equal to
        • is less than

      Node Component

      • Name: The name of the component.
      • Version: The version of the component, for example, 4.15.0-2024. You can use this to search for a specific version of a component, for example, in conjunction with a component name.

      Cluster

      • Name: The name of the cluster.
      • Label: The label for the cluster.
      • Type: The type of cluster, for example, OCP.
      • Platform type: The type of platform, for example, OpenShift 4 cluster.
  4. Optional: To refine the list of results, do any of the following tasks:

    • Click CVE severity, and then select one or more levels.
    • Click CVE status, and then select Fixable or Not fixable.
  5. Optional: To view the details of the node and information about the CVEs according to the CVSS score and fixable CVEs for that node, click a node name in the list of nodes.

Chapter 15. Responding to violations

Using Red Hat Advanced Cluster Security for Kubernetes (RHACS) you can view policy violations, drill down to the actual cause of the violation, and take corrective actions.

RHACS’s built-in policies identify a variety of security findings, including vulnerabilities (CVEs), violations of DevOps best practices, high-risk build and deployment practices, and suspicious runtime behaviors. Whether you use the default out-of-box security policies or use your own custom policies, RHACS reports a violation when an enabled policy fails.

15.1. Violations view

You can analyze all violations in the Violations view and take corrective action.

In the RHACS portal, go to Violations to see the discovered violations.

The Violations view shows a list of violations with the following attributes for each row:

  • Policy: The name of the violated policy.
  • Entity: The entity where the violation occurred.
  • Type: The type of entity, such as a deployment, namespace, or cluster.
  • Enforced: Indicates if the policy was enforced when the violation occurred.
  • Severity: Indicates the severity as Low, Medium, High, or Critical.
  • Categories: The policy categories. Policy categories are listed in Platform ConfigurationPolicy Management in the Policy categories tab.
  • Lifecycle: The lifecycle stages to which the policy applies, Build, Deploy, or Runtime.
  • Time: The date and time when the violation occurred.

Similar to other views, you can perform the following actions:

  • Select a column heading to sort the violations in ascending or descending order.
  • Use the filter bar to filter violations. See the Searching and filtering section for more information.
  • Select a violation in the Violations view to see more details about the violation.

15.1.1. Marking violations as resolved

If a policy that has runtime violations is deleted, attempted violations are not deleted from the Violations page. You can manually remove the violation by marking it as resolved.

Procedure

  1. Select Violations and locate the violation in the list of violations.
  2. Click the overflow menu, kebab , and then select one of the following options:

    • Resolve and add to process baseline: Resolves the violation and adds the associated process to the process baseline. If the process is executed again, a new violation will be displayed.
    • Mark as resolved: Resolves the violation.

15.2. Viewing violation details

When you select a violation in the Violations view, a window opens with more information about the violation. It provides detailed information grouped by multiple tabs.

15.2.1. Violation tab

The Violation tab of the Violation Details panel explains how the policy was violated. If the policy targets deploy-phase attributes, you can view the specific values that violated the policies, such as violation names. If the policy targets runtime activity, you can view detailed information about the process that violated the policy, including its arguments and the ancestor processes that created it.

15.2.2. Deployment tab

The Deployment tab of the Details panel displays details of the deployment to which the violation applies.

Overview section

The Deployment overview section lists the following information:

  • Deployment ID: The alphanumeric identifier for the deployment.
  • Deployment name: The name of the deployment.
  • Deployment type: The type of the deployment.
  • Cluster: The name of the cluster where the container is deployed.
  • Namespace: The unique identifier for the deployed cluster.
  • Replicas: The number of the replicated deployments.
  • Created: The time and date when the deployment was created.
  • Updated: The time and date when the deployment was updated.
  • Labels: The labels that apply to the selected deployment.
  • Annotations: The annotations that apply to the selected deployment.
  • Service Account: The name of the service account for the selected deployment.
Container configuration section

The Container configuration section lists the following information:

  • containers: For each container, provides the following information:

    • Image name: The name of the image for the selected deployment. Click the name to view more information about the image.
    • Resources: This section provides information for the following fields:

      • CPU request (cores): The number of cores requested by the container.
      • CPU limit (cores): The maximum number of cores that can be requested by the container.
      • Memory request (MB): The memory size requested by the container.
      • Memory limit (MB): The maximum memory that can be requested by the container.
    • volumes: Volumes mounted in the container, if any.
    • secrets: Secrets associated with the selected deployment. For each secret, provides information for the following fields:

      • Name: Name of the secret.
      • Container path: Location where the secret is stored.
    • Name: The name of the location where the service will be mounted.
    • Source: The data source path.
    • Destination: The path where the data is stored.
    • Type: The type of the volume.
Port configuration section

The Port configuration section provides information about the ports in the deployment, including the following fields:

  • ports: All ports exposed by the deployment and any Kubernetes services associated with this deployment and port if they exist. For each port, the following fields are listed:

    • containerPort: The port number exposed by the deployment.
    • protocol: Protocol, such as, TCP or UDP, that is used by the port.
    • exposure: Exposure method of the service, for example, load balancer or node port.
    • exposureInfo: This section provides information for the following fields:

      • level: Indicates if the service exposing the port internally or externally.
      • serviceName: Name of the Kubernetes service.
      • serviceID: ID of the Kubernetes service as stored in RHACS.
      • serviceClusterIp: The IP address that another deployment or service within the cluster can use to reach the service. This is not the external IP address.
      • servicePort: The port used by the service.
      • nodePort: The port on the node where external traffic comes into the node.
      • externalIps: The IP addresses that can be used to access the service externally, from outside the cluster, if any exist. This field is not available for an internal service.
Security context section

The Security context section lists whether the container is running as a privileged container.

  • Privileged:

    • true if it is privileged.
    • false if it is not privileged.
Network policy section

The Network policy section lists the namespace and all network policies in the namespace containing the violation. Click on a network policy name to view the full YAML file of the network policy.

15.2.3. Policy tab

The Policy tab of the Details panel displays details of the policy that caused the violation.

Policy overview section

The Policy overview section lists the following information:

  • Severity: A ranking of the policy (critical, high, medium, or low) for the amount of attention required.
  • Categories: The policy category of the policy. Policy categories are listed in Platform ConfigurationPolicy Management in the Policy categories tab.
  • Type: Whether the policy is user generated (policies created by a user) or a system policy (policies built into RHACS by default).
  • Description: A detailed explanation of what the policy alert is about.
  • Rationale: Information about the reasoning behind the establishment of the policy and why it matters.
  • Guidance: Suggestions on how to address the violation.
  • MITRE ATT&CK: Indicates if there are MITRE tactics and techniques that apply to this policy.
Policy behavior

The Policy behavior section provides the following information:

  • Lifecycle Stage: Lifecycle stages that the policy belongs to, Build, Deploy, or Runtime.
  • Event source: This field is only applicable if the lifecycle stage is Runtime. It can be one of the following:

    • Deployment: RHACS triggers policy violations when event sources include process and network activity, pod exec, and pod port forwarding.
    • Audit logs: RHACS triggers policy violations when event sources match Kubernetes audit log records.
  • Response: The response can be one of the following:

    • Inform: Policy violations generate a violation in the violations list.
    • Inform and enforce: The violation is enforced.
  • Enforcement: If the response is set to Inform and enforce, lists the type of enforcement that is set for the following stages:

    • 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.
Policy criteria section

The Policy criteria section lists the policy criteria for the policy.

15.2.3.1. Security policy enforcement for the deploy stage

Red Hat Advanced Cluster Security for Kubernetes supports two forms of security policy enforcement for deploy-time policies: hard enforcement through the admission controller and soft enforcement by RHACS Sensor. The admission controller blocks creation or updating of deployments that violate policy. If the admission controller is disabled or unavailable, Sensor can perform enforcement by scaling down replicas for deployments that violate policy to 0.

Warning

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

15.2.3.1.1. Hard enforcement

Hard enforcement is performed by the RHACS admission controller. In clusters with admission controller enforcement, the Kubernetes or OpenShift Container Platform API server blocks all noncompliant deployments. The admission controller blocks CREATE and UPDATE operations. Any pod create or update request that satisfies a policy configured with deploy-time enforcement enabled will fail.

Note

Kubernetes admission webhooks support only CREATE, UPDATE, DELETE, or CONNECT operations. The RHACS admission controller supports only CREATE and UPDATE operations. Operations such as kubectl patch, kubectl set, and kubectl scale are PATCH operations, not UPDATE operations. Because PATCH operations are not supported in Kubernetes, RHACS cannot perform enforcement on PATCH operations.

For blocking enforcement, you must enable