1. Documentation
    2. history bug_report picture_as_pdf
×

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.

In the RHACS portal, go to Violations to see the discovered violations.

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.

Marking violations as resolved

If a policy that has runtime violations is deleted, attempted violations are not deleted from the Violations page. You can manually remove the violation by marking it as resolved.

Procedure

  1. Select Violations and locate the violation in the list of violations.

  2. Click the overflow menu, kebab, and then select one of the following options:

    • Resolve and add to process baseline: Resolves the violation and adds the associated process to the process baseline. If the process is executed again, a new violation will be displayed.

    • Mark as resolved: Resolves 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: 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.

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.

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

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.

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.

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.

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