Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

このコンテンツは選択した言語では利用できません。

Chapter 5. Using policies to provide security

5.1. About policies in RHACS
リンクのコピー

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
リンクのコピー

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
リンクのコピー

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
リンクのコピー

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
リンクのコピー

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
リンクのコピー

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

5.1.2.2.2. Namespace exclusions
リンクのコピー

By default, RHACS excludes certain administrative namespaces, such as the stackrox, kube-system, and istio-system namespaces, from enforcement blocking. The reason for this is that some items in these namespaces must be deployed for RHACS to work correctly.

In addition, the RHACS admission controller bypasses requests that originate from a service account in a system namespace. Consider this factor when deploying the CI/CD tool of your choice.

5.1.2.2.3. Enforcement on existing deployments
リンクのコピー

For existing deployments, policy changes only result in enforcement at the next detection of the criteria, when a Kubernetes event occurs. If you make changes to a policy, you must reassess policies by selecting Policy Management and clicking Reassess All. This action applies deploy policies on all existing deployments regardless of whether there are any new incoming Kubernetes events. If a policy is violated, then RHACS performs enforcement.

5.1.2.2.4. Soft enforcement
リンクのコピー

Soft enforcement is performed by RHACS Sensor. This enforcement prevents an operation from being initiated. With soft enforcement, Sensor scales the replicas to 0, and prevents pods from being scheduled. In this enforcement, a non-ready deployment is available in the cluster.

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
リンクのコピー

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
リンクのコピー

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:

  • 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 that policy is evaluated.

    • 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 are designed to define the positive, expected behavior. Whether a criteria is designed for positive or negative condition depends on the context, because they 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. Consequently, Container Registry name is NOT <quay.io> triggers if any registry is used other than the allowed one 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. Liveness probe is <Defined> can be used to receive a positive indication 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.

  • Policy behavior: Specifies the action, inform or enforce, that RHACS takes for a given scope.

    • Scope: By default, RHACS policies are global; they apply across all secured clusters, on all namespaces, for all workloads and images. The policy scope can be modified by explicitly including or excluding a mix of cluster, namespace, and deployment selection criteria. Policy scopes can use regular expression to select a namespace name, namespace label, or a deployment name or deployment label, whihc automatically applies across all clusters, including new ones.
    • Action: This section determines if a policy is active, for example, enabled or disabled, whether it is enforced, and which notifiers to use for routing alerts.

5.1.4. Policy and violation management
リンクのコピー

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
リンクのコピー

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
リンクのコピー

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 "Policy reference".

5.1.5.1. Viewing default security policies
リンクのコピー

Red Hat Advanced Cluster Security for Kubernetes 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
リンクのコピー

RHACS allows you to 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 custom security policies".

5.1.7. Sharing security policies
リンクのコピー

You can share your security policies between different Central instances in the RHACS portal by exporting and importing policies. Sharing policies helps you enforce the same standards for all your clusters. To share policies, you export them as JSON files, and then import them back into another Central instance.

Note

Currently, you cannot export multiple security policies at the same time by using the RHACS portal. However, you can use the API for exporting multiple security policies. In the RHACS portal, go to Help API reference to see the API reference.

5.1.7.1. Exporting a security policy
リンクのコピー

When you export a policy, it includes all the policy contents and also includes cluster scopes, cluster exclusions, and all configured notifications.

Procedure

  1. In the RHACS portal, go to Platform Configuration Policy Management.
  2. From the Policies page, select the policy you want to edit.
  3. Select Actions Export policy to JSON.

5.1.7.2. Importing a security policy
リンクのコピー

You can import a security policy from the System Policies view on the RHACS portal.

