Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
    2. history
×

Evaluating security risks

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.

Opening the risk view

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

Procedure

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

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

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 attribute Policy 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

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.

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

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.

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.

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.

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.

Security context section

The Security Context section shows details about the following:

  • Privileged: Lists true if the container is privileged.

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.

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 Export → Download PDF or Export → Download 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.

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

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.

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.

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.

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.

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

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.

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.