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

Commands: