Questo contenuto non è disponibile nella lingua selezionata.

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

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 next detection of the criteria, when a Kubernetes event occurs. If you make changes to a policy, you must reassess policies by selecting Policy Management and clicking Reassess All. This action applies deploy policies on all existing deployments regardless of whether there are any new incoming Kubernetes events. If a policy is violated, then RHACS performs enforcement.

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.
1. Click Add tactic, and then select a tactic from the drop-down list.
2. Click the Add technique to add techniques for the selected tactic. You can specify multiple techniques for a tactic.
Click Next.

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

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

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

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 next detection of the criteria, when a Kubernetes event occurs. For more information about enforcement, see "Security policy enforcement for the deploy stage".
- Runtime: RHACS deletes all pods when an event in the pods matches the criteria of the policy.
  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.
1. 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 Next.

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.
  1. To combine multiple values for an attribute, click the Add icon.
  2. 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 Next 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.

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 by authoring them locally and then using a continuous delivery tool such as Argo CD to track, manage, and apply policies to your clusters that are running RHACS. You can also use the API to configure connections to your own GitOps repository such as GitHub. To author policies locally, you create CRs that represent the desired state of the policies. 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.

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 installs a new configuration controller in the namespace where Central is installed, typically the stackrox namespace. With an Argo CD workflow, you configure Argo CD to communicate with this controller in the stackrox namespace by using the Kubernetes API. 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:
```
$ 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:
```
$ 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.

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 6. Managing security policies

6.1. About security policies

6.1.1. Policy categories

6.1.1.1. Creating policy categories by using the Policy categories tab

6.1.1.2. Modifying policy categories by using the Policy categories tab

6.1.2. Understanding policies and lifecycle phases

6.1.3. Understanding rules and policy criteria

6.1.4. About policy enforcement

6.1.4.1. Security policy enforcement for the deploy stage

6.1.4.1.1. Hard enforcement

6.1.4.1.2. Soft enforcement

6.1.4.1.3. Namespace exclusions

6.1.4.1.4. Enforcement on existing deployments

6.1.5. Sharing security policies

6.1.5.1. Exporting a security policy

6.1.5.2. Importing a security policy

6.2. Custom security policies

6.2.1. Creating a security policy from the system policies view

Enter policy details

Configure the policy lifecycle

Configure the policy rules and criteria

Configure the policy scope

Configure policy actions

Review the policy and preview violations

6.2.1.1. Adding logical conditions for the policy criteria

6.2.2. Creating a security policy from the risk view

6.2.3. Modifying existing security policies

6.2.4. Managing polices as code

6.2.4.1. About policy drift

6.2.4.2. Creating policies in code by using the RHACS portal

6.2.4.3. Creating policies in code by constructing a CR

6.2.4.4. Disabling the policy as code feature

6.3. Default security policies

6.3.1. Critical severity security policies

6.3.2. High severity security policies

6.3.3. Medium severity security policies

6.3.4. Low severity security policies

6.3.5. Default security policies

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Rendiamo l’open source più inclusivo

Informazioni su Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links