This is a cache of https://docs.openshift.com/acs/4.2/operating/respond-to-violations.html. It is a snapshot of the page at 2024-11-23T17:52:53.967+0000.
Responding to violations | Operating | Red Hat Advanced Cluster Security for Kubernetes 4.2
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Responding to violations

Using Red Hat Advanced Cluster Security for Kubernetes (RHACS) you can view policy violations, drill down 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.

Violations view

You can analyze all violations in the Violations view and take corrective action.

To see discovered violations, select Violations from the left navigation menu on the RHACS portal.

The Violations view shows a list of violations with the following attributes for each row:

  • Policy: The name of the violated policy.

  • Entity: The entity where the violation occurred.

  • Type: The type of entity, such as a deployment, namespace, or cluster.

  • Enforced: Indicates if the policy was enforced when the violation occurred.

  • Severity: Indicates the severity as Low, Medium, High, or Critical.

  • Categories: The policy categories. Policy categories are listed in Platform Configuration → Policy Management in the Policy categories tab.

  • Lifecycle: The lifecycle stages to which the policy applies, Build, Deploy, or Runtime.

  • Time: The date and time when the violation occurred.

Similar to other views, you can perform the following actions:

  • Select a column heading to sort the violations in ascending or descending order.

  • Use the filter bar to filter violations. See the Searching and filtering section for more information.

  • Select a violation in the Violations view to see more details about the violation.

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.

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.

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.

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 exec, 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: RHACS blocks creation of deployments that match the conditions of the policy. 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.

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