Home
Products
Red Hat Advanced Cluster Security for Kubernetes
4.11
Operating
Chapter 5. Using policies to provide security

Chapter 5. Using policies to provide security

5.1. About policies in RHACS
Copy link

Red Hat Advanced Cluster Security for Kubernetes (RHACS) helps you secure your container infrastructure by using a robust policy engine and an admission controller. With RHACS, you can establish appropriate security guardrails, inform about policy violations, and selectively enforce policies to prevent insecure situations.

Specifically, RHACS can help you fail the CI pipeline in the build stage, reject deployments from being deployed in the deployment stage, and shut down running deployments that violate runtime policies. RHACS also provides policy management and violation management tools described in the following sections.

5.1.1. Understanding the RHACS policy evaluation engine
Copy link

The RHACS policy engine evaluates policies that you have created based on policy criteria. It operates differently in each of the build, deploy, and runtime stages.

Build stage

RHACS can evaluate policy rules upon request by using the roxctl CLI. When a policy is violated during the build stage, the violation text and error code let developers know what failed and how to fix it. You can configure the error code to fail the pipeline. During this stage, RHACS can evaluate both standalone images and deployments against applicable policies. Violations from the build stage are not stored or routed using notifiers.

Deploy stage

RHACS uses deploy stage policies when inspecting workloads during a deployment attempt. These policies are composed of workload criteria, such as the following criteria:

Container configuration, including environment variables and privileges
Deployment metadata, such as required or disallowed annotations and labels
Storage volume information, such as volume name and mount configuration
Networking configuration, such as port exposure and ingress or egress policy
Kubernetes access configuration, which consists of criteria such as service account configuration and Role-based Access Control (RBAC) permissions

You can also include image criteria, such as image registry, image content, and CVE data, when building deploy stage policies. This is helpful if you want to evaluate the same requirements in both pipeline builds and deployment attempts. This eliminates the need to duplicate policies, because you can create a policy that includes both image and workload criteria and use it for both the build and deploy stages.

RHACS prevents Kubernetes or OpenShift Container Platform from creating or updating workloads, for example, deployments, daemon sets or jobs, that match the conditions of the policy. This is useful for shutting down deployments with serious problems even if the build was successful.

Runtime stage

RHACS continuously evaluates deployments against applicable policies after a deployment is running. Runtime policies are used to monitor running pods within a Kubernetes cluster and report or prevent unauthorized workload activity, baseline deviations, or prohibited Kubernetes resource operations. RHACS can monitor unsafe Kubernetes requests and selectively block them by using the API. F example, RHACS can block attempted access to config maps or secrets.

Runtime policies can inspect the following two event sources:

Deployment events: Real-time events such as running pods, process activity inside pods, deviations from networking or process baselines, or user-pod interaction such as port forwarding or port exec actions
Audit log events: Logs that can be inspected for actions such as access to sensitive Kubernetes resources

Runtime policies can also include build and deploy stage criteria for the following reasons:

These criteria can be used to identify high-risk situations combining runtime and workload/image criteria.
These criteria can ensure that the build and deploy stage requirements are met during runtime, for example, when a new vulnerability is discovered, or a new requirement has been introduced.

Audit log policies are used to inspect the Kubernetes audit log for actions related to sensitive Kubernetes resources, such as secrets and ClusterRoleBinding. They have the following characteristics:

Audit log policies are only composed of the audit log criteria.
They are not associated with images or deployments. For this reason, audit log policies can only be associated with the runtime lifecycle stage.
These policies are not enforceable, because the audited action has already occurred.

5.1.2. About policy enforcement
Copy link

When you configure policies in RHACS, you can configure how RHACS responds when it detects a condition that violates a security policy.

RHACS allows you to enforce security policies during all phases of the development lifecycle: build, deploy, and runtime.

RHACS provides two types of policy enforcement:

Sensor enforcement: Also known as soft enforcement, if a workload is examined and violates a policy, Sensor scales down pods by using the Kubernetes API.
Admission controller enforcement: Also known as hard enforcement, an admission controller works with validating webhooks and the Kubernetes API server to block workload admission or update attempts that violate an enforced policy. When a request is made to deploy or update, the validating webhooks communicate with the admission controller and the admission controller responds to either allow or block the action based on whether a policy is enforced. The API server accepts or rejects the request based on whether it violates the policy and if the policy is enforced.

For more information about admission controller enforcement, see "Understanding admission controller enforcement".

5.1.2.1. Build stage enforcement
Copy link

RHACS uses build stage policies to discover and respond to security violations before code is deployed. Build stage policies are composed entirely of image criteria, such as image registry, image content, and CVE data, including scan results and status.

RHACS checks the build by using the roxctl image check and roxctl deployment check commands. You can configure RHACS to fail your continuous integration (CI) builds when images match the criteria of the policy. This means that when there is a condition in the build that violates the policy, for example, if there is a fixable CVE of a severity level and you have configured a policy for that condition, the build fails.

As an example, you can configure RHACS to check an image or deployment and integrate that check into a continuous integration/continuous development (CI/CD) pipeline. Then, if RHACS detects a condition that means a policy should fail, the RHACS API returns a non-zero exit code. These violations are not collected or acted on by RHACS, but are used with a CI/CD tool. You configure your CI/CD tool to act on those results, for example, to fail the build process if a violation is reported.

5.1.2.2. Deploy stage enforcement
Copy link

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.

5.1.2.2.1. Hard enforcement
Copy link

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, UPDATE, and SCALE operations. Any pod create, update, or scale request that satisfies a policy configured with deploy-time enforcement enabled will fail. The admission controller also blocks user-initiated container commands such as pod exec and port forward for policies configured with runtime enforcement.

Note

Kubernetes admission webhooks support only CREATE, UPDATE, DELETE, and CONNECT operations. The RHACS admission controller supports only CREATE, UPDATE, and SCALE 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. However, enforcement against SCALE operations is supported.

For hard enforcement, enable the enforcement settings for the cluster in RHACS. To verify that enforcement is enabled, in the Static configuration section, in the Admission controller enforcement behavior field, ensure that Enforce policies is selected. Additionally, for each policy that you want to enforce, select Inform and enforce when configuring the policy.

Note

Because admission controller enforcement is a static configuration option, changing this setting for clusters that are installed by using the manifest or roxctl method requires you to download the updated YAML bundle and redeploy it to the cluster.

5.1.2.2.2. Namespace exclusions from admission controller enforcement
Copy link

By default, Red Hat Advanced Cluster Security for Kubernetes (RHACS) excludes certain administrative namespaces from from the validating webhook configurations in the admission controller. Policy evaluation and enforcement is not performed on review requests originating from these administrative namespaces. Some items in these namespaces must be deployed for RHACS to work correctly so they are excluded.

In addition to excluding namespaces, the RHACS admission controller bypasses requests that originate from from a Kubernetes ServiceAccount in a system namespace.

Note

Consider this factor when choosing the namespace to deploy your continuous deployment tool of choice.

The following namespaces are excluded by default:

stackrox
kube-system
kube-public
istio-system

For Helm installations on Kubernetes secured clusters, you can customize the namespaces that are excluded from the validating webhook configuration by configuring the values-public.yaml file. In the admissionControl.namespaceSelector field, you can specify the namespaces that you want to exclude. See the following example:

...
admissionControl:
   namespaceSelector:
    matchExpressions:
    - key: namespace.metadata.stackrox.io/name
      operator: NotIn
      values:
        - stackrox
        - kube-system
        - kube-public
        - istio-system
        - example-namespace
...

where:

example-namespace: Signifies the namespace that you want to exclude.

5.1.2.2.3. Enforcement on existing deployments
Copy link

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.

5.1.2.2.4. Soft enforcement
Copy link

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.

By design, Sensor only performs this soft enforcement once, to prevent trapping of update requests to scale the deployment back down again.

If soft enforcement is configured, and Sensor is down, then RHACS cannot perform enforcement.

5.1.2.3. Runtime enforcement
Copy link

You can configure policies that are enforced during runtime to terminate a pod that violates the policy or, in the case of audit log inspection, notify you of events that violate the policy but have already occurred and have been logged.

When enforced, a policy violation results in one or more of the following actions:

Shutting down an offending pod, which results in creation of another healthy pod in its place
RHACS intercepting and preventing certain Kubernetes API calls

Important

When a violation is triggered by an image or workload rule, a violation alert is generated, but the pod is not disrupted.

5.1.3. RHACS policy structure
Copy link

RHACS policies are structured text objects that define security rules and the action RHACS performs when these rules are broken.

An RHACS policy contains the following parts:

5.1.3.1. Policy definition
Copy link

The policy definition specifies the policy’s metadata and its rules, including the following components:

Policy details

Text to assist policy authors in managing policies and end users in the remediation process.

Lifecycle

A fundamental policy attribute that determines when RHACS evaluates that policy.

Policy rules

A set of conditions that are used with an implied OR, for example, rule 1 or rule 2. Each rule consists of predefined building blocks called policy criteria that use an AND relationship, for example, criterion A and criterion B. RHACS uses intuitive text to describe the conditions that you want, rather than having you specify potentially complex Kubernetes conditions.

Most RHACS criteria configure the condition on which to trigger the policy, and many criteria include a NOT form. However, a few criteria define the positive, expected behavior. Whether a criteria defines a positive or negative condition depends on the context. Ccriteria are designed to make creating policies intuitive for policy users.

The following examples show negative and positive forms of policy criteria:

Negative form: Container Registry name is <gcr.io> triggers if the specific gcr.io registry is used. Therefore, Container Registry name is NOT <quay.io> triggers if any registry is used other than the allowed registry, quay.io. This is a generalized rule.
Negative form: Liveness probe is <Not Defined> triggers if a liveness probe is missing from the configuration. You can use Liveness probe is <Defined> to receive a positive notification by using a notifier for all compliant workloads.
Positive form: The Drop capabilities, Capabilities that MUST be dropped: <SYS_ADMIN> rule defines the expected behavior. If a workload fails to drop the SYS_ADMIN property, it violates the policy and triggers a violation alert.

5.1.3.2. Policy behavior
Copy link

The policy behavior specifies the action, inform or enforce, that RHACS takes for given resources. Policy behavior includes the following items:

Resources

By default, RHACS policies are global; they apply across all secured clusters, on all namespaces, for all workloads and images.

You can modify the policy resources by explicitly including or excluding a mix of cluster, namespace, and deployment selection criteria. Policy resource targeting can use cluster ID or cluster labels, namespace name or namespace labels, and deployment labels to target specific resources. Regular expressions in RE2 syntax are supported for namespace names and deployment labels.

Label-based resource targeting (cluster labels and namespace labels) uses exact key=value matching for included resources only and requires RHACS 4.11 or later on secured clusters installed by using Helm or the Operator. Excluded resources do not support cluster label or namespace label targeting.

Action

Determines if a policy is active, for example, whether it is enabled or disabled, if it is enforced, and the notifiers to use for routing alerts.

5.1.4. Policy and violation management
Copy link

Policy management encompasses the set of activities that security teams undertake to establish the appropriate guardrails. All of these activities happen before the policy is evaluated. Violation management is the set of activities that security and developer teams take to assist in addressing security incidents to remediate policy violations. All of these activities happen after a policy has been violated.

5.1.4.1. Setting policy rules
Copy link

With policy as code, RHACS supports both internal and external sources for policies. When using external policies, RHACS defines a Kubernetes native Custom Resource (CR) to streamline policy as code by using tools like OpenShift Pipelines and Argo CD.

You can use RHACS to perform the following actions:

Define policy rules: Whether teams manage their policies as code or by using the RHACS internal database, authoring policies can be technically challenging. RHACS provides an intuitive user interface, or portal, that simplifies this task. You can focus on controls while hiding the specification complexity. You can author policies by using the portal and then exported them as YAML to be stored as code or be stored locally.
Choose the lifecycle to which the policy applies: For internal policies, RHACS offers Create, Read, Update, Delete (CRUD) actions. For external policies, these actions are handled by users on their own, and the results are presented to RHACS using the CR. For internal policies, RHACS also offers role-based access control and tracks changes to policies in its audit log.
Configure policy behavior: RHACS provides users with multi-cluster governance in a centralized manner. When configuring policies, you can configure the following:
- Select the scope for inclusion or exclusion for individual clusters, or establish governance to apply to all clusters
- Choose the action (inform/enforce), and enable or disable the policy
- Configure notifiers
Test policies:
- You can perform a dry run to test the policy in the portal or by using the API, and perform policy CR validation
- Create policy reports: You can configure reporting in the portal or by using the API to detail policy coverage

5.1.5. Default security policies
Copy link

The default security policies in Red Hat Advanced Cluster Security for Kubernetes provide broad coverage to identify security issues and ensure best practices for security in your environment. By configuring those policies, you can automatically prevent high-risk service deployments in your environment and respond to runtime security incidents.

For a list of default security policies categorized by severity, see "Security policy reference".

5.1.5.1. Viewing default security policies
Copy link

You can use the RHACS portal to view default policies, clone them, and edit the cloned default policies. Default policies are not supported with the policies as code feature.

Procedure

In the RHACS portal, go to Platform Configuration Policy Management. Default policies are indicated by the System label in the Origin column.
Note
You cannot delete default policies or edit policy criteria for default policies.

5.1.6. Custom security policies
Copy link

With RHACS, you can create custom security policies to provide security during the build, deploy, and run phases of development. You can create custom security policies by the following methods:

You can clone a default policy and then modify it to configure specific information for your environment
You can use the RHACS portal to create and save a new policy.
With the policy as code feature, you can create and save policies as Kubernetes custom resources (CRs) and use a Kubernetes-native continuous delivery (CD) tool such as Argo CD to apply them to clusters.

For more information, see "Creating and modifying security policies".

Important

Use caution when enforcing custom policies in the openshift-* namespaces and for default OpenShift Container Platform pods. For example, a custom policy with enforcement configured can terminate pods with possible data loss if the policy is violated.

5.2. Using admission controller enforcement
Copy link

RHACS works with Kubernetes admission controllers and OpenShift Container Platform admission plugins to give you the ability to enforce security policies before Kubernetes or OpenShift Container Platform creates workloads, for example, deployments, daemon sets or jobs. The RHACS admission controller prevents users from creating or updating workloads that violate policies that you configure in RHACS.

5.2.1. Understanding admission controller enforcement
Copy link

RHACS uses an admission controller to provide enforcement for security policies that you have configured. The admission controller works with validating webhooks to evaluate requests to create, update, and perform workload operations against security policies. It can also evaluate running workloads and detect user-initiated container commands such as pod exec and port forward. If enforcement is configured for a policy and results in a violation, the request fails, preventing the operation from persisting in the API server and being successfully completed.

The workflow for evaluating requests and enforcing policies follows these steps:

