Evaluating security risks | Operating | Red Hat Advanced Cluster Security for Kubernetes 3.66

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.

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

Navigate to the RHACS portal and select Risk from the navigation menu.
Apply local page filtering criteria that you want to create a policy.
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

Search attribute

Policy criteria

Add Capabilities

Annotation

Disallowed Annotation

CPU Cores Limit

Container CPU Limit

CPU Cores Request

Container CPU Request

CVE

CVE Published On

✕ Dropped

CVE Snoozed

✕ Dropped

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 Pull Secret

✕ Dropped

Image Registry

Image Remote

Image Scan Time

Days since image was last scanned

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 Protocol

Protocol

Priority

✕ Dropped

Privileged

Process Ancestor

Process Arguments

Process Name

Process Path

✕ Dropped

Process Tag

✕ Dropped

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 Name

Volume ReadOnly

Writable Volume

Volume Source

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 comments and tags

You can use tags and comments to specify what is happening with processes to keep your team up to date. Comments enable you to add text notes to processes, and tags allow you to categorize your processes.

Adding comments

Comments allow you to add text notes to processes, so that everyone in the team can check what is happening with a process.

Prerequisites

To add and remove comments, you need a role with write permission for the resource you are modifying. For example, to add comments on processes, your role must have write permission for the Alert resource.
To delete comments from other users, you need a role with write permission for the AllComments resource.

You can edit and delete your own comments.

Procedure

Click New in the Processes Comments section header.
Enter your comment in the comment editor. You can also add links in the comment editor. When someone clicks on the link in a comment, the linked resource opens in a new tab in their browser.
Click Save.

All comments are visible under the Processes Comments section, and you can edit and delete comments by selecting Edit or Delete icon for a specific comment.

Adding tags

You can use custom tags to categorize your processes. Then you can filter the Processes view to show processes for selected tags (Tag attribute).

Prerequisites

To add and remove tags, you need a role with write permission for the resource you are modifying. For example, to add tags on processes, your role must have write permission for the Alert resource.
To delete tags from other users, you need a role with write permission for the AllComments resource.

You can edit and delete your own tags.

Procedure

Select the drop-down menu in the Process Tags section. Existing tags appear as a list (up to 10).
Click on an existing tag or enter a new tag and then press Enter. As you enter your query, Red Hat Advanced Cluster Security for Kubernetes automatically displays relevant suggestions for the existing tags that match.

You can add more than one tag for a process. All tags are visible under the Process Tags section and you can remove tags by clicking on the Remove icon for a specific tag.

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

In the RHACS portal, select Risk from the navigation menu.
Select a deployment from the list of deployments in the default Risk view. deployment details open in a panel on the right.
In the deployment details panel, select the Process Discovery tab.
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

In the RHACS portal, select Risk from the navigation menu.
Select a deployment from the list of deployments in the default Risk view. deployment details open in a panel on the right.
In the deployment details panel, select the Process Discovery tab.
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

In the RHACS portal, select Risk from the navigation menu.
Select a deployment from the list of deployments in the default Risk view. deployment details open in a panel on the right.
In the deployment details panel, select the Process Discovery tab.
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

In the RHACS portal, select Risk from the navigation menu.
Select a deployment from the list of deployments in the default Risk view. deployment details open in a panel on the right.
In the deployment details panel, select the Process Discovery tab.
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.