Chapter 6. Managing security policies 6.1. About security policies Red Hat Advanced Cluster Security for Kubernetes provides out-of-the-box default security policies that you can use to prevent high-risk service deployments in your environment and respond to runtime security incidents. You can also create custom multi-factor policies for your container environment. 6.1.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. 6.1.1.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.1.1.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. 6.1.2. Understanding policies and lifecycle phases When configuring policies, you can select the lifecycle stages that apply to your policy, and you can select more than one stage for a policy. You can select from the following lifecycle stages: Build phase policies: These policies apply to image fields such as CVEs and Dockerfile instructions. Deploy phase policies: These policies can include all build-time policy criteria. They can also have data from your cluster configurations, such as running in privileged mode or mounting the Docker daemon socket. Runtime policies: These policies scan include all build-time and deploy-time policy criteria, and data about process executions during runtime. You can further configure runtime policies to trigger policy violations based on the following events: Deployments: RHACS triggers policy violations when event sources include process and network activity, such as executing a command in a pod and pod port forwarding. Audit logs: RHACS triggers policy violations when event sources match Kubernetes audit log records. 6.1.3. Understanding rules and 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 . 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.1.4. About policy enforcement When you configure policies in RHACS, you can choose how RHACS responds when it detects a condition that violates a security policy. RHACS can perform different types of policy enforcement, or actions that address a violation, depending on the phase in which the violation is discovered. When configuring policy enforcement, you can select multiple stages when configuring enforcement in the policy. For example, you can select Build and Deploy so that RHACS alerts the build pipeline to the problem, but if the developer allows the build to succeed, the deployment is prevented. In build time enforcement , 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 which 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 should fail. As an example, if you have configured RHACS to check an image or deployment and you have integrated that check into a CI/CD pipeline, if RHACS detects a condition that means a policy should fail, the RHACS API returns a non-zero exit code. The pipeline then uses that code to fail the build. In deploy time enforcement , RHACS works with Kubernetes admission controllers and OpenShift Container Platform admission plugins to allow you to enforce security policies. 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. 6.1.4.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.1.4.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.1.4.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.1.4.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.1.4.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. 6.1.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. 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 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.1.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.1.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. 6.2. Custom security policies In addition to using the default policies, you can also create custom policies in Red Hat Advanced Cluster Security for Kubernetes. You can create custom policies by using the following methods: In the RHACS portal, go to Platform configuration Policy management and click Create policy . In the RHACS portal, go to Risk and use the filter to select the criteria that you want the policy to use. Click Create policy . Create and manage policies as code by saving policies as Kubernetes custom resources (CRs) and by applying them to clusters using a continuous delivery tool such as Argo CD. See the following sections for more information. 6.2.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 . Configure the policy definition information in the following sections: Enter policy details Enter the following details about your policy in the Policy details section. Enter a Name for the policy. Select a Severity level for this policy. Select a policy category for the policy. This is a required field. 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. 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 . Configure the policy lifecycle In the Lifecycle section, complete the following steps: Select the Lifecycle stages to which your policy is applicable: Build , Deploy , or Runtime . You can select more than one stage from the following choices: 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. If you selected the Runtime lifecycle stage, you must select one of the following Event sources : Deployment : RHACS triggers policy violations when event sources include process and network activity, pod execution and pod port forwarding. Audit logs : RHACS triggers policy violations when event sources match Kubernetes audit log records. Click . Configure the policy rules and criteria To configure a policy rule: In the Rules section, configure the conditions that you want to trigger the policy. You can edit the rule titles and click Add a new rule to add an additional rule. 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 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. 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 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. Note See "Policy criteria" in the "Additional resources" section for more information. To combine multiple values for an attribute, click the Add icon. Click . Configure the policy scope Create scopes to restrict or exclude your policy from entities, such as cluster or namespaces, within your environment. To restrict by scope, click Add inclusion 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 expression in RE2 Syntax for namespaces and labels. To exclude by scope, for example, to exclude specific deployments, clusters, namespaces, and deployment labels from the policy, click Add exclusion scope . 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. Note This function is only available for policies configured for the deploy and runtime lifecycle stages. For policies configured for the build lifecycle stage, you can exclude images from the policy. In the Exclude images (Build lifecycle only) field, enter the 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 . Configure policy actions Configure the activation state, enforcement, and notifiers for the policy. Select an activation state for the policy. Select an enforcement method: Inform : Include the violation in the violations list. Inform and enforce : enforce actions. If you select this option, you must select the enforcement behavior for the policy by using the toggle for each lifecycle. 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 : 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 how to respond to automated enforcement actions. Attach notifiers to the policy to send policy violations to email recipients or external tooling such as Jira, Splunk, or other applications that use webhooks. Select the notifiers from the list. Note You must have previously configured the notification 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. Click . Review the policy and preview violations Review the policy settings you have configured. Verify that the policy configuration is configured with the correct options. The Preview violations panel provides additional information, including whether or not build phase or deploy phase deployments have violations of the policy. Note Runtime violations are not available in this preview because they are generated in response to future events. Before you save the policy, verify that the violations seem accurate. Click Save . 6.2.1.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.2.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 6.2.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 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 . Note You cannot edit default policies. You must clone a default policy and edit the cloned policy. Edit the fields that you want to change and click Save . 6.2.4. 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. Important Policy as code is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope . 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. 6.2.4.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. 6.2.4.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: USD kubectl create -f helm/chart/crds/config.stackrox.io_securitypolicies.yaml Procedure To create a new policy in code by using the RHACS portal to create the CR: In the Policy Management page, create a new policy or clone a default policy. Note You must clone a default policy before you can save it as a CR. In the row listing the policy, click the overflow menu, , and then select Save as Custom Resource . To save multiple policies at one time, you can select them and click Bulk actions Save as Custom Resources . After editing your policy, you can apply the saved CR by doing one of the following: Use the oc apply or kubectl apply command to apply the CR directly to the Kubernetes namespace where Central is installed. Use Argo CD or your GitOps tool to push the CR to the Kubernetes namespace where Central is installed. 6.2.4.3. Creating policies in code by constructing a CR You can create new policies in code by constructing a CR for the policy. Use an editor to construct a CR for the policy with the following attributes: kind: SecurityPolicy apiVersion: config.stackrox.io/v1alpha1 metadata: name: short-name spec: policyName: A longer form name # ... Tip Use online documentation, for example, by entering the kubectl explain securitypolicy.spec command, to understand the fields available for defining a policy specification. Apply the saved CR by doing one of the following: Use the oc apply or kubectl apply command to apply the CR directly to the Kubernetes namespace where Central is installed. Use Argo CD or your GitOps tool to push the CR to the Kubernetes namespace where Central is installed. 6.2.4.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 Enabled . If you installed RHACS by using Helm charts, set the configAsCode.enabled field in the values.yaml file to true . 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: USD kubectl -n stackrox delete deployment config-controller 1 1 For OpenShift Container Platform, use oc instead of kubectl . 6.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 . 6.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. Table 6.1. Critical severity security policies Life cycle stage Name Description Status Build or Deploy Apache Struts: CVE-2017-5638 Alerts when deployments have images that contain the CVE-2017-5638 Apache Struts vulnerability. Enabled Build or Deploy Log4Shell: log4j Remote Code Execution vulnerability Alerts when deployments include images that contain the CVE-2021-44228 and CVE-2021-45046 Log4Shell vulnerabilities. Flaws exist in the Apache Log4j Java logging library in versions 2.0-beta9 - 2.15.0, excluding version 2.12.2. Enabled Build or Deploy Spring4Shell (Spring Framework Remote Code Execution) and Spring Cloud Function vulnerabilities Alerts when deployments include images that contain either the CVE-2022-22965 vulnerability, which affects Spring MVC, and the CVE-2022-22963 vulnerability, which affects Spring Cloud. In versions 3.16, 3.2.2, and older unsupported versions, Spring Cloud contains flaws. Flaws exist in Spring Framework in versions 5.3.0 - 5.3.17, versions 5.2.0 - 5.2.19, and in older unsupported versions. Enabled Runtime Iptables Executed in Privileged Container Alerts when privileged pods run iptables. Enabled 6.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. Table 6.2. High severity security policies Life cycle stage Name Description Status Build or Deploy Fixable Common Vulnerability Scoring System (CVSS) >= 7 Alerts when deployments with fixable vulnerabilities have a CVSS of at least 7. However, Red Hat recommends that you create policies using Common Vulnerabilities and Exposures (CVE) severity instead of CVSS score. Disabled Build or Deploy Fixable Severity at least Important Alerts when deployments with fixable vulnerabilities have a severity rating of at least Important. Enabled Build or Deploy Rapid Reset: Denial of Service Vulnerability in HTTP/2 Protocol Alerts on deployments with images containing components that are susceptible to a Denial of Service (DoS) vulnerability for HTTP/2 servers. This addresses a flaw in the handling of multiplexed streams in HTTP/2. A client can rapidly create a request and immediately reset them, which creates extra work for the server while avoiding hitting any server-side limits, resulting in a denial of service attack. To use this policy, consider cloning the policy and adding the Fixable policy criteria before enabling it. Disabled Build or Deploy Secure Shell (ssh) Port Exposed in Image Alerts when deployments expose port 22, which is commonly reserved for SSH access. Enabled 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 6.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. Table 6.3. Medium severity security policies Life cycle stage Name Description Status Build Docker CIS 4.4: Ensure images are scanned and rebuilt to include security patches Alerts when images are not scanned and rebuilt to include security patches. It is important to scan images often to find vulnerabilities, rebuild the images to include security patches, and then instantiate containers for the images. Disabled Deploy 30-Day Scan Age Alerts when a deployment has not been scanned in 30 days. Enabled Deploy CAP_SYS_ADMIN capability added Alerts when a deployment includes containers that are escalating with CAP_SYS_ADMIN. Enabled Deploy Container using read-write root filesystem Alerts when a deployment includes containers that have read-write root file systems. Disabled Deploy Container with privilege escalation allowed Alerts when a container might be running with unintended privileges, creating a security risk. This situation can happen when a container process that has more privileges than its parent process allows the container to run with unintended privileges. Enabled Deploy Deployments should have at least one Ingress Network Policy Alerts if deployments are missing an Ingress Network Policy. Disabled Deploy Deployments with externally exposed endpoints Detects if a deployment has any service that is externally exposed through any methods. Deployments with services exposed outside of the cluster are at a higher risk of attempted intrusions because they are reachable outside of the cluster. This policy provides an alert so that you can verify that service exposure outside of the cluster is required. If the service is only needed for intra-cluster communication, use service type ClusterIP. Disabled Deploy Docker CIS 5.1: Ensure that, if applicable, an AppArmor profile is enabled Uses AppArmor to protect the Linux operating system and applications by enforcing a security policy that is known as an AppArmor profile. AppArmor is a Linux application security system that is available on some Linux distributions by default, such as Debian and Ubuntu. Enabled Deploy Docker CIS 5.15: Ensure that the host's process namespace is not shared Creates process-level isolation between the containers and the host. The Process ID (PID) namespace isolates the process ID space, which means that processes in different PID namespaces can have the same PID. Enabled Deploy Docker CIS 5.16: Ensure that the host's IPC namespace is not shared Alerts when the IPC namespace on the host is shared with containers. The IPC (POSIX/SysV IPC) namespace separates named shared memory segments, semaphores, and message queues. Enabled Deploy Docker CIS 5.19: Ensure mount propagation mode is not enabled Alerts when mount propagation mode is enabled. When mount propagation mode is enabled, you can mount container volumes in Bidirectional, Host to Container, and None modes. Do not use Bidirectional mount propagation mode unless it is explicitly needed. Enabled Deploy Docker CIS 5.21: Ensure the default seccomp profile is not disabled Alerts when the seccomp profile is disabled. The seccomp profile uses an allowlist to permit common system calls and blocks all others. Disabled Deploy Docker CIS 5.7: Ensure privileged ports are not mapped within containers Alerts when privileged ports are mapped within containers. The TCP/IP port numbers that are lower than 1024 are privileged ports. Normal users and processes can not use them for security reasons, but containers might map their ports to privileged ports. Enabled Deploy Docker CIS 5.9 and 5.20: Ensure that the host's network namespace is not shared Alerts when the host's network namespace is shared. When HostNetwork is enabled, the container is not placed inside a separate network stack, and the container's networking is not containerized. As a result, the container has full access to the host's network interfaces, and a shared UTS namespace is enabled. The UTS namespace provides isolation between the hostname and the NIS domain name, and it sets the hostname and the domain, which are visible to running processes in that namespace. Processes that run within containers do not typically require to know the hostname or the domain name, so the UTS namespace should not be shared with the host. Enabled Deploy Images with no scans Alerts when a deployment includes images that were not scanned. Disabled Runtime Kubernetes Actions: Port Forward to Pod Alerts when the Kubernetes API receives a port forward request. Enabled Deploy Mount Container Runtime Socket Alerts when a deployment has a volume mount on the container runtime socket. Enabled Deploy Mounting Sensitive Host Directories Alerts when a deployment mounts sensitive host directories. Enabled Deploy No resource requests or limits specified Alerts when a deployment includes containers that do not have resource requests and limits. Enabled Deploy Pod Service Account Token Automatically Mounted Protects pod default service account tokens from being compromised by minimizing the mounting of the default service account token to only those pods whose applications require interaction with the Kubernetes API. Enabled Deploy Privileged Container Alerts when a deployment includes containers that run in privileged mode. Enabled Runtime crontab Execution Detects the usage of the crontab scheduled jobs editor. Enabled Runtime Netcat Execution Detected Detects when netcat runs in a container. Enabled Runtime OpenShift: Advanced Cluster Security Central Admin Secret Accessed Alerts when someone accesses the Red Hat Advanced Cluster Security Central secret. Enabled Runtime OpenShift: Kubernetes Secret Accessed by an Impersonated User Alerts when someone impersonates a user to access a secret in the cluster. Enabled Runtime Remote File Copy Binary Execution Alerts when a deployment runs a remote file copy tool. Enabled 6.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. Table 6.4. Low severity security policies Life cycle stage Name Description Status Build or Deploy 90-Day Image Age Alerts when a deployment has not been updated in 90 days. Enabled Build or Deploy ADD Command used instead of COPY Alerts when 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 6.3.5. 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. You can use the RHACS portal to view default policies, clone them, and edit the cloned default policies. Note Default policies are not supported with the policies as code feature. 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. Policy categories : 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. Note You cannot delete default policies or edit policy criteria for default policies.

Commands:
kubectl create -f helm/chart/crds/config.stackrox.io_securitypolicies.yaml
kind: SecurityPolicy apiVersion: config.stackrox.io/v1alpha1 metadata: name: short-name spec: policyName: A longer form name
kubectl -n stackrox delete deployment config-controller 1