You are viewing documentation for a release that is no longer maintained. To view the documentation for the most recent version, see the latest RHACS docs.
Chapter 3. 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.
3.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.
3.1.1. 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.
3.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
- 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.
3.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
ORoperator. For example, if the search query isCluster:A,B, the filter matches deployments incluster Aorcluster B. -
Combines the search terms from different categories with an
ANDoperator. For example, if the search query isCluster:A+Namespace:Z, the filter matches deployments incluster Aand innamespace Z.
-
Combines the search terms within the same category with an
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).
-
For example, if you search for
- 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 |
3.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.
3.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).
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.
3.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.
3.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,
DeploymentorDaemonSet. - 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.
3.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.
3.4.3. Security context section
The Security Context section shows details about the following:
-
Privileged: Lists
trueif the container is privileged.
3.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.
3.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 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
appandsidecar, Red Hat Advanced Cluster Security for Kubernetes keeps activity for up to 10appinstances and up to 10sidecarinstances. - Does not track process activities associated with the previous instances of the container.
-
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
- 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 at10:54:47.5349823, Red Hat Advanced Cluster Security for Kubernetes adjusts the container start time to10:54:47.5349823.
3.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.
<discreet><title>Process baselines</title>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.
</discreet><discreet><title>Process baseline states</title>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.
3.6.1. 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.
3.6.2. 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.
3.6.3. 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.
3.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
- 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.