A user or system submits a request to create, update, or perform workload operations that is received by the Kubernetes or OpenShift Container Platform API server.
The API server contacts the validating webhooks with an AdmissionReview request.
The validating webhooks call the admission controller via the service endpoint to verify that the resource being provisioned or user-issued commands in the containers comply with the specified security policies.
The review request is either passed or failed, or can time out in some cases:
- If the review request violates an enforced security policy, the API server rejects the request.
- If review request is not prevented by a security policy or times out, the API server accepts and persists the resource. In the case of a timeout, this behavior is known as "fail open", which is the default behavior. However, you can configure the default behavior in case of timeout to "fail closed" for stricter enforcement.

If you use admission controller enforcement, consider the following guidance:

Using admission controller enforcement increases Kubernetes or OpenShift Container Platform API latency because it involves additional validation like policy evaluation on Kubernetes operations. Many standard Kubernetes libraries, such as fabric8, have short Kubernetes or OpenShift Container Platform API timeouts by default.
Consider API timeouts in any custom automation you might be using. If a request does time out due to latency issues, you can configure if the admission controller will fail open, allowing the request to reach the API server, or fail closed, blocking the requested operation. This setting is configured during installation and you can verify the setting by selecting Platform Configuration Clusters and checking the Admission controller failure policy.
If you are using RHACS in a continuous development (CD) tool, set the admission controller failure policy to fail closed, so that your CD tool handles the enforcement.
You can use admission controller enforcement for the following items:
- Options in the pod securityContext
- Deployment configurations
- Image components and vulnerabilities
- User-initiated container commands such as pod exec and port forward
If you have deploy stage enforcement enabled for a policy and you enable the admission controller, RHACS attempts to block deployments that violate the policy. If a noncompliant deployment is not rejected by the admission controller, for example, in case of a timeout, RHACS still applies other deploy stage enforcement mechanisms, such as scaling to zero replicas.

5.2.2. Enabling admission controller enforcement during installation
Copy link

You can enable admission controller enforcement when you install a cluster.

When installing a cluster by using the Operator, Helm, or roxctl CLI methods, follow the instructions in "Installing Secured Cluster services for RHACS on Red Hat OpenShift" and "Installing Secured Cluster services for RHACS on other platforms" to enable admission controller enforcement during installation.
When installing a cluster by using the legacy installation method, follow these steps:
1. In the RHACS portal, select Platform Configuration Clusters.
2. Click Secure a cluster Legacy installation method.
3. In the Static configuration section, in the Admission controller enforcement behavior field, select Enforce policies.
4. Select Next.
5. Click Download YAML File and Keys to download the updated cluster bundle.
6. Extract and run the sensor script from the cluster bundle to deploy the configuration to the cluster.
  Note
  When you enable admission controller policy enforcement, the admission controller memory limit is automatically increased to 1 GiB per replica to support image scan data caching requirements. If you specify a custom memory limit override, the custom value takes priority. For more information, see "Admission controller settings for the Operator" and "Configuration parameters for Helm".

Verification

The ValidatingWebhookConfiguration Kubernetes resource contains information about enforcement configuration behavior. The configuration settings are available in the admission controller logs.

5.2.3. Viewing and enabling admission controller enforcement on an existing cluster
Copy link

You can view whether admission controller enforcement was enabled on a cluster or change the enforcement behavior after installation.

Procedure

For a cluster that was installed by using the Operator, in the SecuredCluster custom resource (CR), edit the spec.admissionControl.enforcement parameter to Enabled.

For a cluster that was installed by using Helm, in the values-public.yaml file, set the admissionControl.enforce value to false and run the following command:

helm upgrade -n stackrox \
  stackrox-secured-cluster-services rhacs/secured-cluster-services \
  --reuse-values \
  -f /config/yaml/values-public.yaml \
  -f /config/yaml/values-private.yaml

For clusters installed by another method, you can use the RHACS portal to edit the enforcement option. You cannot edit Operator- or Helm-managed clusters by using the portal. Follow these steps:
1. In the RHACS portal, go to Platform Configuration Clusters.
2. Select an existing cluster from the list.
3. In the Static configuration section, in the Admission controller enforcement behavior field, select Enforce policies. The admission controller enforces policies that are configured for enforcement by rejecting the workload admission or update attempt.
4. Select Next.
5. Click Download YAML File and Keys to download the updated cluster bundle.
6. Extract and run the sensor script from the cluster bundle to redeploy the configuration to the cluster.
  Note
  When you enable admission controller policy enforcement, the admission controller memory limit is automatically increased to 1 GiB per replica to support image scan data caching requirements. If you specify a custom memory limit override, the custom value takes priority. For more information, see "Admission controller settings for the Operator" and "Configuration parameters for Helm".

Verification

The ValidatingWebhookConfiguration Kubernetes resource contains information about enforcement configuration behavior. The configuration settings are available in the admission controller logs.

5.2.4. Bypassing admission controller enforcement
Copy link

To configure a deployment to bypass the admission controller, you must set the admission.stackrox.io/break-glass annotation on the deployment. Bypassing the admission controller triggers a violation of the "StackRox Emergency Deployment Annotation" policy, which includes deployment details.

To help others understand why you bypassed the admission controller, use an issue-tracker link or some other reference as the value of this annotation.

Prerequisites

You have enabled the ability to bypass the admission controller on the secured cluster by using one of the following options:
- Operator: You set the admissionControl.bypass parameter to BreakGlassAnnotation.
- Helm: You set the admissionControl.dynamic.disableBypass parameter to false.
- RHACS portal: You set the option in Platform Configuration Clusters Admission controller bypass annotation to Enabled.

Procedure

Create a deployment YAML that includes the admission.stackrox.io/break-glass annotation, as shown in the following example:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    "admission.stackrox.io/break-glass": "jira-3423"
  creationTimestamp: "2025-03-07T03:18:21Z"
  generation: 1
  labels:
    app: hello-node
  name: hello-node
  namespace: test-bypass-adm
...

where:

metadata.annotations.admission.stackrox.io/break-glass: Specifies a change control reference or relevant explanation for why the admission controller was bypassed.

5.2.5. Disabling admission controller enforcement on a cluster
Copy link

You can disable admission controller enforcement on a cluster when installing RHACS. For clusters that you did not install by using the Operator or Helm, you can disable admission controller enforcement from the Clusters view on the Red Hat Advanced Cluster Security for Kubernetes (RHACS) portal.

Procedure

For a cluster that was installed by using the Operator, in the SecuredCluster custom resource (CR), edit the spec.admissionControl.enforcement parameter to Disabled.

For a cluster that was installed by using Helm, in the values-public.yaml file, set the admissionControl.enforce value to false and run the following command:

helm upgrade -n stackrox \
  stackrox-secured-cluster-services rhacs/secured-cluster-services \
  --reuse-values \
  -f /config/yaml/values-public.yaml \
  -f /config/yaml/values-private.yaml

For clusters that are not managed by the Operator or Helm, you can use the RHACS portal to change this setting:
1. In the RHACS portal, select Platform Configuration Clusters.
2. Select an existing cluster from the list.
3. In the Static configuration section, in the Admission controller enforcement behavior field, select one of the following options:
  - Enforce policies: The admission controller enforces policies that are configured for enforcement by rejecting the workload admission or update attempt.
  - No enforcement: Even if enforcement is configured for a policy, if this option is selected, the admission controller does not enforce the policy and allows workload admission attempts or updates that violate the policy.
4. Select Next.
5. Click Download YAML File and Keys to download the updated cluster bundle.
6. Extract and run the sensor script from the cluster bundle to redeploy the configuration to the cluster.

5.2.6. Configuring the admission controller failure policy during installation
Copy link

You can configure the admission controller failure policy when you install a cluster. This setting determines whether the API server request is allowed (fail open) or blocked (fail closed) if an error or timeout happens in the RHACS validating webhook evaluation.

When installing a cluster by using the Operator, Helm, or roxctl CLI methods, follow the instructions in "Installing Secured Cluster services for RHACS on Red Hat OpenShift" and "Installing Secured Cluster services for RHACS on other platforms" to configure this parameter during installation.
When installing a cluster by using the legacy installation method, follow these steps:
1. In the RHACS portal, select Platform Configuration Clusters.
2. Select an existing cluster from the list.
3. In the Static configuration (requires deployment) section, in the Admission controller failure policy field, select one of the following options:
  - Fail open: If an error or timeout occurs when a workload admission or update request is being evaluated by the validating webhook, the request should be allowed to reach the API server.
  - Fail closed: If an error or timeout occurs when a workload admission or update request is being evaluated by the validating webhook, the request should not be allowed to reach the API server, but should be blocked.
4. Select Next.
5. Select Finish. Because this is a change to the static configuration, you must redeploy the cluster for your changes to take effect.

5.2.7. Configuring the admission controller failure policy on an existing cluster
Copy link

You can configure the admission controller failure policy for an existing cluster. This setting determines whether the API server request is allowed (fail open) or blocked (fail closed) if an error or timeout happens in the RHACS validating webhook evaluation.

For a cluster that was installed by using the Operator, in the SecuredCluster custom resource (CR), edit the spec.admissionControl.failurePolicy parameter to Ignore to fail open, or Fail to fail closed.
For a cluster that was installed by using Helm, in the values-public.yaml file, set the admissionControl.failurePolicy value to parameter to Ignore to fail open, or Fail to fail closed. Then then run the following command:
```
helm upgrade -n stackrox \
  stackrox-secured-cluster-services rhacs/secured-cluster-services \
  --reuse-values \
  -f /config/yaml/values-public.yaml \
  -f /config/yaml/values-private.yaml
```
For clusters installed by another method, you can use the RHACS portal to edit the admission controller failure policy. You cannot edit Operator- or Helm-managed clusters by using the portal. Perform these steps:
1. In the RHACS portal, select Platform Configuration Clusters.
2. Click Secure a cluster Legacy installation method.
3. In the Static configuration (requires deployment) section, in the Admission controller failure policy field, select one of the following options:
  - Fail open: If an error or timeout occurs when a workload admission or update request is being evaluated by the validating webhook, the request should be allowed to reach the API server.
  - Fail closed: If an error or timeout occurs when a workload admission or update request is being evaluated by the validating webhook, the request should not be allowed to reach the API server, but should be blocked.
4. Select Next.
5. Select Finish. Because this is a change to the static configuration, you must redeploy the cluster for your changes to take effect.

5.3. Configuring file activity monitoring
Copy link

Configure policies in Red Hat Advanced Cluster Security (RHACS) to detect and alert on sensitive file accesses or operations for containerized workloads or cluster nodes. Define criteria to identify high risk accesses of sensitive files, such as opening a file for writing, file deletion, or permission changes. You can configure the system to send notifications when this activity occurs, and set enforcement actions to automatically block noncompliant workloads.

Important

File activity monitoring is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

Policy criteria might change in future releases as this feature approaches General Availability. If you test this feature in Technology Preview, you might need to perform manual updates before you upgrade. Follow the instructions in the relevant KCS article to maintain your configurations in future versions.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

5.3.1. Detection of unauthorized file modifications
Copy link

Protect your infrastructure by configuring RHACS policies that monitor sensitive file activity. Policies can check custom file paths identified with wildcard patterns. The unified file path criterion that replaces separate effective path and actual path fields enables you to define flexible monitoring rules. These flexible rules can match your specific security and compliance requirements, from individual critical files to entire directory trees. You can detect unauthorized modifications and host breakouts even when attackers try to obscure their targets by using symbolic links or volume mounts.

When creating policies for unauthorized file modifications, you specify file paths by using glob pattern syntax. For example, you add /etc/*.conf or /var/log/app/**/*.log in a single file path field during policy creation. The file activity monitoring system evaluates violations against both the effective path, which is how the process views the file inside the container, and the actual path, which is the true location on the host filesystem. This dual matching ensures comprehensive detection while violation records display both path values for forensic investigation.

You can combine file path patterns with process filtering criteria to create precise policies that reduce false positives from legitimate system operations. Process filters suppress violations when expected processes such as package managers, Operators, or the Machine Config Operator modify monitored files during upgrades or maintenance windows.

Important

To use file activity monitoring, you must have enabled File Activity Monitoring within the per Node Configuration section during secured cluster configuration.

For more information, see "Creating and modifying security policies".

5.3.1.1. Dynamic path support for file activity monitoring
Copy link

RHACS 4.11 enhances the Technology Preview file activity monitoring feature with dynamic path support and process-based filtering. You can now define custom file paths by using wildcard patterns instead of being limited to four fixed critical paths. The unified file path criterion simplifies policy creation by replacing separate effective path and actual path fields, while violation records continue to display both values for forensic analysis.

You can use process filtering to suppress alerts from legitimate system operations such as OpenShift upgrades and package installations. You can configure policies with process name, process ancestor, process arguments, and process UID criteria to reduce false positives while maintaining comprehensive file integrity monitoring coverage.

RHACS file activity monitoring includes the following changes and enhancements:

Node violations are now visible in the RHACS portal Violations page, improving investigation workflows for security teams.
File rename operations are detectable as a distinct file operation type.
File activity violations are supported in the Splunk Technology Add-on 3.0.0 alert data feed. For more information, see "Using the Red Hat Advanced Cluster Security for Kubernetes add-on".

If you are upgrading from RHACS 4.10 with file activity monitoring enabled, you must migrate existing policies to the 4.11 unified file path model. Any policies that use separate effective path and actual path fields are not automatically converted. For migration guidance, see "Migrate file activity monitoring policies from 4.10 to 4.11".

5.3.1.2. Known limitations
Copy link

The following are the known limitations of the file activity monitoring feature:

Architecture support: This feature supports only x86 architecture in RHACS 4.11. On hybrid clusters with multiple architectures, file activity monitoring operates only on x86 nodes. ARM, Power, and Z architecture nodes do not report file activity violations. Future general availability releases might expand architecture support.
Wildcard pattern performance constraints: Patterns exceeding this limit are rejected during policy creation. Under sustained load of 100 file operations per second, the file activity monitoring collector consumes approximately 5% CPU and 200 MB RAM. Exceeding these thresholds might result in missed violations or delayed violation reporting.
Hosted control plane compatibility: File activity monitoring operates on OpenShift cluster worker nodes regardless of whether the control plane is hosted externally (for example, Red Hat Advanced Cluster Security for Kubernetes (RHACS) on Hosted Control Planes). The feature does not monitor control plane file activity, only workloads and system processes running on managed worker nodes. Worker node architecture must be x86 for file activity monitoring to function.
Splunk Technology Add-on integration: File activity violation data requires Splunk Technology Add-on 3.0.0 or later. Earlier versions of the Splunk TA do not support the file activity input type. For more information, see "Install and configure the Splunk add-on".

5.3.2. Create a file activity monitoring policy
Copy link

You can create file activity monitoring policies to detect unauthorized file modifications and host breakouts. Use glob syntax wildcard patterns in your policies to match multiple files or directories with a single pattern, enabling comprehensive monitoring coverage without creating individual policies for each file path.

Prerequisites

RHACS 4.11 or later is installed.
You have identified which files and directories require monitoring based on security policy and compliance requirements.
You understand glob pattern syntax and wildcard matching behavior.
The file activity monitoring setting is enabled in the Per Node Settings section during secured cluster configuration.

Procedure

In the RHACS portal, navigate to Platform Configuration Policy Management.
Click Create policy.
In the Policy name field, enter a descriptive name for the policy purpose.
Select the policy severity.
In the Categories section, select File Activity Monitoring.
Select the Runtime lifecycle stage.
Select the event source:
- Deployment: Select this option to monitor file activity initiated by Kubernetes workloads, such as pods, jobs, or deployments. This source identifies when containers try to change their own files or the underlying host system.
- Node: Select this option to monitor sensitive file activity from processes running directly on the host, such as SSH sessions, systemd services, or standalone scripts.
In the Policy rules section, add the policy fields that you want to use. For this policy, select File activity File path.
Note
The events and violations will show the actual path and effective path, where appropriate. However, the single file path field checks both of these fields.
Enter a file path pattern with optional wildcard characters in glob syntax, as shown in the following examples:
- For exact path matching, enter the full path without wildcards.
  - Example: /etc/ssh/sshd_config
- To match all files in a directory, use a single asterisk.
  - Example: /etc/*.conf
- To match files at any depth in a directory tree, use double asterisks.
  - Example: /var/log/app/*/.log
- To match specific user directories, combine path segments with wildcards.
  - Example: /home/*/.ssh/authorized_keys
Optional: From File operation, select one or more operations to monitor:
- Open (writable) - Detects files opened for writing.
- Create - Detects new file creation.
- Rename - Detects file rename operations. Provides the file that was moved and the location where the file was moved to.
- Delete (Unlink) - Detects file deletion.
- Change permissions - Detects permission modifications.
- Change ownership - Detects ownership changes.
Optional: For node policies, you can create a policy that alerts on file activity from specific processes. For example, you can combine file activity and process filtering to suppress violations from legitimate system operations. For more information, see "Filter file activity by process".
Click Save.

Verification

Trigger a test file operation that matches your configured pattern to verify the policy functions correctly.
Navigate to Violations in the RHACS portal.
If you configured a policy for deployment policies:
1. Select the User Workloads tab.
2. Verify that a violation was created with the expected file path that matches your wildcard pattern.
If you configured a policy for node file activity monitoring:
1. Select the Nodes tab.
2. Verify that a violation record is displayed with the expected file path that matches your configured wildcard pattern.

5.3.3. Process filtering for file activity policies
Copy link

File activity monitoring policies support process-based filtering to reduce false positive alerts from legitimate system operations. You can configure policies to suppress violations when specific processes, process ancestors, process UIDs, or process arguments match expected patterns during maintenance windows or system upgrades. This capability enables you to maintain comprehensive file integrity monitoring coverage while minimizing alert fatigue from authorized changes.

Process filtering works by adding process criteria to file activity policies with the file path and file operation criteria. When a file operation occurs, RHACS evaluates all configured criteria. If the operation matches the file criteria but the initiating process matches the exclusion filter, no violation is generated.

5.3.3.1. Available process filtering criteria
Copy link

RHACS supports four process-based criteria for file activity policy filtering:

Process name: Filters based on the executable name of the process that performed the file operation. Use this criterion to exclude known system components such as rpm, dpkg, or operator binaries.
Process ancestor: Filters based on parent or ancestor processes in the process tree. Use this criterion to exclude all operations initiated by specific management frameworks, such as the Machine Config Operator (MCO) on OpenShift clusters.
Process arguments: Filters based on command-line arguments passed to the process. Use this criterion to distinguish between different invocations of the same binary, such as excluding systemctl daemon-reload while monitoring other systemctl operations.
Process UID: Filters based on the numeric user ID of the process. Use this criterion to allow privileged system maintenance (UID 0) while detecting unprivileged user attempts to modify protected files.

5.3.3.2. Common use cases for process filtering
Copy link

Suppress OpenShift upgrade activity: During OpenShift cluster upgrades, the MCO modifies system configuration files as part of normal upgrade procedures. You can filter violations by adding a process ancestor criterion matching the MCO binary to prevent alert storms during planned maintenance.
Exclude package manager operations: System administrators regularly install and update packages by using yum, dnf, or rpm on cluster nodes. You can filter violations by adding a process name criterion matching the package management tools to allow these expected modifications while detecting unauthorized changes.
Allow Operator-initiated changes: Kubernetes operators frequently update application configuration files as part of their reconciliation loops. You can filter violations by adding process name or process ancestor criteria matching the Operator binary to distinguish between automated configuration management and potential security incidents.
Detect privilege escalation attempts: You can monitor sensitive files for modifications while excluding expected system daemon activity by combining file path patterns with process UID filters. For example, monitor /etc/sudoers modifications and exclude UID 0 operations to detect unprivileged who are attempting privilege escalation.

5.3.3.3. Combining file path and process filters
Copy link

Process filtering becomes most effective when combined with targeted file path patterns and specific file operation selections. This layered approach creates precise policies that balance security coverage with operational noise reduction.

For example, you can create a policy that performs the following tasks:

Monitors all configuration files matching /etc/*.conf
Triggers on change permissions and change ownership operations
Excludes operations initiated by the Machine Config Operator

This policy detects unauthorized permission changes while ignoring legitimate system maintenance, reducing false positives without sacrificing security visibility.

Note

Process filtering criteria use the same matching logic as other RHACS policy criteria. You can configure multiple process filters in a single policy, and all configured criteria must match for a violation to be suppressed.

5.3.3.4. Create file activity policies with process filters
Copy link

You can create file activity monitoring policies that combine file path patterns, file operation selections, and process filtering criteria to achieve precise security coverage with minimal false positives. With this layered approach, you can monitor sensitive files while suppressing violations from expected system maintenance and Operator activity.

Prerequisites

RHACS 4.11 or later is installed.
You understand which files require monitoring based on security and compliance requirements.
You understand which processes initiate legitimate modifications to monitored files.
The file activity monitoring setting is enabled in the Per Node Settings section during secured cluster configuration.

Procedure

In the RHACS portal, navigate to Platform Configuration Policy Management.
Click Create policy.
In the Policy name field, enter a descriptive name for the policy purpose.
Select the policy severity.
In the Categories section, select File Activity Monitoring.
Select the Runtime lifecycle stage.
Select the Node event source.
In the Policy rules section, add the policy fields that you want to use. For this policy, select File activity File path.
In the File path field, enter a wildcard pattern matching the files you want to monitor. For example, enter /etc/*.conf to match all configuration files in the /etc/ directory.
In File operation, select the operations you want to alert on that indicate security risks. For example, select Change permissions and Change ownership to detect unauthorized attempts to escalate privileges or modify file access controls.
Configure the process activity filtering by selecting one or more criteria. In the criterion value field, enter the process identifier to exclude. For example, select Process ancestor and enter machine-config-daemon to suppress violations during OpenShift cluster upgrades. You can configure the following criteria:
- Process name: Filters by executable name
- Process ancestor: Filters by parent process
- Process arguments: Filters by command-line arguments
- Process UID: Filters by user ID
Optional: Add additional process filtering criteria to create more precise exclusion rules. For example, add a Process name criterion with value rpm and add another Process name criterion with value dnf to suppress violations from both Red Hat Package Manager and Dandified YUM operations.
Click Save.

Verification

Trigger a file operation from an unfiltered process that matches your configured file criteria, for example:
```
$ touch /etc/test.conf && chmod 777 /etc/test.conf
```
Navigate to Violations in the RHACS portal.
Verify that a violation record is displayed with the file path and operation details.
Trigger a file operation from a filtered process to verify the process filter is working.
For example, to simulate package installation:
```
# rpm -i example-package.rpm
```
Navigate to Violations in the RHACS portal.
Verify that no violation is displayed for the filtered process operation.

5.3.3.4.1. Policies with process filter examples
Copy link

You can combine file path, operations, and process name criteria to create file activity monitoring policies that provide alerts with fewer false positives.

The following example policy configurations show common file activity monitoring scenarios with process filtering:

Monitor SSH authorized keys changes excluding system daemons

File path: /home/*/.ssh/authorized_keys
File operations: Create, Delete (unlink), Change permissions
Process name: sshd (negated to exclude SSH daemon)
Event source: Node

This policy detects unauthorized SSH key additions while allowing SSH daemon operations.

Monitor application log rotation excluding system log managers

File path: /var/log/app/*/.log
File operations: Rename, Delete (unlink)
Process ancestor: logrotate
Event source: Deployment

This policy detects unauthorized log file deletion or tampering while allowing scheduled log rotation.

Monitor container configuration files excluding Operator updates

File path: /opt/app/config/*.yaml
File operations: Open (writable), Create, Delete (unlink)
Process name: app-operator
Event source: Deployment

This policy detects unauthorized configuration changes while allowing the application Operator to manage configuration files.

5.3.4. Migrate file activity monitoring policies from 4.10 to 4.11
Copy link

You can migrate file activity monitoring policies from RHACS release 4.10 to release 4.11. To migrate, re-create policies by using the unified file path criterion with wildcard patterns.

The underlying policy data model changed in release 4.11 to support custom paths and process filtering, requiring manual migration from the fixed four-path model used in release 4.10. To use your existing policies, you must complete these steps before upgrading to release 4.11.

Prerequisites

You understand which files and operations that your 4.10 policies monitored.
You understand glob pattern syntax for creating wildcard patterns.

Procedure

Inventory your existing 4.10 file activity policies:
1. In the RHACS portal, navigate to Platform Configuration Policy Management.
2. Filter policies by the File Activity Monitoring category.
3. For each file activity policy, record:
  - The effective path or actual path values configured
  - The file operation selections, such as Open, Create, Delete, Change permissions, or Change ownership
  - The event source selection (Deployment or Node)
  - Any observed false positive patterns during 4.10 usage
Map 4.10 fixed paths to 4.11 wildcard patterns. Review each monitored path and determine whether you can expand coverage using wildcard patterns:
- For paths monitoring specific files, use the exact path without wildcards.
- For paths monitoring configuration directories, consider patterns such as /etc/*.conf to match all configuration files.
- For paths monitoring application logs, consider recursive patterns such as /var/log/app/*/.log to match logs at any depth.
Create new 4.11 file activity policies:
1. Click Create policy.
2. In the Policy name field, enter a name for the migrated policy purpose.
3. Verify that the correct severity is selected.
4. In the Categories section, select File Activity Monitoring.
5. Verify that the correct lifecycle stage is selected.
6. Select the same Event source value configured in your 4.10 policy.
7. In the Policy rules section, add a File path criterion with the correct wildcard pattern.
8. Select the same File operation values configured in your 4.10 policy.
9. Optional: Add process filtering criteria to suppress false positives observed during 4.10 usage:
  - To exclude Machine Config Operator activity during OpenShift upgrades, add a Process ancestor criterion with value machine-config-daemon.
  - To exclude package manager operations, add a Process name criterion with value rpm or dnf.
  - To exclude operator-initiated changes, add a Process name criterion matching the operator binary.
10. Click Save.
Test your migrated policies:
1. Trigger a file operation that should generate a violation based on your policy configuration.
2. Navigate to Violations in the RHACS portal.
3. Verify that the new 4.11 policy generates violations with expected path values.
4. Trigger a file operation that matches your process filter criteria.
5. Verify that no violation is displayed for filtered processes, confirming that process filters suppress expected activity.
Disable or delete 4.10 policies:
1. After verifying that 4.11 policies provide equal or better security coverage, disable your 4.10 file activity policies by setting them to Disabled.
2. Optional: Delete 4.10 policies after a suitable observation period confirms that 4.11 policies meet your monitoring requirements.

Verification

Navigate to Violations in the RHACS portal.
Verify that file activity violations appear for unauthorized modifications while expected system operations do not trigger violations.
Compare the volume of violations from 4.11 policies to 4.10 baseline levels.
Verify that wildcard patterns detect file operations across multiple files as intended.

5.4. Creating and modifying security policies
Copy link

Create custom security policies in the RHACS portal to enforce configuration rules and minimize risks. Define detailed criteria, lifecycle stages, and automated enforcement options to detect and block noncompliant images or workloads. By using these policies, you support consistent security standards across the build, deploy, and runtime phases.

5.4.1. Creating a security policy from the system policies view
Copy link

Define a new security policy in the RHACS portal to enforce security rules in your environment. Go to Policy Management to create a new policy and enter the required definition information. You can manage security settings by creating policies in the Platform Configuration Policy page.

Procedure

In the RHACS portal, go to Platform Configuration Policy Management.
Click Create policy.
Configure the policy definition information in the following sections.

5.4.1.1. Entering policy details
Copy link

Configure the core attributes of your custom security policy to ensure exact threat classification. Assign a severity level and offer clear remediation guidance to resolve policy violations effectively. Additionally, specify MITRE ATT&CK tactics and techniques to contextualize the potential security risk.

Procedure

Enter a Name for the policy. A policy must have a name between 5 and 128 characters, and cannot contain new lines or dollar signs.
Select a Severity level for the policy.
From the Select categories list, select a category for the policy. You can select one or more categories for the policy.
Enter details about the policy in the Description field.
Enter an explanation about why the policy exists in the Rationale field.
Enter steps to resolve violations of the policy in the Guidance field.
Select the tactic and the techniques you want to specify for the policy:
1. From the Add tactic list, select a tactic.
2. From the Add technique list, select a technique for the tactic. You can specify one or more techniques for a tactic.
Click Next.

5.4.1.2. Selecting the policy lifecycle stage
Copy link

Define when RHACS evaluates policies by assigning a specific lifecycle stage. You can target these specific phases to inspect images during the continuous integration (CI) process or monitor workload activity on a live node, ensuring that enforcement actions occur at the appropriate time.

For more information, see "Understanding the RHACS policy evaluation engine".

Procedure

Select the Lifecycle stages for the policy:
The following options are associated with the lifecycle stages:
Build
Policies in this stage inspect image criteria such as the image registry, content, vulnerability data, and the scanning process. The CI pipeline evaluates these policies during the build process. If you enable enforcement, a policy violation fails the build. RHACS does not store violations from this stage.
Deploy
Policies in this stage inspect workload configurations and their images. RHACS evaluates these policies when you create or update a workload resource and re-evaluates them periodically or on-demand. When you enable enforcement, a policy violation causes the admission controller to reject the deployment or update try, or scale the workload replicas to zero.
Build and Deploy
Select this stage if you want your policy to inspect images in both the build pipeline and during workload admission, and to apply enforcement to either or both stages.
Runtime
Policies in this stage inspect either workload activity or Kubernetes resource operations associated with the following event sources:
Deployment
To use runtime policies for workload activity, you must include at least one workload activity criterion. You can combine workload activity criteria with image or workload configuration criteria. If you enable enforcement, RHACS terminates the offending pod, and the orchestrator then re-creates the pod.
Audit logs
Runtime policies that evaluate Kubernetes resource operations look for sensitive operations by using the Kubernetes audit log. You cannot configure enforcement for policies that use this source, because the operations have already occurred. Audit log policies support cluster and namespace scoping, but not deployment-level scoping, because audit events operate at the Kubernetes API level rather than at the deployment level.
Node
Runtime policies that monitor file activity on the host operating system of your Kubernetes nodes. These policies detect unauthorized file operations, such as changes to sensitive system files, by using the actual file path on the host. Policies that use this event source do not support automated enforcement or exclusions in the RHACS console.
Click Next.

5.4.1.3. Configuring policy rules
Copy link

To control when a policy is triggered, configure the specific conditions and rules that apply to your environment. You can customize these rules by dragging and dropping policy fields, such as networking or workload activity, to define criteria appropriate for the build or runtime lifecycle stages.

Procedure

Configure the conditions that you want to trigger the policy. You can edit the rule titles; for example, you can change Rule 1 to something more descriptive.
For each rule, click and drag policy fields into the policy section to add policy fields or criteria.
Note
The policy fields that are available depend on the lifecycle stage you chose for the policy. For example, the criteria associated to Networking or Workload activity are available when creating a policy for the runtime lifecycle, but not when creating a policy for the build lifecycle. For more information about policy criteria, including information about criteria and the lifecycle phase in which they are available, see "Policy criteria".
For each field, you can select from options that are specific to the field. These differ depending on the type of field. For example:
- The default behavior for a value that is a string is to match on a policy field, and select the Not checkbox to indicate when you do not want the field to match.
- Some fields contain a value that is either true or false.
- Some fields require you to select a value from a drop-down list.
- If you select an attribute with Boolean values, such as Read-Only Root Filesystem, the READ-ONLY and WRITABLE options are available.
- If you select an attribute with compound values, such as Environment variable, you can enter values for the Key, Value, and Value From fields, and then click the icon to add more values for the available options.
  Note
  For more information about values available for policy criteria, see "Policy criteria".
To combine multiple values for an attribute, click the Add value of policy field icon.
Optional: To add an additional rule, click Add a new rule .
Click Next.

5.4.1.4. Configuring policy resources
Copy link

Define the policy resources to target the resources in your environment that you want to monitor. You can configure the policy to include specific clusters and namespaces and identify the cluster or namespace by name or by label. Labels are a key/value pair that RHACS sources from Kubernetes cluster or namespace data, or Helm chart values for Helm-based deployments. You can also configure the policy to include deployments with a specified label.

The following guidelines apply:

Policies automatically apply to new resources based on metadata labels without requiring policy updates. By configuring these resources, you ensure that the policy triggers violations only for relevant resources.
If you do not configure any resource rules, the policy applies globally to all secured clusters, all namespaces, and all deployments. This is the default behavior.
The node event source does not support resource scoping.
Audit log event source policies support cluster and namespace scoping, but not deployment-level scoping.
Cluster-scoped resources (for example, ClusterRoles) ignore namespace-level matchers.

The following restrictions apply:

Label-based resource targeting is not supported on secured clusters installed by using the manifest install method. Only Helm and Operator-based installations support label-based targeting.
Cluster and namespace resource targeting (both name-based and label-based) only applies to deploy-time and runtime policies. Build-time policies do not evaluate cluster or namespace scopes.

You can use these fields to make sure policies apply to only the clusters that you want. For example, to apply a policy to all clusters except a specific development cluster, leave Included resources empty (policies apply to all clusters by default). Then, add an Excluded resources rule specifying the cluster name. This configuration applies the policy globally except to the named cluster.

For more information about using cluster and namespace labels to scope policies, see "Policy resource evaluation logic".

Prerequisites

Cluster labels and namespace labels require the following:
- Both Central and secured clusters must run RHACS 4.11 or later
- You install secured clusters by using Helm or the Operator (manifest, or roxctl installation, is not supported)
Secured clusters running earlier versions or that you installed by using the manifest install method ignore the cluster label and namespace label fields in resource rules.

Procedure

You can configure the resources to which your policy applies.
1. Included resources: To specify resources to include in the policy, select Add inclusion and configure the policy to specify certain clusters, namespaces, or deployments:
  - Cluster: To select resources from a specified cluster, configure one of the following options:
    By name: Select a specific cluster by name.
    By label: Target a cluster by label key=value pairs (for example, environment=production). RHACS sources cluster labels from the Kubernetes cluster metadata; for example, labels on the SecuredCluster custom resource for Operator deployments, or Helm chart values for Helm-based deployments.
  - Namespace: To select resources from specified namespaces, select one of the following options:
    By name: Target a namespace by name. You can use regular expression in RE2 syntax in this field.
    By label: Target a namespace by label key=value pairs (for example, compliance=pci). For example, to restrict a policy to production clusters with PCI compliance namespaces, add a resource rule with cluster label environment=production and namespace label compliance=pci.
  - Deployment label: To select resources from deployments with a specific label, you can enter the label, or key=value pair.
    Within a single resource rule, the system combines the cluster, namespace, and deployment label criteria by using AND logic. If you add multiple resource rules, the policy applies to resources matching ANY of the resource rules (OR logic). After adding a resource rule, you can click Add resource rule to add additional rules.
Excluded resources: To configure the policy to not apply to specific resources, you can exclude them. The policy will not apply to the entities you select. To exclude specific resources from the policy:
1. Select Add exclusion and configure the policy to specify certain clusters, namespaces, or deployments:
  - Cluster: To exclude resources from a specified cluster, select a specific cluster by name. You cannot use labels to target clusters to exclude.
  - Namespace: To exclude resources from specified namespaces, enter the namespace name. You can use regular expression in RE2 syntax in this field.
  - Deployment: To exclude specific deployments from the policy, enter the deployment name. You can use regular expression in RE2 syntax in this field. For example, to exclude test namespaces, add an exclusion rule with the namespace name pattern test-.*.
  - Deployment label: To exclude deployments with a specific label, you can enter the label, or key=value pair.
Exclude images: To exclude specific images from the policy, you can specify them. This setting only applies when you check images in a continuous integration system with the Build lifecycle stage. It does not have any effect if you use this policy to check running deployments in the Deploy lifecycle stage or runtime activities in the Runtime lifecycle stage. To exclude specific images from the policy, select them from the list of images.

5.4.1.4.1. Policy resource evaluation logic
Copy link

RHACS evaluates policy resource rules by combining cluster ID or labels, namespace name or labels, and deployment labels to find the resources that a policy applies to. Understanding the evaluation logic helps you design resource rules that target the intended resources without unintended matches or exclusions.

A policy resource rule consists of up to three types of selection criteria: cluster selection, namespace selection, and deployment label selection. RHACS combines these criteria by using AND logic and OR logic to find whether a policy applies to a specific resource.

5.4.1.4.1.1. Resource rule structure
Copy link

Within a single resource rule, RHACS combines the specified criteria by using AND logic. For example, (Cluster ID OR Cluster label) AND (Namespace name OR Namespace label) AND (Deployment label) means that a deployment must match all specified criteria within a resource rule for the policy to apply.

If a field is not specified in a resource rule, it matches all resources of that type. For example, a resource rule with only cluster label environment=production (no namespace or deployment criteria) applies to all namespaces and all deployments on clusters labeled environment=production.

Important

You cannot specify both cluster ID and cluster label in the same resource rule. Similarly, you cannot specify both namespace name and namespace label in the same resource rule. These fields are mutually exclusive within a single rule. If you specify both in the RHACS web console or via the API, the system prevents you from saving the policy configuration with a validation error.

If you add multiple resource rules to a policy, RHACS combines the rules by using OR logic. A deployment matches the policy if it satisfies any one of the resource rules.

For example, a policy with two resource rules applies to deployments that match either rule:

Rule 1: Cluster label environment=production AND Namespace label compliance=pci
Rule 2: Cluster ID staging-cluster-1 AND Namespace name pci-test

This policy applies to the following entities:

All deployments in namespaces labeled compliance=pci on clusters labeled environment=production, OR
All deployments in the pci-test namespace on the staging-cluster-1 cluster

5.4.1.4.1.2. Label matching
Copy link

Cluster labels and namespace labels use exact key=value matching. When you specify a label such as environment=production, the policy applies only to resources with that exact label key and value. For example, for the label selector environment=production:

This policy applies to resources that match clusters or namespaces with the label environment=production.
This policy does not match resources with environment=prod or environment=production-east.

Namespace names and deployment labels support regular expressions by using RE2 syntax.

5.4.1.4.2. Policy resource label syntax reference
Copy link

This reference provides syntax examples for cluster labels and namespace labels in policy resource rules. Use these patterns to configure label-based policy targeting.

5.4.1.4.2.1. Label format
Copy link

Policy resource labels use the key=value format. Both cluster labels and namespace labels use exact string matching.

Label matching is case-sensitive. The label key Environment is different from the key environment.

5.4.1.4.2.2. Common label patterns
Copy link

The following table shows common label patterns for policy resource configuration:

Expand

Table 5.1. Policy resource label patterns
Use case	Cluster label example	Namespace label example
Environment targeting	`environment=production`	`environment=staging`
Compliance zone	`compliance=pci`	`compliance=hipaa`
Geographic region	`region=us-east-1`	`region=eu-west-1`
Team or organization	`owner=platform-team`	`team=security`
Application grouping	`app=medical-portal`	`app=financial-api`

5.4.1.4.2.3. Label examples
Copy link

The following examples show policy resource labels:

Target production clusters: environment=production. This matches clusters with the exact label environment=production.
PCI compliance: compliance=pci. This matches namespaces with the exact label compliance=pci.
Target namespaces owned by the security team: team=security: This matches namespaces with the exact label team=security.

5.4.1.4.2.4. Mutual exclusivity rules
Copy link

When configuring policy scope rules, note the following mutual exclusivity constraints:

You cannot specify both cluster ID and cluster label in the same resource rule. Choose one cluster selection method per rule.
You cannot specify both namespace name and namespace label in the same resource rule. Choose one namespace selection method per rule.
You can combine cluster label AND namespace label AND deployment label in a single resource rule.
Label-based targeting is only available for included resources in RHACS 4.11. Excluded resources do not support cluster label or namespace label targeting.

If you need to target resources by using both ID-based and label-based criteria, create multiple resource rules. RHACS combines multiple resource rules with OR logic.

Example: To target a specific staging cluster by ID and all production clusters by label, create two resource rules:

Rule 1: Cluster ID staging-cluster-1
Rule 2: Cluster label environment=production

5.4.1.4.2.5. Managing cluster and namespace labels
Copy link

RHACS sources the cluster labels used for policy resource targeting from Kubernetes cluster metadata:

For Operator-based secured cluster deployments: Define labels on the SecuredCluster custom resource
For Helm-based secured cluster deployments: Define labels in Helm chart values

RHACS sources namespace labels from Kubernetes namespace metadata.

To verify the labels that are available for targeting:

Navigate to Platform Configuration Clusters to view cluster labels.
Use kubectl get namespace <namespace_name> --show-labels to view namespace labels.

5.4.1.5. Enable the policy
Copy link

Apply the configured rules to your environment by activating the policy. You can enable the policy to enforce these settings or disable the policy to stop its application.

Procedure

Select whether to enable or disable the policy:
- To enable the policy, select Enable.
- To disable the policy, select Disable.

5.4.1.6. Configuring policy enforcement
Copy link

To address security violations effectively, configure RHACS to apply specific enforcement behaviors across the build, deploy, and runtime lifecycles. You can adjust the configuration to receive alerts for violations or automatically block noncompliant images and workloads to stop them from entering your environment. Implementing these controls ensures that your clusters remain secure and compliant with your defined policies.

Procedure

Select a method to address the violations of the policy:
Note
Enforcement is not available for node event sources.
Inform
Include the violation in the violations list.
Inform and enforce
Include the violation in the violation list and enforce actions that you have configured. If you select this option, you must select the enforcement behavior for the policy by using the toggle for the appropriate lifecycles.
If you select policy enforcement, configure the enforcement behavior. The enforcement behavior you can select depends on the lifecycle stages you selected for the policy in the Lifecycle section of the policy definition.
The following enforcement behaviors are available depending on the lifecycle stage:
Build
Set Enforce on Build to on to have RHACS fail your continuous integration (CI) builds when images match the criteria of the policy. You can download the roxctl CLI and configure the roxctl image check command to work with the policy.
Deploy
Set Enforce on Deploy to on to have RHACS block any workload admissions or updates that match the policy criteria. You must configure and run the RHACS admission controller for this enforcement to take effect.
In clusters with admission controller enforcement, the Kubernetes or OpenShift Container Platform API server blocks all noncompliant deployments. In clusters without admission controller enforcement, RHACS modifies noncompliant deployments to prevent pods from scheduling.
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 "Deploy stage enforcement".
Runtime
Set Enforce on Runtime to on to have RHACS delete all pods when an event in the pods matches the criteria of the policy.
Warning
Policy enforcement can impact running applications or development processes. Before you enable enforcement options, inform all stakeholders and plan how to respond to automated enforcement actions.

5.4.1.7. Selecting policy notifiers
Copy link

To receive alerts by email or an external tool when a policy violation occurs, select notifiers from the available list. These integrations notify you immediately of compliance events so you can respond quickly.

Prerequisite

You have configured the notifier before it is visible and available to select in the list. You configure these integrations in the Platform Configuration Integrations page, in the Notifier Integrations section.

Procedure

Select one or more notifiers for RHACS to use to inform you when a policy violation occurs.
Click Next.

5.4.1.8. Reviewing the policy and previewing violations
Copy link

To ensure the policy is working correctly, verify the configuration options and examine potential violations in the Preview policy violations panel. Validate the build and deploy phase results to confirm the accuracy of the policy before you save the changes.

Procedure

Verify that the policy configuration is configured with the correct options.
View the results in the Preview policy violations panel to ensure that the policy is working. This panel provides additional information, including whether build phase or deploy phase deployments have policy violations.
Note
Runtime violations are not available in this preview because they are generated when events occur in the future.
Before you save the policy, verify that the violations seem accurate.
Click Save.

5.4.1.9. Verifying file activity policies
Copy link

You can verify that your file activity policies are functioning correctly by manually triggering a violation on a monitored component.

Prerequisites

You have configured a file activity policy for a Deployment or Node event source.
You have identified the specific files and operations monitored by your policy.
You have access to the command line interface of the monitored node or deployment.

Procedure

Trigger a file activity violation on a monitored node or deployment by running the following command, for example:
```
$ touch /etc/passwd
```
Choose the appropriate method to confirm that the alert is displayed:
- For deployment policies, complete the following steps:
  1. In the RHACS portal, click Violations.
  2. Verify that the alert is displayed in the list.
- For node policies, verify that the notifier has received an alert, or query the alerts API to locate the violation JSON data.
  Note
  The RHACS portal does not display node violations. To view these alerts, use the API or configured notifiers.

5.4.2. Creating a security policy from the risk view
Copy link

