Chapter 6. Managing security policies Red Hat Advanced Cluster Security for Kubernetes allows you to use out-of-the-box security policies and define custom multi-factor policies for your container environment. Configuring these policies enables you to automatically prevent high-risk service deployments in your environment and respond to runtime security incidents. 6.1. Using default security policies Red Hat Advanced Cluster Security for Kubernetes includes a set of default policies that provide broad coverage to identify security issues and ensure best practices for security in your environment. To view the default policies: In the RHACS portal, go to Platform Configuration Policy Management . The Policies view also enables you to configure the policies. The policy information is organized into the following groups: Policy : A name for the policy. Description : A longer, more detailed description of the alert for the policy. Status : The current status of the policy, either Enabled or Disabled . Notifiers : The list of notifiers that are configured for the policy. Severity : A ranking of the policy, either critical, high, medium, or low, for the amount of attention required. Lifecycle : The phase of the container lifecycle (build, deploy, or runtime) that this policy applies to, and the phase at which enforcement applies, when the policy is enabled. The Policy categories view lists the categories and enables you to manage the categories for your policies. By default, all the categories are listed. You optionally filter the categories by using the category name. The following categories are listed: Anomalous Activity Cryptocurrency Mining DevOps Best Practices Docker CIS Kubernetes Kubernetes Events Network Tools Package Management Privileges Security Best Practices Supply Chain Security System Modification Vulnerability Management Zero Trust Note You cannot delete default policies or edit policy criteria for default policies. 6.2. 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. Procedure In the RHACS portal, go to Platform Configuration Policy Management . From the Policies page, select the policy you want to edit. Select Actions Edit policy . Modify the Policy details . You can modify the policy name, severity, categories, description, rationale, and guidance. You can also attach notifiers to the policy by selecting from the available Notifiers under the Attach notifiers section. Click . In the Policy behavior section, select the Lifecycle stages and Event sources for the policy. Select a Response method to address violations for the policy. Click . In the Policy criteria section, expand the categories under the Drag out policy fields section. Use the drag-and-drop policy fields to specify logical conditions for the policy criteria. Note You cannot edit policy criteria for default policies. Click . In the Policy scope section, modify Restrict by scope , Exclude by scope , and Exclude images settings. Click . In the Review policy section, preview the policy violations. Click Save . Additional resources Creating a security policy from the system policies view 6.3. Creating and managing policy categories 6.3.1. Creating policy categories by using the Policy categories tab Beginning with version 3.74, RHACS provides a new method to create and manage policy categories in Red Hat Advanced Cluster Security Cloud Service or in RHACS if you have the PostgreSQL database enabled. All policy workflows other than policy creation remain unchanged when using this feature. You can also configure policy categories by using the PolicyCategoryService API object. For more information, go to Help API reference in the RHACS portal. Procedure In the RHACS portal, go to Platform Configuration Policy Management . Click the Policy categories tab. This tab provides a list of existing categories and allows you to filter the list by category name. You can also click Show all categories and select the checkbox to remove default or custom categories from the displayed list. Click Create category . Enter a category name and click Create . 6.3.2. Modifying policy categories by using the Policy categories tab Beginning with version 3.74, RHACS provides a new method to create and manage policy categories in Red Hat Advanced Cluster Security Cloud Service or in RHACS if you have the PostgreSQL database enabled. All policy workflows other than policy creation remain unchanged when using this feature. You can also configure policy categories by using the PolicyCategoryService API object. For more information, go to Help API reference in the RHACS portal. Procedure In the RHACS portal, go to Platform Configuration Policy Management . Click the Policy categories tab. This tab provides a list of existing categories and allows you to filter the list by category name. You can also click Show all categories and select the checkbox to remove default or custom categories from the displayed list. Click a policy name to edit or delete it. Default policy categories cannot be selected, edited, or deleted. Additional resources Creating a security policy from the system policies view 6.4. Creating custom policies In addition to using the default policies, you can also create custom policies in Red Hat Advanced Cluster Security for Kubernetes. To build a new policy, you can clone an existing policy or create a new one from scratch. You can also create policies based on the filter criteria in the Risk view in the RHACS portal. You can also use AND , OR , and NOT logical operators for policy criteria to create advanced policies. 6.4.1. Creating a security policy from the system policies view You can create new security policies from the system policies view. Procedure In the RHACS portal, go to Platform Configuration Policy Management . Click Create policy . Enter the following details about your policy in the Policy details section: Enter a Name for the policy. Optional: Attach notifiers to the policy by selecting from the available Notifiers under the Attach notifiers section. Note Before you can forward alerts, you must integrate RHACS with your notification provider, such as webhooks, Jira, PagerDuty, Splunk, or others. Select a Severity level for this policy, either Critical , High , Medium , or Low . Select policy Categories you want to apply to this policy. For information about creating categories, see "Creating and managing policy categories" later in this document. Enter details about the policy in the Description field. Enter an explanation about why the policy exists in the Rationale field. Enter steps to resolve violations of this policy in the Guidance field. Optional: Under the MITRE ATT&CK section, select the tactics and the techniques you want to specify for the policy. Click Add tactic , and then select a tactic from the drop-down list. Click the Add technique to add techniques for the selected tactic. You can specify multiple techniques for a tactic. Click . In the Policy behavior section, take the following steps: Select the Lifecycle stages to which your policy is applicable: Build , Deploy , or Runtime . You can select more than one stage. Build-time policies apply to image fields such as CVEs and Dockerfile instructions. Deploy-time policies can include all build-time policy criteria but they can also include data from your cluster configurations, such as running in privileged mode or mounting the Docker socket. Runtime policies can include all build-time and deploy-time policy criteria but they can also include data about process executions during runtime. Optional: If you selected the Runtime lifecycle stage, select one of the following Event sources : Deployment: RHACS triggers policy violations when event sources include process and network activity, pod exec and pod port forwarding. RHACS triggers policy violations when event sources match Kubernetes audit log records. For Response method , select one of the following options: Inform : include the violation in the violations list. Inform and enforce : enforce actions. Optional: If you selected Inform and enforce , in Configure enforcement behavior , select the enforcement behavior for the policy by using the toggle for each lifecycle. It is only available for the stages you select when configuring Lifecycle stages . The enforcement behavior is different for each lifecycle stage. Build : RHACS fails your continuous integration (CI) builds when images match the criteria of the policy. Deploy : For the Deploy stage, RHACS blocks the creation and update of deployments that match the conditions of the policy if the RHACS admission controller is configured and running. In clusters with admission controller enforcement, the Kubernetes or OpenShift Container Platform API server blocks all noncompliant deployments. In other clusters, RHACS edits noncompliant deployments to prevent pods from being scheduled. For existing deployments, policy changes only result in enforcement at the detection of the criteria, when a Kubernetes event occurs. For more information about enforcement, see "Security policy enforcement for the deploy stage". Runtime - RHACS deletes all pods when an event in the pods matches the criteria of the policy. Warning Policy enforcement can impact running applications or development processes. Before you enable enforcement options, inform all stakeholders and plan about how to respond to automated enforcement actions. Click . In the Policy Criteria section, configure the attributes that you want to trigger the policy for. Click and drag policy fields into the Policy Section to add criteria. Note The policy fields that are available depend on the lifecycle stage you chose for the policy. For example, criteria under Kubernetes access policies or Networking are available when creating a policy for the runtime lifecycle, but not when creating a policy for the build lifecycle. See "Policy criteria" in the "Additional resources" section for more information about policy criteria, including information about criteria and the lifecycle phase in which they are available. Optional: Click Add condition to add policy sections that contain additional criteria that will trigger the policy (for example, to trigger on old, stale images, you can configure that image tag is not latest or image age and specify a minimum number of days since an image is built). Click . In the Policy scope section, configure the following: Click Add inclusion scope to use Restrict by scope to enable this policy only for a specific cluster, a namespace, or a label. You can add multiple scopes and also use regular expression in RE2 Syntax for namespaces and labels. Click Add exclusion scope to use Exclude by scope to exclude deployments, clusters, namespaces, and labels you specify. The policy will not apply to the entities that you select. You can add multiple scopes and also use regular expression in RE2 Syntax for namespaces and labels. However, you cannot use regular expression for selecting deployments. For Excluded Images (Build Lifecycle only) , select all images that you do not want to trigger a violation for. 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. Click . In the Review policy section, preview the policy violations. Click Save . 6.4.1.1. Security policy enforcement for the deploy stage Red Hat Advanced Cluster Security for Kubernetes supports two forms of security policy enforcement for deploy-time policies: hard enforcement through the admission controller and soft enforcement by RHACS Sensor. The admission controller blocks creation or updating of deployments that violate policy. If the admission controller is disabled or unavailable, Sensor can perform enforcement by scaling down replicas for deployments that violate policy to 0 . Warning Policy enforcement can impact running applications or development processes. Before you enable enforcement options, inform all stakeholders and plan how to respond to the automated enforcement actions. 6.4.1.1.1. Hard enforcement Hard enforcement is performed by the RHACS admission controller. In clusters with admission controller enforcement, the Kubernetes or OpenShift Container Platform API server blocks all noncompliant deployments. The admission controller blocks CREATE and UPDATE operations. Any pod create or update request that satisfies a policy configured with deploy-time enforcement enabled will fail. Note Kubernetes admission webhooks support only CREATE , UPDATE , DELETE , or CONNECT operations. The RHACS admission controller supports only CREATE and UPDATE operations. Operations such as kubectl patch , kubectl set , and kubectl scale are PATCH operations, not UPDATE operations. Because PATCH operations are not supported in Kubernetes, RHACS cannot perform enforcement on PATCH operations. For blocking enforcement, you must enable the following settings for the cluster in RHACS: Enforce on Object Creates : This toggle in the Dynamic Configuration section controls the behavior of the admission control service. You must have the Configure Admission Controller Webhook to listen on Object Creates toggle in the Static Configuration section turned on for this to work. Enforce on Object Updates : This toggle in the Dynamic Configuration section controls the behavior of the admission control service. You must have the Configure Admission Controller Webhook to listen on Object Updates toggle in the Static Configuration section turned on for this to work. If you make changes to settings in the Static Configuration setting, you must redeploy the secured cluster for those changes to take effect. 6.4.1.1.2. Soft enforcement Soft enforcement is performed by RHACS Sensor. This enforcement prevents an operation from being initiated. With soft enforcement, Sensor scales the replicas to 0, and prevents pods from being scheduled. In this enforcement, a non-ready deployment is available in the cluster. If soft enforcement is configured, and Sensor is down, then RHACS cannot perform enforcement. 6.4.1.1.3. Namespace exclusions By default, RHACS excludes certain administrative namespaces, such as the stackrox , kube-system , and istio-system namespaces, from enforcement blocking. The reason for this is that some items in these namespaces must be deployed for RHACS to work correctly. 6.4.1.1.4. Enforcement on existing deployments For existing deployments, policy changes only result in enforcement at the detection of the criteria, when a Kubernetes event occurs. If you make changes to a policy, you must reassess policies by selecting Policy Management and clicking Reassess All . This action applies deploy policies on all existing deployments regardless of whether there are any new incoming Kubernetes events. If a policy is violated, then RHACS performs enforcement. Additional resources Policy criteria Using admission controller enforcement 6.4.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 Go to the RHACS portal and select Risk from the navigation menu. Apply local page filtering criteria that you want to create a policy for. Select New Policy and fill in the required fields to create a new policy. Additional resources Using local page filtering Creating a security policy from the system policies view 6.4.3. Policy criteria In the Policy Criteria section you can configure the data on which you want to trigger a policy. 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 . Attribute Description JSON Attribute Allowed Values Regex , NOT , AND, OR Phase Section: Image registry 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) Section: Image contents The Common Vulnerabilities and Exposures (CVE) is 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) 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) Image age The minimum number of days from image creation date. Image Age Integer ✕ Build , Deploy , Runtime (when used with a Runtime criterion) 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 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 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) 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) 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) 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) Section: Container configuration 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) Section: Deployment metadata 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) Section: Storage Volume Name Name of the storage. Volume Name String Regex, NOT, AND, OR Deploy , Runtime (when used with a Runtime criterion) Volume Source Indicates the form in which the volume is provisioned. For example, persistentVolumeClaim or hostPath . Volume Source String Regex, NOT, AND, OR Deploy , Runtime (when used with a Runtime criterion) Volume Destination The path where the volume is mounted. Volume Destination String Regex, NOT, AND, OR Deploy , Runtime (when used with a Runtime criterion) Volume Type The type of volume. 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 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) 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) 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) Port Exposure Exposure method of the service, for example, load balancer or node port. Port Exposure Method One of: UNSET EXTERNAL NODE HOST INTERNAL ROUTE NOT, AND, OR Deploy , Runtime (when used with a Runtime criterion) 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 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) Section: Process activity 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 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 Section: Kubernetes access 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) Section: Kubernetes events 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 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 Kubernetes Resource Type Type of the accessed Kubernetes resource. Kubernetes Resource One of: Config maps Secrets ClusterRoles ClusterRoleBindings NetworkPolicies SecurityContextConstraints EgressFirewalls ! OR only Runtime ONLY - Audit Log Kubernetes API Verb The Kubernetes API verb that is used to access the resource, such as GET or POST . Kubernetes API Verb One of: CREATE DELETE GET PATCH UPDATE ! OR only Runtime ONLY - Audit Log Kubernetes Resource 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 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 6.4.3.1. Adding logical conditions for the policy criteria You can use the drag-and-drop policy fields panel to specify logical conditions for the policy criteria. Prerequisites You must be using Red Hat Advanced Cluster Security for Kubernetes version 3.0.45 or newer. Procedure In the Policy Criteria section, select Add a new condition to add a new policy section. You can click on the Edit icon to rename the policy section. The Drag out a policy field section lists available policy criteria in multiple categories. You can expand and collapse these categories to view the policy criteria attributes. Drag an attribute to the Drop a policy field inside area of the policy section. Depending on the type of the attribute you select, you get different options to configure the conditions for the selected attribute. For example: If you select an attribute with Boolean values Read-Only Root Filesystem , you will see READ-ONLY and WRITABLE options. If you select an attribute with compound values Environment variable , you will see options to enter values for Key , Value , and Value From fields, and an icon to add more values for the available options. To combine multiple values for an attribute, click the Add icon. You can also click on the logical operator AND or OR listed in a policy section, to toggle between AND and OR operators. Toggling between operators only works inside a policy section and not between two different policy sections. You can specify more than one AND and OR condition by repeating these steps. After you configure the conditions for the added attributes, click to continue with the policy creation. 6.5. Sharing security policies Beginning from Red Hat Advanced Cluster Security for Kubernetes version 3.0.44, you can share your security policies between different Central instances, by exporting and importing policies. It 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 once 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. 6.5.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 In the RHACS portal, go to Platform Configuration Policy Management . From the Policies page, select the policy you want to edit. Select Actions Export policy to JSON . 6.5.2. Importing a security policy You can import a security policy from the System Policies view on the RHACS portal. Procedure In the RHACS portal, go to Platform Configuration Policy Management . Click Import policy . In the Import policy JSON dialog, click Upload and select the JSON file you want to upload. 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.

Commands: