Questo contenuto non è disponibile nella lingua selezionata.

Chapter 15. Responding to violations

Using Red Hat Advanced Cluster Security for Kubernetes (RHACS) you can view policy violations, navigate 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. Namespace conditions for platform components

By understanding the namespace conditions for platform components, you can identify and manage the namespaces that fall under OpenShift Container Platform, layered products, and third party partners in your environment.

Table 15.1. Namespace conditions for platform components
Platform component	Namespace condition
OpenShift Container Platform	Namespace starts with `openshift-` Namespace starts with `kube-`
Layered products	namespace = `stackrox` Namespace starts with `rhacs-operator` Namespace starts with `open-cluster-management` namespace = `multicluster-engine` namespace = `aap` namespace = `hive`
Third party partners	namespace = `nvidia-gpu-operator`

Red Hat Advanced Cluster Security for Kubernetes (RHACS) identifies the workloads belonging to platform components by using the following regex pattern:

^kube-.*|^openshift-.*|^stackrox$|^rhacs-operator$|^open-cluster-management$|^multicluster-engine$|^aap$|^hive$|^nvidia-gpu-operator$

15.2. Analyzing all violations

By viewing the Violations page, you can analyze all violations and take corrective action.

Procedure

In the RHACS portal, click Violations.
To navigate through the different types of violations, do any of the following tasks:
- To view the list of active violations, click the Active tab.
- To view the list of resolved violations, click the Resolved tab.
- To view the list of violations that RHACS attempted to resolve, click the Attempted tab.
Choose the appropriate method to view the violations from the drop-down list, which is in the upper left of the page:
- To display the findings for application workloads, select Applications view.
- To display the findings for platform components in OpenShift Container Platform, select Platform view.
- To display the findings for application workloads and platform components simultaneously, select Full view.
Optional: Choose the appropriate method to re-organize the information in the Violations page:
- To sort the violations in ascending or descending order, select a column heading.
- To filter violations, use the filter bar.
- To see more details about the violation, select a violation in the Violations page.
Optional: Choose the appropriate method to exclude a deployment from the policy:
- If you selected a single deployment, click the overflow menu and then select Exclude deployment from policy.
- If you selected multiple deployments, from the Row actions drop-down list, select Exclude deployments from policy.

15.3. Violations page overview

The Violations page shows a list of violations and organizes information into the following groups:

Policy: The name of the violated policy.
Entity: The entity where the violation occurred.
Type: The type of entity.
For workload violations, the type indicates the workload type, for example, Deployment, Pod, DaemonSet, and so on.
For other resource violations, the type indicates the resource type, for example, Secrets, ConfigMaps, ClusterRoles, and so on.
Enforced: Indicates if the policy was enforced when the violation occurred.
Severity: The severity of the violation.
The following values are associated with the severity of the violation:
- Low
- Medium
- High
- Critical
Categories: The category of the violated policy.
To view the policy categories:
- In the RHACS portal, click the Platform Configuration Policy Management Policy categories tab.
Lifecycle: The lifecycle stages to which the policy applies.
The following values are associated with the lifecycle stages:
- Build
- Deploy
- Runtime
Time: The date and time when the violation occurred.

15.4. 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.4.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.4.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.4.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 Configuration Policy 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 execution, 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.4.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.4.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 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.

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

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

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

Additional resources

Using admission controller enforcement

15.4.4. Network policies tab

The Network policies section lists the network policies associated with a namespace.