You can generate a new security policy directly from the Risk view in the RHACS portal to address specific security concerns. Use this method to create a policy based on the local page filtering criteria you apply to your risk data, ensuring the policy targets the specific risks you are analyzing.

Procedure

In the RHACS portal, click Risk.
Apply the local page filtering criteria that you want to create a policy for. For example, you can filter by using criteria such as a specific CVE, a cluster, a deployment, an image, or various other criteria.
Click Create policy and complete the required fields to create a new policy. For the steps to create a policy, see "Creating a security policy from the system policies view".

5.4.3. Modifying existing security policies
Copy link

You can update security configurations in the RHACS portal to adapt to changing security requirements. Select a specific policy to edit its fields and save your changes. To customize a default system policy, you must clone the policy to create an editable copy.

Procedure

In the RHACS portal, click Platform Configuration Policy Management.
Select the policy you want to edit.
From the Actions list, select Edit policy.
Note
You cannot edit certain fields of default system policies. To make changes to a default policy, clone the policy and edit the copy.
Edit the fields that you want to change, and then click Save.

5.4.3.1. Disabling a policy
Copy link

Disable a policy in the RHACS portal to prevent the system from using it when evaluating workload operations. To deactivate the policy, edit the policy behavior settings and turn off the activation state.

Procedure

In the RHACS portal, click Platform Configuration Policy Management. For default policies, you cannot edit enforcement options.
Select the policy you want to edit.
From the Actions list, select Edit policy.
Expand Policy behavior, and then select Actions.
In the Activation state field, select Disable.
Save the policy.

5.4.3.2. Creating policy categories by using the Policy categories tab
Copy link

You can create policy categories by using the Policy categories tab. You can also configure policy categories by using the PolicyCategoryService API object. For more information, go to Help API reference in the RHACS portal.

Procedure

In the RHACS portal, go to Platform Configuration Policy Management.
Click the Policy categories tab. This tab provides a list of existing categories and allows you to filter the list by category name. You can also click Show all categories and select the checkbox to remove default or custom categories from the displayed list.
Click Create category.
Enter a category name and click Create.

5.4.3.3. Modifying policy categories by using the Policy categories tab
Copy link

You can modify policy categories by using the policy categories tab. You can also configure policy categories by using the PolicyCategoryService API object. For more information, go to Help API reference in the RHACS portal.

Procedure

In the RHACS portal, go to Platform Configuration Policy Management.
Click the Policy categories tab. This tab provides a list of existing categories and allows you to filter the list by category name. You can also click Show all categories and select the checkbox to remove default or custom categories from the displayed list.
Click a policy name to edit or delete it. Default policy categories cannot be selected, edited, or deleted.

5.5. Managing policies as code
Copy link

You can create and manage policies as code by saving policies as Kubernetes custom resources (CRs) and applying them to clusters by using a Kubernetes-native continuous delivery (CD) tool such as Argo CD.

5.5.1. Managing polices as code
Copy link

Policy as code is useful for Kubernetes security architects who want to author policies in YAML or JSON instead of using the RHACS portal. GitOps administrators who already manage Kubernetes configurations by using a GitOps workflow can also find it useful.

RHACS provides the ability to use default policies or create custom policies for your system. With the policy as code feature, you can create custom policies locally by downloading them and modifying them, or by creating them from empty files. To author policies locally, you create CRs that represent the desired state of the policies. You then use a continuous delivery tool such as Argo CD to track, manage, and apply policies to your clusters that are running RHACS. After you create or update CRs and use the CI/CD tool to apply them, the policies stored in the RHACS database are created or updated.

With this feature, RHACS installs a new Kubernetes controller in the namespace where Central is installed, typically the stackrox namespace. With an Argo CD workflow, you configure Argo CD to apply policy as code resources to the same namespace in which RHACS is installed. After you configure this connection, the controller in RHACS receives information from the Kubernetes API about new, updated, or deleted policies that are managed as individual Kubernetes CR files. RHACS reconciles the policy CR to the policy stored in the RHACS database.

With a GitOps workflow that does not use Argo CD, you configure your GitOps repository to connect to Central in RHACS through the RHACS API. A CR is not used.

5.5.1.1. About policy drift
Copy link

Because policies can be edited, deleted, and created in the RHACS portal and also externally, sometimes policy drift can occur. Drift occurs when the version of a policy in Central in RHACS does not match the version of the policy in Kubernetes.

Drift can occur when a change is applied to an externally-managed policy by using the RHACS portal or the API instead of by modifying its Kubernetes custom resource. RHACS does not prevent drift, but it is not recommended. Drift is automatically resolved within ten hours after it was introduced.

5.5.1.2. Creating policies in code by using the RHACS portal
Copy link

You can create new policies in code by using the RHACS portal to save existing policies as YAML files.

Prerequisites

You must have RHACS release 4.6 or later installed.
If you installed RHACS by using the manifest installation method, also called the roxctl method, you must manually apply the config.stackrox.io CRD that is located in the .zip file at helm/chart/crds/config.stackrox.io_securitypolicies.yaml by using the following command:
```
$ kubectl create -f helm/chart/crds/config.stackrox.io_securitypolicies.yaml
```

Procedure

To create a new policy in code by using the RHACS portal to create the CR:

In the Policy Management page, create a new policy or clone a default policy.
Note
You must clone a default policy before you can save it as a CR.
In the row listing the policy, click the overflow menu, , and then select Save as Custom Resource. To save multiple policies at one time, you can select them and click Bulk actions Save as Custom Resources.
After editing your policy, you can apply the saved CR by doing one of the following:
- Use the oc apply or kubectl apply command to apply the CR directly to the Kubernetes namespace where Central is installed.
- Use Argo CD or your GitOps tool to push the CR to the Kubernetes namespace where Central is installed.

5.5.1.3. Creating policies in code by constructing a CR
Copy link

You can create new policies in code by constructing a CR for the policy.

Use an editor to construct a CR for the policy with the following attributes:
```
kind: SecurityPolicy
apiVersion: config.stackrox.io/v1alpha1
metadata:
  name: short-name
spec:
  policyName: A longer form name
# ...
```
Tip
Use online documentation, for example, by entering the kubectl explain securitypolicy.spec command, to understand the fields available for defining a policy specification.
Apply the saved CR by doing one of the following:
- Use the oc apply or kubectl apply command to apply the CR directly to the Kubernetes namespace where Central is installed.
- Use Argo CD or your GitOps tool to push the CR to the Kubernetes namespace where Central is installed.

5.5.1.4. Disabling the policy as code feature
Copy link

The policy as code feature is automatically enabled when you install RHACS, but you can disable it.

Note

For OpenShift Container Platform, use oc instead of kubectl.

Procedure

To disable the policy as code feature, complete one of the following tasks, depending on the method you used to install RHACS:

If you installed RHACS by using the Operator, set the spec.configAsCode.configAsCodeComponent field to Disabled.
If you installed RHACS by using Helm charts, set the configAsCode.enabled field in the values.yaml file to false.
If you installed RHACS by using the manifest installation method, also known as the roxctl method, delete the config-controller deployment by running the following command:
```
$ kubectl -n stackrox delete deployment config-controller
```

5.6. Security policy reference
Copy link

You can use policy categories to manage your policies. Security criteria are available to use in building custom policies. Different criteria are available, depending on the policy lifecycle stage. Lists of default security policies, or policies that are included in the system by default, are provided and organized by severity.

5.6.1. Policy categories
Copy link

RHACS uses policy categories to group policies by type and function. You can use these categories to organize and search for policies.

RHACS provides the following default policy categories:

Anomalous Activity
Cryptocurrency Mining
DevOps Best Practices
Docker Center for Internet Security (CIS)
File Activity Monitoring
Kubernetes
Kubernetes Events
Network Tools
Package Management
Privileges
Security Best Practices
Supply Chain Security
System Modification
Vulnerability Management
Zero Trust

You can view existing categories and create your own policy categories in the RHACS portal by using the Policy Categories tab in the Policy Management window.

5.6.2. Policy criteria
Copy link

You can set up rules in RHACS and configure the data on which you want to trigger a policy. This data is also referred to as policy criteria or policy fields.

You can configure the policy based on the attributes listed in the following table.

In this table:

The Regular expressions, AND, OR, and NOT columns indicate whether you can use regular expressions and other logical operators along with the specific attribute.
- ! for Regex (Regular expressions) indicates that you can only use regular expressions for the listed fields.
- ! for AND, or OR indicates that you can only use the mentioned logical operator for the attribute.
- ✕ in the Regex / NOT / AND, OR column indicates that the attribute does not support any of those (regex, negation, logical operators).
The RHACS version column indicates the version of Red Hat Advanced Cluster Security for Kubernetes that you must have to use the attribute.
You cannot use logical combination operators AND and OR for attributes that have:
- Boolean values true and false
- Minimum-value semantics, for example:
  - Minimum RBAC permissions
  - Days since image was created
You cannot use the NOT logical operator for attributes that have:
- Boolean values true and false
- Numeric values that already use comparison, such as the <, >, <=, >= operators.
- Compound criteria that can have multiple values, for example:
  - Dockerfile line, which includes both instructions and arguments.
  - Environment variable, which consists of both name and value.
- Other meanings, including Add capabilities, Drop capabilities, Days since image was created, and Days since image was last scanned.

5.6.2.1. Image criteria
Copy link

Image registry

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Image registry	The name of the image registry.	Image Registry	String	Regex, NOT, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Image name	The full name of the image in registry, for example `library/nginx`.	Image Remote	String	Regex, NOT, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Image tag	Identifier for an image.	Image Tag	String	Regex, NOT, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Require image signature	The list of signature integrations you can use to verify an image’s signature. Create alerts on images that either do not have a signature or their signature is not verifiable by at least one of the provided signature integrations.	Image Signature Verified By	A valid ID of an already configured image signature integration	! `OR` only	Build, Deploy, Runtime (when used with a Runtime criterion)

Image contents

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Image age	The minimum number of days from image creation date.	Image Age	Integer	✕	Build, Deploy, Runtime (when used with a Runtime criterion)
Image user	Matches the USER directive in the Dockerfile. See https://docs.docker.com/engine/reference/builder/#user for details .	Image User	String	Regex, NOT, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Dockerfile line	A specific line in the Dockerfile, including both instructions and arguments.	Dockerfile Line	One of: LABEL, RUN, CMD, EXPOSE, ENV, ADD, COPY, ENTRYPOINT, VOLUME, USER, WORKDIR, ONBUILD	! Regex only for values, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Image component	Name and version number of a specific software component present in an image.	Image Component	key=value Value is optional. If value is missing, it must be in format "key=".	Regex, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Image OS	Name and version number of the base operating system of the image. For example, `alpine:3.17.3`	Image OS	String	Regex, NOT, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Require image label	Ensure the presence of a Docker image label. The policy triggers if any image in the deployment does not have the specified label. You can use regular expressions for both key and value fields to match labels. The `Require Image Label` policy criteria only works when you integrate with a Docker registry. For details about Docker labels see Docker documentation, https://docs.docker.com/config/labels-custom-metadata/.	Required Image Label	key=value Value is optional. If value is missing, it must be in format "key=".	Regex, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Disallow image label	Ensure that a particular Docker image label is NOT used. The policy triggers if any image in the deployment has the specified label. You can use regular expressions for both key and value fields to match labels. The 'Disallow Image Label policy' criteria only works when you integrate with a Docker registry. For details about Docker labels see Docker documentation, https://docs.docker.com/config/labels-custom-metadata/.	Disallowed Image Label	key=value Value is optional. If value is missing, it must be in format "key=".	Regex, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)

Image scanning

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Image scan age	The minimum number of days since the image was last scanned.	Image Scan Age	Integer	✕	Build, Deploy, Runtime (when used with a Runtime criterion)
Image scan status	Check if an image was scanned.	Unscanned Image	Boolean	✕	Build, Deploy, Runtime (when used with a Runtime criterion)
Common Vulnerability Scoring System (CVSS)	CVSS: Use it to match images with vulnerabilities whose scores are greater than `>`, less than `<`, or equal to `=` the specified CVSS.	CVSS	<, >, <=, >= or nothing (which implies equal to) — and — a decimal (a number with an optional fractional value). Examples: >=5, or 9.5	AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
National Vulnerability Database (NVD) CVSS	Requires Scanner V4. NVD CVSS: Use it to match images with vulnerabilities reported by NVD whose scores are greater than `>`, less than `<`, or equal to `=` the specified CVSS.	CVSS	<, >, <=, >= or nothing (which implies equal to) — and — a decimal (a number with an optional fractional value). Examples: >=5, or 9.5	AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Severity	The severity of the vulnerability based on the CVSS or the vendor. Can be one of Low, Moderate, Important or Critical.	Severity	<, >, ⇐, >= or nothing (which implies equal to) — and — One of: UNKNOWN LOW MODERATE IMPORTANT CRITICAL Examples: >=IMPORTANT, or CRITICAL	AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Fixable	This criterion results in a violation only if the image in the deployment you are evaluating has a fixable CVE.	Fixable	Boolean	✕	Build, Deploy, Runtime (when used with a Runtime criterion)
Fixed by	The version string of a package that fixes a flagged vulnerability in an image. This criterion may be used in addition to other criteria that identify a vulnerability, for example using the CVE criterion.	Fixed By	String	Regex, NOT, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
CVE	Common Vulnerabilities and Exposures, use it with specific CVE numbers.	CVE	String	Regex, NOT, AND, OR	Build, Deploy, Runtime (when used with a Runtime criterion)
Days since CVE was published	This criterion results in a violation only if it has been more than a specified number of days since RHACS was first published.	Days Since CVE Was First Published	Integer	✕	Build, Deploy, Runtime (when used with a Runtime criterion)
Days since CVE was first discovered in image	This criterion results in a violation only if it has been more than a specified number of days since RHACS discovered the CVE in a specific image.	Days Since CVE Was First Discovered In Image	Integer	✕	Build, Deploy, Runtime (when used with a Runtime criterion)
Days since CVE was first discovered in system	This criterion results in a violation only if it has been more than a specified number of days since RHACS discovered the CVE across all deployed images in all clusters that RHACS monitors.	Days Since CVE Was First Discovered In System	Integer	✕	Build, Deploy, Runtime (when used with a Runtime criterion)
Days since CVE fix was available	This criterion results in a violation if it has been more than a specified number of days since the date when the CVE fix became available. Use this criterion to create a custom grace period for fixing vulnerabilities. For vulnerabilities that are associated with Red Hat packages, CVE fix dates are included in the vulnerability information. For non Red Hat packages, the fix date is approximated as follows: For existing CVEs, RHACS records the date that the status changed from `not fixable` to `fixable`. For new and fixable CVEs, RHACS records the date that the CVE was discovered in RHACS.	Days Since CVE Fix Was Available	Integer	X	Build, Deploy, Runtime (when used with a Runtime criterion)

5.6.2.2. Workload configuration criteria
Copy link

Container configuration

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Environment variable	Check environment variables by name or value. When you create a policy that includes the environment variable attribute, you can choose which types of environment variables the policy should match. For example, you can specify raw values, which are provided directly in the deployment YAML, or you can specify references to values from config maps, secrets, fields, or resource requests or limits. For any type other than a raw value specified directly in the deployment YAML, the corresponding `value` attribute of the policy rule is ignored. In this case, the policy match is evaluated on the existence of the specified environment variable type. Additionally, this criteria disallows the creation of policies with a non-empty `value` attribute for types other than raw values.	Environment Variable	RAW=key=value to match an environment variable as directly specified in the deployment YAML with a specific key and value. You can omit the `value` attribute to match on only the key. If the environment variable is not defined in the configuration YAML, then you can use the format `SOURCE=KEY`, where `SOURCE` is one of the following objects: SECRET_KEY (SecretKeyRef) CONFIG_MAP_KEY (ConfigMapRef) FIELD (FieldRef) RESOURCE_FIELD (ResourceFieldRef) The preceding list provides the API object label first, and then provides the user interface label in parentheses.	! Regex only for key and value (if using RAW) AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Container CPU request	Check for the number of cores reserved for a given resource.	Container CPU Request	<, >, ⇐, >= or nothing (which implies equal to) — and — A decimal (a number with an optional fractional value) Examples: >=5, or 9.5	AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Container CPU limit	Check for the maximum number of cores a resource is allowed to use.	Container CPU Limit	(Same as Container CPU Request)	AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Container memory request	Number, including fraction, of MB requested.	Container Memory Request	(Same as Container CPU Request)	AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Container memory limit	Check for the maximum amount of memory a resource is allowed to use.	Container Memory Limit	(Same as Container CPU Request)	AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Privileged container	Check if a deployment is configured in privileged mode. This criterion only checks the value of the `privileged` field in the respective Pod Security Context.	Privileged Container	Boolean: `true` when the value of the `privileged` field in the respective `PodSecurityContext` is set to `true`	✕	Deploy, Runtime (when used with a Runtime criterion)
Root filesystem writeability	Check if a deployment is configured in the `readOnlyFilesystem` mode.	Read-Only Root Filesystem	Boolean: `true` when the value of the `readOnlyRootFilesystem` field in the respective `PodSecurityContext` is set to `true`	✕	Deploy, Runtime (when used with a Runtime criterion)
Seccomp profile type	The type of `seccomp` profile defined for the deployment. If `seccomp` options are provided at both the pod and container level, the container options override the pod options. See Security Context.	Seccomp Profile Type	One of: UNCONFINED RUNTIME_DEFAULT LOCALHOST	✕	Deploy, Runtime (when used with a Runtime criterion)
Privilege escalation	Provides alerts when a deployment allows a container process to gain more privileges than its parent process.	Allow Privilege Escalation	Boolean	✕	Deploy, Runtime (when used with a Runtime criterion)
Drop capabilities	Linux capabilities that must be dropped from the container. Provides alerts when the specified capabilities are not dropped. For example, if configured with `SYS_ADMIN` AND `SYS_BOOT`, and the deployment drops only one or neither of these two capabilities, the alert occurs.	Drop Capabilities	One of: ALL AUDIT_CONTROL AUDIT_READ AUDIT_WRITE BLOCK_SUSPEND CHOWN DAC_OVERRIDE DAC_READ_SEARCH FOWNER FSETID IPC_LOCK IPC_OWNER KILL LEASE LINUX_IMMUTABLE MAC_ADMIN MAC_OVERRIDE MKNOD NET_ADMIN NET_BIND_SERVICE NET_BROADCAST NET_RAW SETGID SETFCAP SETPCAP SETUID SYS_ADMIN SYS_BOOT SYS_CHROOT SYS_MODULE SYS_NICE SYS_PACCT SYS_PTRACE SYS_RAWIO SYS_RESOURCE SYS_TIME SYS_TTY_CONFIG SYSLOG WAKE_ALARM	AND	Deploy, Runtime (when used with a Runtime criterion)
Add capabilities	Linux capabilities that must not be added to the container, such as the ability to send raw packets or override file permissions. Provides alerts when the specified capabilities are added. For example, if configured with `NET_ADMIN` or `NET_RAW`, and the deployment manifest YAML file includes at least one of these two capabilities, the alert occurs.	Add Capabilities	AUDIT_CONTROL AUDIT_READ AUDIT_WRITE BLOCK_SUSPEND CHOWN DAC_OVERRIDE DAC_READ_SEARCH FOWNER FSETID IPC_LOCK IPC_OWNER KILL LEASE LINUX_IMMUTABLE MAC_ADMIN MAC_OVERRIDE MKNOD NET_ADMIN NET_BIND_SERVICE NET_BROADCAST NET_RAW SETGID SETFCAP SETPCAP SETUID SYS_ADMIN SYS_BOOT SYS_CHROOT SYS_MODULE SYS_PACCT SYS_PTRACE SYS_RAWIO SYS_RESOURCE SYS_TIME SYS_TTY_CONFIG SYSLOG WAKE_ALARM	OR	Deploy, Runtime (when used with a Runtime criterion)
Container name	The name of the container.	Container Name	String	Regex, NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
AppArmor profile	The Application Armor ("AppArmor") profile used in the container.	AppArmor Profile	String	Regex, NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Liveness probe	Whether the container defines a liveness probe.	Liveness Probe	Boolean	✕	Deploy, Runtime (when used with a Runtime criterion)
Readiness probe	Whether the container defines a readiness probe.	Readiness Probe	Boolean	✕	Deploy, Runtime (when used with a Runtime criterion)

Deployment metadata

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Disallowed annotation	An annotation which is not allowed to be present on Kubernetes resources in a specified environment.	Disallowed Annotation	key=value Value is optional. If value is missing, it must be in format "key=".	Regex, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Required label	Check for the presence of a required label in Kubernetes.	Required Label	key=value Value is optional. If value is missing, it must be in format "key=".	Regex, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Required annotation	Check for the presence of a required annotation in Kubernetes.	Required Annotation	key=value Value is optional. If value is missing, it must be in format "key=".	Regex, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Runtime class	The `RuntimeClass` of the deployment.	Runtime Class	String	Regex, NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Host network	Check if `HostNetwork` is enabled which means that the container is not placed inside a separate network stack (for example, the container’s networking is not containerized). This implies that the container has full access to the host’s network interfaces.	Host Network	Boolean	✕	Deploy, Runtime (when used with a Runtime criterion)
Host PID	Check if the Process ID (PID) namespace is isolated between the containers and the host. This allows for processes in different PID namespaces to have the same PID.	Host PID	Boolean	✕	Deploy, Runtime (when used with a Runtime criterion)
Host IPC	Check if the IPC (POSIX/SysV IPC) namespace (which provides separation of named shared memory segments, semaphores and message queues) on the host is shared with containers.	Host IPC	Boolean	✕	Deploy, Runtime (when used with a Runtime criterion)
Namespace	The name of the namespace the deployment belongs to.	Namespace	String	Regex, NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Replicas	The number of deployment replicas. If you use `oc scale` to scale the deployment replicas from 0 to a number, then the admission controller blocks this action if the deployment violates a policy.	Replicas	<, >, ⇐, >= or nothing (which implies equal to) — and — a decimal (a number with an optional fractional value). Examples: >=5, or 9.5	NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)

Storage

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Volume name	Name of the storage.	Volume Name	String	Regex, NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Volume source path	The volume’s path on the host.	Volume Source	String	Regex, NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Volume destination path	The path where the volume is mounted.	Volume Destination	String	Regex, NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Volume type	Indicates the form in which the volume is provisioned. For example, `persistentVolumeClaim` or `hostPath`.	Volume Type	String	Regex, NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Mounted volume writability	Volumes that are mounted as writable.	Writable Mounted Volume	Boolean	✕	Deploy, Runtime (when used with a Runtime criterion)
Mount propagation	Check if container is mounting volumes in `Bidirectional`, `Host to Container`, or `None` modes.	Mount Propagation	One of: NONE HOSTTOCONTAINER BIDIRECTIONAL	NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Host mount writability	Resource has mounted a path on the host with write permissions.	Writable Host Mount	Boolean	✕	Deploy, Runtime (when used with a Runtime criterion)
Section: Networking
Exposed port protocol	Protocol, such as TCP or UDP, that is used by the exposed port.	Exposed Port Protocol	String	Regex, NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Exposed node port	Port numbers exposed externally by a deployment.	Exposed Node Port	(Same as Exposed Port)	NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Exposed port	Port numbers exposed by a deployment.	Exposed Port	<, >, ⇐, >= or nothing (which implies equal to) — and — an integer. Examples: >=1024, or 22	NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Port exposure method	Exposure method of the service, for example, load balancer or node port.	Port Exposure Method	One of: Route LoadBalancer NodePort HostPort Exposure type is not set	NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Ingress network policy	Check the presence or absence of ingress Kubernetes network policies.	Has Ingress Network Policy	Boolean	Regex, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Egress network policy	Check the presence or absence of egress Kubernetes network policies.	Has Egress Network Policy	Boolean	Regex, AND, OR	Deploy, Runtime (when used with a Runtime criterion)

Access control

Expand

Attribute Description JSON Attribute Allowed Values Regex, NOT, AND, OR Phase

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Service account	The name of the service account.	Service Account	String	Regex, NOT, AND, OR	Deploy, Runtime (when used with a Runtime criterion)
Automount service account token	Check if the deployment configuration automatically mounts the service account token.	Automount Service Account Token	Boolean	✕	Deploy, Runtime (when used with a Runtime criterion)
Minimum RBAC permissions	Match if the deployment’s Kubernetes service account has Kubernetes RBAC permission level equal to `=` or greater than `>` the specified level.	Minimum RBAC Permissions	One of: DEFAULT ELEVATED_IN_NAMESPACE ELEVATED_CLUSTER_WIDE CLUSTER_ADMIN	NOT	Deploy, Runtime (when used with a Runtime criterion)

Service account

The name of the service account.

Service Account

String

Regex,
NOT,
AND, OR

Deploy,
Runtime (when used with a Runtime criterion)

Automount service account token

Check if the deployment configuration automatically mounts the service account token.

Automount Service Account Token

Boolean

Deploy,
Runtime (when used with a Runtime criterion)

Minimum RBAC permissions

Match if the deployment’s Kubernetes service account has Kubernetes RBAC permission level equal to = or greater than > the specified level.

Minimum RBAC Permissions

One of:

DEFAULT ELEVATED_IN_NAMESPACE ELEVATED_CLUSTER_WIDE CLUSTER_ADMIN

NOT

Deploy,
Runtime (when used with a Runtime criterion)

5.6.2.3. Workload activity criteria
Copy link

Process activity

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Process name	Name of the process executed in a deployment.	Process Name	String	Regex, NOT, AND, OR	Runtime ONLY - Process
Process ancestor	Name of any parent process for a process executed in a deployment.	Process Ancestor	String	Regex, NOT, AND, OR	Runtime ONLY - Process
Process arguments	Command arguments for a process executed in a deployment.	Process Arguments	String	Regex, NOT, AND, OR	Runtime ONLY - Process
Process UID	Unix user ID for a process executed in a deployment.	Process UID	Integer	NOT, AND, OR	Runtime ONLY - Process

Baseline deviation

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Unexpected network flow detected	Check if the detected network traffic is part of the network baseline for the deployment.	Unexpected Network Flow Detected	Boolean	✕	Runtime ONLY - Network
Unexpected process executed	Check deployments for which process executions are not listed in the deployment’s locked process baseline.	Unexpected Process Executed	Boolean	✕	Runtime ONLY - Process

User issued container commands

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Kubernetes action	The name of the Kubernetes action, such as `Pod Exec`.	Kubernetes Resource	One of: PODS_ATTACH PODS_EXEC PODS_PORTFORWARD	! `OR` only	Runtime ONLY - Kubernetes Events
Kubernetes API verb	Do not use; not valid for runtime policies.	Kubernetes API Verb	N/A	N/A	N/A
Kubernetes user name	The name of the user who accessed the resource.	Kubernetes User Name	Alphanumeric with hyphens (-) and colon (:) only	Regex, NOT, ! `OR` only	Runtime ONLY - Kubernetes Events
Kubernetes user group	The name of the group to which the user who accessed the resource belongs to.	Kubernetes User Groups	Alphanumeric with hyphens (-) and colon (:) only	Regex, NOT, ! `OR` only	Runtime ONLY - Kubernetes Events

File activity

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Effective path	The file path as it appears to the process inside the container.	Effective Path	One of: /etc/passwd /etc/ssh/sshd_config /etc/shadow /etc/sudoers	AND, OR	Runtime
Actual path	The physical location of the file on the file system of the node.	Actual Path	One of: /etc/passwd /etc/ssh/sshd_config /etc/shadow /etc/sudoers	AND, OR	Runtime
File operation	The specific action performed on the file, such as creating, deleting, or modifying permissions and ownership. When using the File operation criteria, you must specify at least one value for either Effective path or Actual path.	File Operation	One of: Open (Writable) Create Delete Permission change Ownership change	AND, OR	Runtime

Attribute

Description

JSON Attribute

Allowed Values

Regex, NOT, AND, OR

Phase

Effective path

The file path as it appears to the process inside the container.

Effective Path

One of:

/etc/passwd /etc/ssh/sshd_config /etc/shadow /etc/sudoers

AND, OR

Runtime

Actual path

The physical location of the file on the file system of the node.

Actual Path

One of:

/etc/passwd /etc/ssh/sshd_config /etc/shadow /etc/sudoers

AND, OR

Runtime

File operation

The specific action performed on the file, such as creating, deleting, or modifying permissions and ownership. When using the File operation criteria, you must specify at least one value for either Effective path or Actual path.

File Operation

One of:

Open (Writable) Create Delete Permission change Ownership change

AND, OR

Runtime

5.6.2.4. Audit log: Kubernetes resource operations
Copy link

You can also use cluster and namespace label scoping; see "Configuring policy resources" for more information.

Resource operation (Required)

Expand

Attribute Description JSON Attribute Allowed Values Regex, NOT, AND, OR Phase

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Kubernetes API verb	The Kubernetes API verb that is used to access the resource, such as `GET` or `POST`.	Kubernetes API Verb	One of: CREATE DELETE GET PATCH UPDATE	! `OR` only	Runtime ONLY - Audit Log
Kubernetes resource type	Type of the accessed Kubernetes resource.	Kubernetes Resource	One of: CONFIGMAPS SECRETS CLUSTERROLES CLUSTERROLEBINDINGS NETWORKPOLICIES SECURITYCONTEXTCONSTRAINTS EGRESSFIREWALLS	! `OR` only	Runtime ONLY - Audit Log

Kubernetes API verb

The Kubernetes API verb that is used to access the resource, such as GET or POST.

Kubernetes API Verb

One of:

CREATE DELETE GET PATCH UPDATE

! OR only

Runtime ONLY - Audit Log

Kubernetes resource type

Type of the accessed Kubernetes resource.

Kubernetes Resource

One of:

CONFIGMAPS SECRETS CLUSTERROLES CLUSTERROLEBINDINGS NETWORKPOLICIES SECURITYCONTEXTCONSTRAINTS EGRESSFIREWALLS

! OR only

Runtime ONLY - Audit Log

Resource attributes

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Kubernetes resource name	The name of the accessed Kubernetes resource.	Kubernetes Resource Name	Alphanumeric with hyphens (-) and colon (:) only	Regex, NOT, ! `OR` only	Runtime ONLY - Audit Log
Kubernetes user name	The name of the user who accessed the resource.	Kubernetes User Name	Alphanumeric with hyphens (-) and colon (:) only	Regex, NOT, ! `OR` only	Runtime ONLY - Kubernetes Events
Kubernetes user groups	The name of the group to which the user who accessed the resource belongs to.	Kubernetes User Groups	Alphanumeric with hyphens (-) and colon (:) only	Regex, NOT, ! `OR` only	Runtime ONLY - Kubernetes Events
User agent	The user agent that the user used to access the resource. For example `oc`, or `kubectl`.	User Agent	String	Regex, NOT, ! `OR` only	Runtime ONLY - Audit Log
Source IP address	The IP address from which the user accessed the resource.	Source IP Address	IPV4 or IPV6 address	Regex, NOT, ! `OR` only	Runtime ONLY - Audit Log
Is impersonated user	Check if the request was made by a user that is impersonated by a service account or some other account.	Is Impersonated User	Boolean	✕	Runtime ONLY - Audit Log

5.6.2.5. Node activity criteria
Copy link

File activity

Expand

Attribute	Description	JSON Attribute	Allowed Values	Regex, NOT, AND, OR	Phase
Actual path	The physical location of the file on the file system of the node or the underlying mount.	Actual Path	One of: /etc/passwd /etc/ssh/sshd_config /etc/shadow /etc/sudoers	AND, OR	Runtime
File operation	The specific action performed on the file, such as creating, deleting, or modifying permissions and ownership. When using the File operation criteria, you must specify at least one value for the Actual path.	File Operation	One of: Open (Writable) Create Delete Permission change Ownership change	AND, OR	Runtime

Attribute

Description

JSON Attribute

Allowed Values

Regex, NOT, AND, OR

Phase

Actual path

The physical location of the file on the file system of the node or the underlying mount.

Actual Path

One of:

/etc/passwd /etc/ssh/sshd_config /etc/shadow /etc/sudoers

AND, OR

Runtime

File operation

File Operation

One of:

Open (Writable) Create Delete Permission change Ownership change

AND, OR

Runtime

5.6.3. Default security policies
Copy link

Note

The severity levels for policies in Red Hat Advanced Cluster Security for Kubernetes are different from the severity levels that Red Hat Product Security assigns.

The Red Hat Advanced Cluster Security for Kubernetes policy severity levels are Critical, High, Medium, and Low. Red Hat Product Security rates vulnerability severity levels as Critical, Important, Moderate, and Low.

While a policy’s severity level and the Red Hat Product Security severity levels can interact, it is important to distinguish between them. For more information about the Red Hat Product Security severity levels, see Severity Ratings.

5.6.3.1. Critical severity security policies
Copy link

The following table lists the default security policies in Red Hat Advanced Cluster Security for Kubernetes that are of critical severity. The policies are organized by lifecycle stage.

Expand

Table 5.2. Critical severity security policies
Life cycle stage	Name	Description	Status
Build or Deploy	Apache Struts: CVE-2017-5638	Alerts when deployments have images that contain the CVE-2017-5638 Apache Struts vulnerability.	Enabled
Build or Deploy	Log4Shell: log4j Remote Code Execution vulnerability	Alerts when deployments include images that contain the CVE-2021-44228 and CVE-2021-45046 Log4Shell vulnerabilities. Flaws exist in the Apache Log4j Java logging library in versions 2.0-beta9 - 2.15.0, excluding version 2.12.2.	Enabled
Build or Deploy	Spring4Shell (Spring Framework Remote Code Execution) and Spring Cloud Function vulnerabilities	Alerts when deployments include images that contain either the CVE-2022-22965 vulnerability, which affects Spring MVC, and the CVE-2022-22963 vulnerability, which affects Spring Cloud. In versions 3.16, 3.2.2, and older unsupported versions, Spring Cloud contains flaws. Flaws exist in Spring Framework in versions 5.3.0 - 5.3.17, versions 5.2.0 - 5.2.19, and in older unsupported versions.	Enabled
Runtime	Iptables Executed in Privileged Container	Alerts when privileged pods run iptables.	Enabled

5.6.3.2. High severity security policies
Copy link

The following table lists the default security policies in Red Hat Advanced Cluster Security for Kubernetes that are of high severity. The policies are organized by lifecycle stage.

Expand

Table 5.3. High severity security policies
Life cycle stage	Name	Description	Status
Build or Deploy	Fixable Common Vulnerability Scoring System (CVSS) >= 7	Alerts when deployments with fixable vulnerabilities have a CVSS of at least 7. However, Red Hat recommends that you create policies using Common Vulnerabilities and Exposures (CVE) severity instead of CVSS score.	Disabled
Build or Deploy	Fixable Severity at least Important	Alerts when deployments with fixable vulnerabilities have a severity rating of at least Important.	Enabled
Build or Deploy	Rapid Reset: Denial of Service Vulnerability in HTTP/2 Protocol	Alerts on deployments with images containing components that are susceptible to a Denial of Service (DoS) vulnerability for HTTP/2 servers. This addresses a flaw in the handling of multiplexed streams in HTTP/2. A client can rapidly create a request and immediately reset them, which creates extra work for the server while avoiding hitting any server-side limits, resulting in a denial of service attack. To use this policy, consider cloning the policy and adding the `Fixable` policy criteria before enabling it.	Disabled
Build or Deploy	Secure Shell (ssh) Port Exposed in Image	Alerts when deployments expose port 22, which is commonly reserved for SSH access.	Enabled
Build or Deploy	Red Hat Images must be signed by the Red Hat Release Key	Alerts when a Red Hat image is not signed by the official Red Hat product signing key, "Release Key 3". These alerts apply to images from the following registries and remotes: `registry.redhat.io` `registry.access.redhat.com` `quay.io/openshift-release-dev/ocp-release` `quay.io/openshift-release-dev/ocp-v4.0-art-dev`	Disabled
Deploy	Emergency Deployment Annotation	Alerts when deployments use the emergency annotation, such as "admission.stackrox.io/break-glass":"ticket-1234" to circumvent StackRox Admission controller checks.	Enabled
Deploy	Environment Variable Contains Secret	Alerts when deployments have environment variables that contain 'SECRET'.	Enabled
Deploy	Fixable CVSS >= 6 and Privileged	Alerts when deployments run in privileged mode with fixable vulnerabilities that have a CVSS of at least 6. However, Red Hat recommends that you create policies using CVE severity instead of CVSS score.	Disabled by default in version 3.72.0 and later
Deploy	Privileged Containers with Important and Critical Fixable CVEs	Alerts when containers that run in privileged mode have important or critical fixable vulnerabilities.	Enabled
Deploy	Secret Mounted as Environment Variable	Alerts when a deployment has a Kubernetes secret that is mounted as an environment variable.	Disabled
Deploy	Secure Shell (ssh) Port Exposed	Alerts when deployments expose port 22, which is commonly reserved for SSH access.	Enabled
Runtime	Cryptocurrency Mining Process Execution	Spawns the crypto-currency mining process.	Enabled
Runtime	iptables Execution	Detects when someone runs iptables, which is a deprecated way of managing network states in containers.	Enabled
Runtime	Kubernetes Actions: Attach to Pod	Alerts when the Kubernetes API receives a request to attach to a container.	Enabled
Runtime	Kubernetes Actions: Exec into Pod	Alerts when the Kubernetes API receives a request to run a command in a container.	Enabled
Runtime	Linux Group Add Execution	Detects when someone runs the addgroup or groupadd binary to add a Linux group.	Enabled
Runtime	Linux User Add Execution	Detects when someone runs the useradd or adduser binary to add a Linux user.	Enabled
Runtime	Login Binaries	Indicates when someone tries to log in.	Disabled
Runtime	Network Management Execution	Detects when someone runs binary files that can manipulate network configuration and management.	Enabled
Runtime	nmap Execution	Alerts when someone starts the nmap process in a container during run time.	Enabled
Runtime	OpenShift: Kubeadmin Secret Accessed	Alerts when someone accesses the kubeadmin secret.	Enabled
Runtime	Password Binaries	Indicates when someone attempts to change a password.	Disabled
Runtime	Process Targeting Cluster Kubelet Endpoint	Detects the misuse of the healthz, kubelet API, or heapster endpoint.	Enabled
Runtime	Process Targeting Cluster Kubernetes Docker Stats Endpoint	Detects the misuse of the Kubernetes docker stats endpoint.	Enabled
Runtime	Process Targeting Kubernetes Service Endpoint	Detects the misuse of the Kubernetes Service API endpoint.	Enabled
Runtime	Process with UID 0	Alerts when deployments contain processes that run with UID 0.	Disabled
Runtime	Secure Shell Server (sshd) Execution	Detects containers that run the SSH daemon.	Enabled
Runtime	SetUID Processes	Use setuid binary files, which permit people to run certain programs with escalated privileges.	Disabled
Runtime	Shadow File Modification	Indicates when someone tries to modify shadow files.	Disabled
Runtime	Shell Spawned by Java Application	Detects when a shell, such as bash, csh, sh, or zsh, is run as a subprocess of a Java application.	Enabled
Runtime	Unauthorized Network Flow	Generates a violation for any network flows that fall outside of the baselines of the "alert on anomalous violations" setting.	Enabled
Runtime	Unauthorized Processed Execution	Generates a violation for any process execution that is not explicitly allowed by a locked process baseline for a container specification in a Kubernetes deployment.	Enabled

5.6.3.3. Medium severity security policies
Copy link

The following table lists the default security policies in Red Hat Advanced Cluster Security for Kubernetes that are of medium severity. The policies are organized by lifecycle stage.

Expand

Table 5.4. Medium severity security policies
Life cycle stage	Name	Description	Status
Build	Docker CIS 4.4: Ensure images are scanned and rebuilt to include security patches	Alerts when images are not scanned and rebuilt to include security patches. It is important to scan images often to find vulnerabilities, rebuild the images to include security patches, and then instantiate containers for the images.	Disabled
Deploy	30-Day Scan Age	Alerts when a deployment has not been scanned in 30 days.	Enabled
Deploy	CAP_SYS_ADMIN capability added	Alerts when a deployment includes containers that are escalating with CAP_SYS_ADMIN.	Enabled
Deploy	Container using read-write root filesystem	Alerts when a deployment includes containers that have read-write root file systems.	Disabled
Deploy	Container with privilege escalation allowed	Alerts when a container might be running with unintended privileges, creating a security risk. This situation can happen when a container process that has more privileges than its parent process allows the container to run with unintended privileges.	Enabled
Deploy	Deployments should have at least one Ingress Network Policy	Alerts if deployments are missing an Ingress Network Policy.	Disabled
Deploy	Deployments with externally exposed endpoints	Detects if a deployment has any service that is externally exposed through any methods. Deployments with services exposed outside of the cluster are at a higher risk of attempted intrusions because they are reachable outside of the cluster. This policy provides an alert so that you can verify that service exposure outside of the cluster is required. If the service is only needed for intra-cluster communication, use service type ClusterIP.	Disabled
Deploy	Docker CIS 5.1: Ensure that, if applicable, an AppArmor profile is enabled	Uses AppArmor to protect the Linux operating system and applications by enforcing a security policy that is known as an AppArmor profile. AppArmor is a Linux application security system that is available on some Linux distributions by default, such as Debian and Ubuntu.	Enabled
Deploy	Docker CIS 5.15: Ensure that the host’s process namespace is not shared	Creates process-level isolation between the containers and the host. The Process ID (PID) namespace isolates the process ID space, which means that processes in different PID namespaces can have the same PID.	Enabled
Deploy	Docker CIS 5.16: Ensure that the host’s IPC namespace is not shared	Alerts when the IPC namespace on the host is shared with containers. The IPC (POSIX/SysV IPC) namespace separates named shared memory segments, semaphores, and message queues.	Enabled
Deploy	Docker CIS 5.19: Ensure mount propagation mode is not enabled	Alerts when mount propagation mode is enabled. When mount propagation mode is enabled, you can mount container volumes in Bidirectional, Host to Container, and None modes. Do not use Bidirectional mount propagation mode unless it is explicitly needed.	Enabled
Deploy	Docker CIS 5.21: Ensure the default seccomp profile is not disabled	Alerts when the seccomp profile is disabled. The seccomp profile uses an allowlist to permit common system calls and blocks all others.	Disabled
Deploy	Docker CIS 5.7: Ensure privileged ports are not mapped within containers	Alerts when privileged ports are mapped within containers. The TCP/IP port numbers that are lower than 1024 are privileged ports. Normal users and processes can not use them for security reasons, but containers might map their ports to privileged ports.	Enabled
Deploy	Docker CIS 5.9 and 5.20: Ensure that the host’s network namespace is not shared	Alerts when the host’s network namespace is shared. When HostNetwork is enabled, the container is not placed inside a separate network stack, and the container’s networking is not containerized. As a result, the container has full access to the host’s network interfaces, and a shared UTS namespace is enabled. The UTS namespace provides isolation between the hostname and the NIS domain name, and it sets the hostname and the domain, which are visible to running processes in that namespace. Processes that run within containers do not typically require to know the hostname or the domain name, so the UTS namespace should not be shared with the host.	Enabled
Deploy	Images with no scans	Alerts when a deployment includes images that were not scanned.	Disabled
Runtime	Kubernetes Actions: Port Forward to Pod	Alerts when the Kubernetes API receives a port forward request.	Enabled
Deploy	Mount Container Runtime Socket	Alerts when a deployment has a volume mount on the container runtime socket.	Enabled
Deploy	Mounting Sensitive Host Directories	Alerts when a deployment mounts sensitive host directories.	Enabled
Deploy	No resource requests or limits specified	Alerts when a deployment includes containers that do not have resource requests and limits.	Enabled
Deploy	Pod Service Account Token Automatically Mounted	Protects pod default service account tokens from being compromised by minimizing the mounting of the default service account token to only those pods whose applications require interaction with the Kubernetes API.	Enabled
Deploy	Privileged Container	Alerts when a deployment includes containers that run in privileged mode.	Enabled
Runtime	crontab Execution	Detects the usage of the crontab scheduled jobs editor.	Enabled
Runtime	Netcat Execution Detected	Detects when netcat runs in a container.	Enabled
Runtime	OpenShift: Advanced Cluster Security Central Admin Secret Accessed	Alerts when someone accesses the Red Hat Advanced Cluster Security Central secret.	Enabled
Runtime	OpenShift: Kubernetes Secret Accessed by an Impersonated User	Alerts when someone impersonates a user to access a secret in the cluster.	Enabled
Runtime	Remote File Copy Binary Execution	Alerts when a deployment runs a remote file copy tool.	Enabled