Procedure

  1. In the RHACS portal, go to Platform Configuration Policy Management.
  2. Click Import policy.
  3. In the Import policy JSON dialog, click Upload and select the JSON file you want to upload.

  4. Click Begin import.

    Each security policy in RHACS has a unique ID (UID) and a unique name. When you import a policy, RHACS handles the uploaded policy as follows:

    • If the imported policy UID and name do not match any existing policy, RHACS creates a new policy.

    • If the imported policy has the same UID as an existing policy, but a different name, you can either:

      • Keep both policies. RHACS saves the imported policy with a new UID.
      • Replace the existing policy with the imported policy.

    • If the imported policy has the same name as an existing policy, but a different UID, you can either:

      • Keep both policies by providing a new name for the imported policy.
      • Replace the existing policy with the imported policy.

    • If the imported policy has the same name and UID as an existing policy, the Red Hat Advanced Cluster Security for Kubernetes checks if the policy criteria match to the existing policy. If the policy criteria match, RHACS keeps the existing policy and shows a success message. If the policy criteria do not match, you can either:

      • Keep both policies by providing a new name for the imported policy.

      • Replace the existing policy with the imported policy.

        Important
        • If you import into the same Central instance, RHACS uses all the exported fields.
        • If you import into a different Central instance, RHACS omits certain fields, such as cluster scopes, cluster exclusions, and notifications. RHACS shows these omitted fields in a message. These fields vary for every installation, and you cannot migrate them from one Central instance to another.

5.2. Using admission controller enforcement
リンクのコピー

RHACS works with Kubernetes admission controllers and OpenShift Container Platform admission plugins to allow you 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
リンクのコピー

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:

  1. 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.
  2. The API server contacts the validating webhooks with an AdmissionReview request.
  3. 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.

  4. 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
リンクのコピー

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

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

  2. 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 Dynamic configuration (syncs with Sensor) section, in the Admission controller enforcement behavior field, select Enforce policies.
    4. Select Next.
    5. Select Finish. RHACS automatically synchronizes the admission controller and applies the changes.

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
リンクのコピー

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

Procedure

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

  2. 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
    Copy to Clipboard Toggle word wrap

  3. 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 Dynamic 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. Select Finish. RHACS automatically synchronizes the admission controller and applies the changes.

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
リンクのコピー

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

  1. 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
...
Copy to Clipboard Toggle word wrap

where:

"admission.stackrox.io/break-glass": "jira-3423"
Provides a change control reference or relevant explanation for why the admission controller was bypassed.

5.2.5. Disabling admission controller enforcement on a cluster
リンクのコピー

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

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

  2. 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
    Copy to Clipboard Toggle word wrap

  3. 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 Dynamic 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. Select Finish.

5.2.6. Configuring the admission controller failure policy during installation
リンクのコピー

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.

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

  2. 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
リンクのコピー

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.

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

  2. 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
    Copy to Clipboard Toggle word wrap

  3. 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. Creating and modifying security policies
リンクのコピー

In Red Hat Advanced Cluster Security for Kubernetes (RHACS), you can use the RHACS portal to create policies, or create and manage policies as code by saving policies as Kubernetes custom resources (CRs) and by applying them to clusters by using a continuous delivery tool such as Argo CD.

5.3.1. Creating a security policy from the system policies view
リンクのコピー

You can create new security policies from the system policies view.

Procedure

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

5.3.1.1. Entering policy details
リンクのコピー

Enter details about your policy, such as the name, severity, description, and guidance to resolve violations of the policy. Required fields are marked with an asterisk.

Procedure

  1. 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.
  2. Select a Severity level for this policy.
  3. Select a policy category for the policy from the Categories list.
  4. Enter details about the policy in the Description field.
  5. Enter an explanation about why the policy exists in the Rationale field.
  6. Enter steps to resolve violations of this policy in the Guidance field.

  7. Under the MITRE ATT&CK section, select the tactics and the techniques you want to specify for the policy.

    1. Click Add tactic, and then select a tactic from the drop-down list.
    2. Click the Add technique to add techniques for the selected tactic. You can specify multiple techniques for a tactic.
  8. Click Next.

5.3.1.2. Selecting the policy lifecycle stage
リンクのコピー

Select the lifecycle stage when the policy is used. For more information, see "Understanding the RHACS policy evaluation engine".