5.6.3.4. Low severity security policies
Copy link

The following table lists the default security policies in Red Hat Advanced Cluster Security for Kubernetes that are of low severity. The policies are organized by lifecycle stage.

Expand

Table 5.5. Low severity security policies
Life cycle stage	Name	Description	Status
Build or Deploy	90-Day Image Age	Alerts when a deployment has not been updated in 90 days.	Enabled
Build or Deploy	ADD Command used instead of COPY	Alerts when an image was built by using an `ADD` command.	Disabled
Build or Deploy	Alpine Linux Package Manager (apk) in Image	Alerts when a deployment includes the Alpine Linux package manager (apk).	Enabled
Build or Deploy	Curl in Image	Alerts when a deployment includes curl.	Disabled
Build or Deploy	Docker CIS 4.1: Ensure That a User for the Container Has Been Created	Ensures that containers are running as non-root users.	Enabled
Build or Deploy	Docker CIS 4.7: Alert on Update Instruction	Ensures that update instructions are not used alone in the Dockerfile.	Enabled
Build or Deploy	Insecure specified in CMD	Alerts when a deployment uses 'insecure' in the command.	Enabled
Build or Deploy	Latest tag	Alerts when a deployment includes images that use the 'latest' tag.	Enabled
Build or Deploy	Red Hat Package Manager in Image	Alerts when a deployment includes components of the Red Hat, Fedora, or CentOS package management system.	Enabled
Build or Deploy	Required Image Label	Alerts when a deployment includes images that are missing the specified label.	Disabled
Build or Deploy	Ubuntu Package Manager Execution	Detects the usage of the Ubuntu package management system.	Enabled
Build or Deploy	Ubuntu Package Manager in Image	Alerts when a deployment includes components of the Debian or Ubuntu package management system in the image.	Enabled
Build or Deploy	Wget in Image	Alerts when a deployment includes wget.	Disabled
Deploy	Drop All Capabilities	Alerts when a deployment does not drop all capabilities.	Disabled
Deploy	Improper Usage of Orchestrator Secrets Volume	Alerts when a deployment uses a Dockerfile with 'VOLUME /run/secrets'.	Enabled
Deploy	Kubernetes Dashboard Deployed	Alerts when a Kubernetes dashboard service is detected.	Enabled
Deploy	Required Annotation: Email	Alerts when a deployment is missing the 'email' annotation.	Disabled
Deploy	Required Annotation: Owner/Team	Alerts when a deployment is missing the 'owner' or 'team' annotation.	Disabled
Deploy	Required Label: Owner/Team	Alerts when a deployment is missing the 'owner' or 'team' label.	Disabled
Runtime	Alpine Linux Package Manager Execution	Alerts when the Alpine Linux package manager (apk) is run at run time.	Enabled
Runtime	chkconfig Execution	Detects the usage of the ckconfig service manager, which is typically not used in a container.	Enabled
Runtime	Compiler Tool Execution	Alerts when binary files that compile software are run at run time.	Enabled
Runtime	Red Hat Package Manager Execution	Alerts when Red Hat, Fedora, or CentOS package manager programs are run at run time.	Enabled
Runtime	Shell Management	Alerts when commands are run to add or remove a shell.	Disabled
Runtime	systemctl Execution	Detects the usage of the systemctl service manager.	Enabled
Runtime	systemd Execution	Detects the usage of the systemd service manager.	Enabled

Chapter 5. Using policies to provide security

5.1. About policies in RHACSCopy linkLink copied to clipboard!

5.1.1. Understanding the RHACS policy evaluation engineCopy linkLink copied to clipboard!

5.1.2. About policy enforcementCopy linkLink copied to clipboard!

5.1.2.1. Build stage enforcementCopy linkLink copied to clipboard!

5.1.2.2. Deploy stage enforcementCopy linkLink copied to clipboard!

5.1.2.2.1. Hard enforcementCopy linkLink copied to clipboard!

5.1.2.2.2. Namespace exclusions from admission controller enforcementCopy linkLink copied to clipboard!

5.1.2.2.3. Enforcement on existing deploymentsCopy linkLink copied to clipboard!

5.1.2.2.4. Soft enforcementCopy linkLink copied to clipboard!

5.1.2.3. Runtime enforcementCopy linkLink copied to clipboard!

5.1.3. RHACS policy structureCopy linkLink copied to clipboard!

5.1.3.1. Policy definitionCopy linkLink copied to clipboard!

5.1.3.2. Policy behaviorCopy linkLink copied to clipboard!

5.1.4. Policy and violation managementCopy linkLink copied to clipboard!

5.1.4.1. Setting policy rulesCopy linkLink copied to clipboard!

5.1.5. Default security policiesCopy linkLink copied to clipboard!

5.1.5.1. Viewing default security policiesCopy linkLink copied to clipboard!

5.1.6. Custom security policiesCopy linkLink copied to clipboard!

5.1.7. Sharing security policiesCopy linkLink copied to clipboard!

5.1.7.1. Exporting a security policyCopy linkLink copied to clipboard!

5.1.7.2. Importing a security policyCopy linkLink copied to clipboard!

5.2. Using admission controller enforcementCopy linkLink copied to clipboard!

5.2.1. Understanding admission controller enforcementCopy linkLink copied to clipboard!

5.2.2. Enabling admission controller enforcement during installationCopy linkLink copied to clipboard!

5.2.3. Viewing and enabling admission controller enforcement on an existing clusterCopy linkLink copied to clipboard!

5.2.4. Bypassing admission controller enforcementCopy linkLink copied to clipboard!

5.2.5. Disabling admission controller enforcement on a clusterCopy linkLink copied to clipboard!

5.2.6. Configuring the admission controller failure policy during installationCopy linkLink copied to clipboard!

5.2.7. Configuring the admission controller failure policy on an existing clusterCopy linkLink copied to clipboard!

5.3. Configuring file activity monitoringCopy linkLink copied to clipboard!

5.3.1. Detection of unauthorized file modificationsCopy linkLink copied to clipboard!

5.3.1.1. Dynamic path support for file activity monitoringCopy linkLink copied to clipboard!

5.3.1.2. Known limitationsCopy linkLink copied to clipboard!

5.3.2. Create a file activity monitoring policyCopy linkLink copied to clipboard!

5.3.3. Process filtering for file activity policiesCopy linkLink copied to clipboard!

5.3.3.1. Available process filtering criteriaCopy linkLink copied to clipboard!

5.3.3.2. Common use cases for process filteringCopy linkLink copied to clipboard!

5.3.3.3. Combining file path and process filtersCopy linkLink copied to clipboard!

5.3.3.4. Create file activity policies with process filtersCopy linkLink copied to clipboard!

5.3.3.4.1. Policies with process filter examplesCopy linkLink copied to clipboard!

5.3.4. Migrate file activity monitoring policies from 4.10 to 4.11Copy linkLink copied to clipboard!

5.4. Creating and modifying security policiesCopy linkLink copied to clipboard!

5.4.1. Creating a security policy from the system policies viewCopy linkLink copied to clipboard!

5.4.1.1. Entering policy detailsCopy linkLink copied to clipboard!

5.4.1.2. Selecting the policy lifecycle stageCopy linkLink copied to clipboard!

5.4.1.3. Configuring policy rulesCopy linkLink copied to clipboard!

5.4.1.4. Configuring policy resourcesCopy linkLink copied to clipboard!

5.4.1.4.1. Policy resource evaluation logicCopy linkLink copied to clipboard!

5.4.1.4.1.1. Resource rule structureCopy linkLink copied to clipboard!

5.4.1.4.1.2. Label matchingCopy linkLink copied to clipboard!

5.4.1.4.2. Policy resource label syntax referenceCopy linkLink copied to clipboard!

5.4.1.4.2.1. Label formatCopy linkLink copied to clipboard!

5.4.1.4.2.2. Common label patternsCopy linkLink copied to clipboard!

5.4.1.4.2.3. Label examplesCopy linkLink copied to clipboard!

5.4.1.4.2.4. Mutual exclusivity rulesCopy linkLink copied to clipboard!

5.4.1.4.2.5. Managing cluster and namespace labelsCopy linkLink copied to clipboard!

5.4.1.5. Enable the policyCopy linkLink copied to clipboard!

5.4.1.6. Configuring policy enforcementCopy linkLink copied to clipboard!

5.4.1.7. Selecting policy notifiersCopy linkLink copied to clipboard!

5.4.1.8. Reviewing the policy and previewing violationsCopy linkLink copied to clipboard!

5.4.1.9. Verifying file activity policiesCopy linkLink copied to clipboard!

5.4.2. Creating a security policy from the risk viewCopy linkLink copied to clipboard!

5.4.3. Modifying existing security policiesCopy linkLink copied to clipboard!

5.4.3.1. Disabling a policyCopy linkLink copied to clipboard!

5.4.3.2. Creating policy categories by using the Policy categories tabCopy linkLink copied to clipboard!

5.4.3.3. Modifying policy categories by using the Policy categories tabCopy linkLink copied to clipboard!

5.5. Managing policies as codeCopy linkLink copied to clipboard!

5.5.1. Managing polices as codeCopy linkLink copied to clipboard!

5.5.1.1. About policy driftCopy linkLink copied to clipboard!

5.5.1.2. Creating policies in code by using the RHACS portalCopy linkLink copied to clipboard!

5.5.1.3. Creating policies in code by constructing a CRCopy linkLink copied to clipboard!

5.5.1.4. Disabling the policy as code featureCopy linkLink copied to clipboard!

5.6. Security policy referenceCopy linkLink copied to clipboard!

5.6.1. Policy categoriesCopy linkLink copied to clipboard!

5.6.2. Policy criteriaCopy linkLink copied to clipboard!

5.6.2.1. Image criteriaCopy linkLink copied to clipboard!

5.6.2.2. Workload configuration criteriaCopy linkLink copied to clipboard!

5.6.2.3. Workload activity criteriaCopy linkLink copied to clipboard!

5.6.2.4. Audit log: Kubernetes resource operationsCopy linkLink copied to clipboard!

5.1. About policies in RHACS
Copy link

5.1.1. Understanding the RHACS policy evaluation engine
Copy link

5.1.2. About policy enforcement
Copy link

5.1.2.1. Build stage enforcement
Copy link

5.1.2.2. Deploy stage enforcement
Copy link

5.1.2.2.1. Hard enforcement
Copy link

5.1.2.2.2. Namespace exclusions from admission controller enforcement
Copy link

5.1.2.2.3. Enforcement on existing deployments
Copy link

5.1.2.2.4. Soft enforcement
Copy link

5.1.2.3. Runtime enforcement
Copy link

5.1.3. RHACS policy structure
Copy link

5.1.3.1. Policy definition
Copy link

5.1.3.2. Policy behavior
Copy link

5.1.4. Policy and violation management
Copy link

5.1.4.1. Setting policy rules
Copy link

5.1.5. Default security policies
Copy link

5.1.5.1. Viewing default security policies
Copy link

5.1.6. Custom security policies
Copy link

5.1.7. Sharing security policies
Copy link

5.1.7.1. Exporting a security policy
Copy link

5.1.7.2. Importing a security policy
Copy link

5.2. Using admission controller enforcement
Copy link

5.2.1. Understanding admission controller enforcement
Copy link

5.2.2. Enabling admission controller enforcement during installation
Copy link

5.2.3. Viewing and enabling admission controller enforcement on an existing cluster
Copy link

5.2.4. Bypassing admission controller enforcement
Copy link

5.2.5. Disabling admission controller enforcement on a cluster
Copy link

5.2.6. Configuring the admission controller failure policy during installation
Copy link

5.2.7. Configuring the admission controller failure policy on an existing cluster
Copy link

5.3. Configuring file activity monitoring
Copy link

5.3.1. Detection of unauthorized file modifications
Copy link

5.3.1.1. Dynamic path support for file activity monitoring
Copy link

5.3.1.2. Known limitations
Copy link

5.3.2. Create a file activity monitoring policy
Copy link

5.3.3. Process filtering for file activity policies
Copy link

5.3.3.1. Available process filtering criteria
Copy link

5.3.3.2. Common use cases for process filtering
Copy link

5.3.3.3. Combining file path and process filters
Copy link

5.3.3.4. Create file activity policies with process filters
Copy link

5.3.3.4.1. Policies with process filter examples
Copy link

5.3.4. Migrate file activity monitoring policies from 4.10 to 4.11
Copy link

5.4. Creating and modifying security policies
Copy link

5.4.1. Creating a security policy from the system policies view
Copy link

5.4.1.1. Entering policy details
Copy link

5.4.1.2. Selecting the policy lifecycle stage
Copy link

5.4.1.3. Configuring policy rules
Copy link

5.4.1.4. Configuring policy resources
Copy link

5.4.1.4.1. Policy resource evaluation logic
Copy link

5.4.1.4.1.1. Resource rule structure
Copy link

5.4.1.4.1.2. Label matching
Copy link

5.4.1.4.2. Policy resource label syntax reference
Copy link

5.4.1.4.2.1. Label format
Copy link

5.4.1.4.2.2. Common label patterns
Copy link

5.4.1.4.2.3. Label examples
Copy link

5.4.1.4.2.4. Mutual exclusivity rules
Copy link

5.4.1.4.2.5. Managing cluster and namespace labels
Copy link

5.4.1.5. Enable the policy
Copy link

5.4.1.6. Configuring policy enforcement
Copy link

5.4.1.7. Selecting policy notifiers
Copy link

5.4.1.8. Reviewing the policy and previewing violations
Copy link

5.4.1.9. Verifying file activity policies
Copy link

5.4.2. Creating a security policy from the risk view
Copy link

5.4.3. Modifying existing security policies
Copy link

5.4.3.1. Disabling a policy
Copy link

5.4.3.2. Creating policy categories by using the Policy categories tab
Copy link

5.4.3.3. Modifying policy categories by using the Policy categories tab
Copy link

5.5. Managing policies as code
Copy link

5.5.1. Managing polices as code
Copy link

5.5.1.1. About policy drift
Copy link

5.5.1.2. Creating policies in code by using the RHACS portal
Copy link

5.5.1.3. Creating policies in code by constructing a CR
Copy link

5.5.1.4. Disabling the policy as code feature
Copy link

5.6. Security policy reference
Copy link

5.6.1. Policy categories
Copy link

5.6.2. Policy criteria
Copy link

5.6.2.1. Image criteria
Copy link

5.6.2.2. Workload configuration criteria
Copy link

5.6.2.3. Workload activity criteria
Copy link

5.6.2.4. Audit log: Kubernetes resource operations
Copy link

5.6.2.5. Node activity criteria
Copy link