Procedure

  1. Select the Lifecycle stages for the policy:

    • Build: Policies in this stage can only inspect image criteria that are related to the image registry, content, vulnerability data and the scanning process. They are evaluated in the CI pipeline, allowing policy violations to break the build when enforced. Violations from this stage are not stored by RHACS.
    • Deploy: Policies in this stage can inspect workload configurations and their images. These policies are evaluated while creating or updating a workload resource, and re-evaluated periodically or on-demand. When enforced, a policy violation can cause the admission controller to reject the deploy or update attempt, or scale the workload replicas down 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 two event sources:

      • Deployment: Runtime policies inspecting workload activity require at least one workload activity criterion. Workload activity criteria can be combined with image or workload configuration criteria. Enforcement terminates the offending pod, and then the pod is re-created.
      • 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.
  2. Click Next.

5.3.1.3. Configuring policy rules
リンクのコピー

You can use policy fields, or criteria, to create rules for your policies.

Procedure

  1. In the Rules section, 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.

  2. 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, criteria under 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".

  3. 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 you click Not 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".

  4. To combine multiple values for an attribute, click the Add icon.
  5. Optional: Click Add a new rule to add an additional rule.
  6. Click Next.

5.3.1.4. Configuring the policy scope
リンクのコピー

You can define the scope of a policy to restrict or allow the policy for certain entities. You can enable the policy to apply only to a specific cluster, namespace, or deployment label. For policies configured for the deploy and runtime lifecycle stages, you can also exclude a cluster, namespace, deployment, or deployment label so that the policy is not applied. For the build lifecycle stage, you can exclude specific images so that, for example, those images will not trigger a violation during the continuous integration part of a continuous integration/continuous delivery (CI/CD) pipeline.

Procedure

  1. Configure any of the following options:

    • Restrict by scope: This enables this policy to only be applied for a specific cluster, a namespace, or a deployment label. You can add multiple scopes and also use regular expressions in RE2 Syntax for namespaces and labels.

    • Exclude by scope: Excludes specific deployments, clusters, namespaces, and deployment labels from the policy. The policy will not apply to the entities that you select. You can add multiple scopes and also use regular expressions in RE2 Syntax for namespaces and labels. However, you cannot use regular expressions for selecting deployments.

      Note

      This function is only available for policies configured for the deploy and runtime lifecycle stages.

    • Exclude images: For policies configured for the build lifecycle stage, you can exclude images from the policy. Select the images for which you do not want to trigger a violation.

      Note

      The Excluded Images 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.

  2. Click Next.

5.3.1.5. Enable the policy
リンクのコピー

Enable or disable the policy.

Procedure

  1. Select Enable make the policy active, or Disable to disable it.
  2. Click Next.

5.3.1.6. Configuring policy enforcement
リンクのコピー

You can configure if RHACS should only inform you with a notification when this policy is violated, or inform you and enforce the policy. Policy enforcement is determined by whether the admission controller is enabled on the cluster and the lifecycle stage of the policy.

Procedure

  1. Select an enforcement method:

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

  2. If you choose to enforce the policy, 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: Select Enforce on Build 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: Select Enforce on Deploy to have RHACS block workload admission and updates that match the conditions of the policy if the RHACS admission controller is configured and running.

      • In clusters with admission controller enforcement, the Kubernetes or OpenShift Container Platform API server blocks all noncompliant deployments. In other clusters, RHACS edits noncompliant deployments to prevent pods from being scheduled.
      • For existing deployments, policy changes only result in enforcement at the next detection of the criteria, when a Kubernetes event occurs. For more information about enforcement, see "Deploy stage enforcement".

    • Runtime: Select Enforce on Runtime 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.

  3. Click Next.

5.3.1.7. Selecting policy notifiers
リンクのコピー

You can attach notifiers to the policy to send policy violations to email recipients, or to external tools such as Slack, Jira, Splunk, or other applications that use webhooks.

Prerequisite

  • You must have previously 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

  1. Select the notifier that RHACS will use to inform you when a policy is violated.
  2. Click Next.

5.3.1.8. Reviewing the policy and previewing violations
リンクのコピー

When creating a policy, RHACS provides a preview window where you can view your policy configuration and preview the violations that will occur if the policy is implemented.

Procedure

  1. Verify that the policy configuration is configured with the correct options.

  2. View the results in the Preview 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.

  3. Click Save.

5.3.2. Creating a security policy from the risk view
リンクのコピー

While evaluating risks in your deployments in the Risk view, when you apply local page filtering, you can create new security policies based on the filtering criteria you are using.

Procedure

  1. Go to the RHACS portal and select Risk from the navigation menu.
  2. Apply local page filtering criteria that you want to create a policy for.
  3. Select New 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.3.3. Modifying existing security policies
リンクのコピー

You can edit the policies you have created and the existing default policies provided by Red Hat Advanced Cluster Security for Kubernetes that you have cloned.

Procedure

  1. In the RHACS portal, go to Platform Configuration Policy Management.
  2. From the Policies page, select the policy you want to edit.

  3. Select Actions 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.

  4. Edit the fields that you want to change and click Save.

5.3.3.1. Disabling a policy
リンクのコピー

You can disable a policy by using the RHACS portal.

Procedure

  1. In the RHACS portal, go to Platform Configuration Policy Management. For default policies, you cannot edit enforcement options.
  2. If you do not want the policy to be evaluated against workload operations, select Actions Edit policy.
  3. In the left navigation menu, select Actions.
  4. In the Activation state field, select Disable.
  5. Save the policy.

5.4. Managing policies as code
リンクのコピー

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.4.1. Managing polices as code
リンクのコピー

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.

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.4.1.1. About policy drift
リンクのコピー

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.4.1.2. Creating policies in code by using the RHACS portal
リンクのコピー

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
    Copy to Clipboard Toggle word wrap

Procedure

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

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

  2. In the row listing the policy, click the overflow menu, kebab , 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.

  3. 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.4.1.3. Creating policies in code by constructing a CR
リンクのコピー

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

  1. 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
# ...
    Copy to Clipboard Toggle word wrap
    Tip

    Use online documentation, for example, by entering the kubectl explain securitypolicy.spec command, to understand the fields available for defining a policy specification.

  2. 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.4.1.4. Disabling the policy as code feature
リンクのコピー

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

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
    1
    Copy to Clipboard Toggle word wrap
    1
    For OpenShift Container Platform, use oc instead of kubectl.

5.5. Security policy reference
リンクのコピー

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.5.1. Policy categories
リンクのコピー

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)
  • 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.5.2. Policy criteria
リンクのコピー

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.5.2.1. Image criteria
リンクのコピー

Image registry
Expand
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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)

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
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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)

5.5.2.2. Workload configuration criteria
リンクのコピー

Container configuration
Expand
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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.5.2.3. Workload activity criteria
リンクのコピー

Process activity
Expand
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

Kubernetes action

The name of the Kubernetes action, such as Pod Exec.

Kubernetes Resource

One of:

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

5.5.2.4. Audit log: Kubernetes resource operations
リンクのコピー

Resource operation (Required)
Expand
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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
AttributeDescriptionJSON AttributeAllowed ValuesRegex, NOT, AND, ORPhase

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.5.3. Default security policies
リンクのコピー

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.

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.5.3.1. Critical severity security policies
リンクのコピー

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.1. Critical severity security policies
Life cycle stageNameDescriptionStatus

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.5.3.2. High severity security policies
リンクのコピー

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.2. High severity security policies
Life cycle stageNameDescriptionStatus

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: 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.5.3.3. Medium severity security policies
リンクのコピー

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.3. Medium severity security policies
Life cycle stageNameDescriptionStatus

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.5.3.4. Low severity security policies
リンクのコピー

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.4. Low severity security policies
Life cycle stageNameDescriptionStatus

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 a deployment uses 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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat