Managing security policies

Using default security policies
Modifying existing security policies
Creating policy categories
Creating custom policies
Sharing security policies
- Exporting a security policy
- Importing a security policy

Red Hat Advanced Cluster Security for Kubernetes allows you to use out-of-the-box security policies and define custom multi-factor policies for your container environment. Configuring these policies enables you to automatically prevent high-risk service deployments in your environment and respond to runtime security incidents.

Using default security policies

Red Hat Advanced Cluster Security for Kubernetes includes a set of default policies that provide broad coverage to identify security issues and ensure best practices for security in your environment.

To view the default policies:

On the RHACS portal, navigate to Platform Configuration → Policies.

The Policies view lists the default policies and includes the following parameters for each policy:

Policy: A name for the policy.
Description: A longer, more detailed description of the alert for the policy.
Status: The current status of the policy, either Enabled or Disabled.
Notifiers: The list of notifiers that are configured for the policy.
Severity: A ranking of the policy, either critical, high, medium, or low, for the amount of attention required.
Lifecycle: The phase of the container lifecycle (build, deploy, or runtime) that this policy applies to, and the phase at which enforcement applies, when the policy is enabled.

The default policies have preconfigured parameters and belong to categories such as:

Anomalous Activity
Cryptocurrency Mining
DevOps Best Practices
Kubernetes
Network Tools
Package Management
Privileges
Security Best Practices
System Modification
Vulnerability Management

You can edit these categories and create your own categories. When you create your own category, a new widget displays information about that category on the dashboard.

You cannot delete default policies or edit policy criteria for default policies.

Modifying existing security policies

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

Procedure

On the RHACS portal, navigate to Platform Configuration → Policies.
From the Policies page, select the policy you want to edit.
Select Actions → Edit policy.
Modify the Policy details. You can modify the policy name, severity, categories, description, rationale, and guidance. You can also attach notifiers to the policy by selecting from the available Notifiers under the Attach notifiers section.
Click Next.
In the Policy behavior section, select the Lifecycle stages and Event sources for the policy.
Select a Response method to address violations for the policy.
Click Next.
In the Policy criteria section, expand the categories under the Drag out policy fields section. Use the drag-and-drop policy fields to specify logical conditions for the policy criteria.

You cannot edit policy criteria for default policies.
Click Next.
In the Policy scope section, modify Restrict by scope, Exclude by scope, and Exclude images settings.
Click Next.
In the Review policy section, preview the policy violations.
Click Save.

Additional resources

Creating a security policy from the system policies view

Creating policy categories

You can create new policy categories from the system policies view.

Procedure

On the RHACS portal, navigate to Platform Configuration → Policies.
From the Policies page, select the policy you want to edit.
Select Actions → Edit policy.
Enter a new category name in the Categories field and then click Create <category>.
Click the Review policy section heading.
Click Save.

After you save the configuration, the new category displays on the dashboard if there are any violations for policies in the category.

Additional resources

Creating a security policy from the system policies view

Creating custom policies

In addition to using the default policies, you can also create custom policies in Red Hat Advanced Cluster Security for Kubernetes.

To build a new policy, you can clone an existing policy or create a new one from scratch.

You can also create policies based on the filter criteria in the Risk view in the RHACS portal.
You can also use AND, OR, and NOT logical operators for policy criteria to create advanced policies.

Creating a security policy from the system policies view

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

Procedure

On the RHACS portal, navigate to Platform Configuration → Policies.
Click Create policy.
Enter the following details about your policy in the Policy details section:
- Enter a Name for the policy.
- Optional: Attach notifiers to the policy by selecting from the available Notifiers under the Attach notifiers section.
  
  You must integrate Red Hat Advanced Cluster Security for Kubernetes with your notification provider, for example, webhooks, Jira, PagerDuty, Splunk, or others before you can forward alerts.
- Select a Severity level for this policy, either Critical, High, Medium, or Low.
- Select policy Categories you want to apply to this policy.
- Enter details about the policy in the Description box.
- Enter an explanation about why the policy exists in the Rationale box.
- Enter steps to resolve violations of this policy in the Guidance box.
- Optional: 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 dropdown list.
  2. Click the Add technique to add techniques for the selected tactic. You can specify multiple techniques for a tactic.
Click Next.
In the Policy behavior section, select the Lifecycle stages and Event sources (Runtime lifecycle only) for the policy.
- Choose Lifecycle Stages to which your policy is applicable, from Build, Deploy, or Runtime. You can select more than one stage.
  - Build-time policies apply to image fields such as CVEs and Dockerfile instructions.
  - Deploy-time policies can include all build-time policy criteria but they can also include data from your cluster configurations, such as running in privileged mode or mounting the Docker socket.
  - Runtime policies can include all build-time and deploy-time policy criteria but they can also include data about process executions during runtime.

For Response method, either select:

Inform to include the violation in the violations list.

Or select Inform and enforce to enforce actions.

Choose the enforcement behavior for the policy. It is only available for the stages you select when configuring Lifecycle Stages. Select ON (enable) to enforce policy and report a violation, and OFF (disable) to only report a violation. The enforcement behavior is different for each lifecycle stage.

Build - Red Hat Advanced Cluster Security for Kubernetes fails your continuous integration (CI) builds when images match the conditions of the policy.
Deploy - Red Hat Advanced Cluster Security for Kubernetes blocks creation of deployments that match the conditions of the policy. In clusters with admission controller enforcement, the Kubernetes or OpenShift Container Platform API server blocks all noncompliant deployments. In other clusters, Red Hat Advanced Cluster Security for Kubernetes edits noncompliant deployments to prevent pods from being scheduled.

Runtime - Red Hat Advanced Cluster Security for Kubernetes kills all pods that match the conditions of the policy or blocks the action taken on the pods.

Policy enforcement can impact running applications or development processes. Before you enable enforcement options, inform all stakeholders and plan about how to respond to automated enforcement actions.

Click Next.
In the Policy Criteria section, configure the attributes that you you want to trigger the policy for.
Click Next.

In the Policy scope section, configure the following:

Click Add inclusion scope to use Restrict to Scope to enable this policy only for a specific cluster, a namespace, or a label. You can add multiple scopes and also use regular expressions in RE2 Syntax for namespaces and labels.
Click Add exclusion scope to use Exclude by Scope to exclude deployments, clusters, namespaces, and labels you specify, it means that the policy will not apply to the entities that you select. You can add multiple scopes and also use regular expressions in RE2 Syntax for namespaces and labels. However, you cannot use regular expressions for selecting deployments.

For Excluded Images (Build Lifecycle only), select all images that you do not want to trigger a violation for.

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.
In the Review policy section, preview the policy violations.
Click Save.

Additional resources

Policy criteria

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

Navigate 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

Policy criteria

In the Policy Criteria section you can configure the data on which you want to trigger a policy.

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

In this table:

The Regular expressions, AND, OR, and NOT columns indicate whether you can use regular expressions and other logical operators along with the specific attribute.
- ! in the Regular expressions column indicates that you can only use regular expressions for the listed fields.
- ! in the AND, OR column indicates that you can only use the mentioned logical operator for the attribute.
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.

To use logical operators AND, OR, and NOT for creating security policies, you need Red Hat Advanced Cluster Security for Kubernetes version 3.0.45 or newer. However, on earlier versions you can still use regular expressions for the fields listed in the Regular expressions column.

Attribute Description RHACS version Regular expressions NOT AND, OR Phase

Attribute	Description	RHACS version	Regular expressions	NOT	AND, OR	Phase
Namespace	The name of the namespace.	3.0.51 and newer	✓	✓	✓	Deploy
Image Registry	The name of the image registry.	All	✓	✓	✓	Deploy
Image Remote	The full name of the image in registry, for example `library/nginx`.	All	✓	✓	✓	Deploy
Image Tag	Identifier for an image.	All	✓	✓	✓	Deploy
Days since image was created	The number of days from image creation date.	All	✕	✕	✕	Build
Days since image was last scanned	The number of days since the last image scan.	All	✕	✕	✕	Build
Dockerfile Line	A specific line in the Dockerfile, including both instructions and arguments.	All	! only for values	✕	✓	Build
Image is NOT Scanned	No scan data is available for the image.	All	✕	✕	✕	Build
CVSS	Common Vulnerability Scoring System, use it to match images with vulnerabilities whose scores are greater than `>`, less than `<`, or equal to `=` the specified CVSS.	All	✕	✕	✓	Build
Fixed By	The version string of a package that fixes a flagged vulnerability in an image.	All	✓	✓	✓	Build
CVE	Common Vulnerabilities and Exposures, use it with specific CVE numbers.	All	✓	✓	✓	Build
Image Component	Name and version number of a specific software component present in an image.	All	✓	✕	✓	Build
Image OS	Name and version number of the base operating system of the image.	3.0.47 and newer	✓	✓	✓	Build
Environment Variable	Check environment variables by name or value.	All	! only for key and value	✕	✓	Deploy
Disallowed Annotation	An annotation which is not allowed to be present on Kubernetes resources in a specified environment.	All	✓	✕	✓	Deploy
Disallowed Image Label	Check for the presence of a Docker image label that should not be in use. 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 `Disallowed Image Label` policy criteria only works when you integrate with a Docker registry.	3.0.40 and newer	✓	✕	✓	Deploy
Required Image Label	Check for the presence of a required 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 `Required Image Label` policy criteria only works when you integrate with a Docker registry.	3.0.40 and newer	✓	✕	✓	Deploy
Required Label	Check for the presence of a required label in Kubernetes.	All	✓	✕	✓	Deploy
Required Annotation	Check for the presence of a required annotation in Kubernetes.	All	✓	✕	✓	Deploy
Volume Name	Name of the storage.	All	✓	✓	✓	Deploy
Volume Source	Indicates the form in which the volume is provisioned. For example, `persistentVolumeClaim` or `hostPath`.	All	✓	✓	✓	Deploy
Volume Destination	The path where the volume is mounted.	All	✓	✓	✓	Deploy
Volume Type	The type of volume.	All	✓	✓	✓	Deploy
Writable Volume	Volumes that are mounted as writable.	All	✕	✕	✕	Deploy
Protocol	Protocol, such as, TCP or UDP, that is used by the exposed port.	All	✓	✓	✓	Deploy
Port	Port numbers exposed by a deployment.	All	✕	✓	✓	Deploy
Privileged	Privileged running deployments.	All	✕	✕	✕	Deploy
Read-Only Root Filesystem	Containers running with the root file system configured as read only.	All	✕	✕	✕	Deploy
Drop Capabilities	Linux capabilities that must be dropped from the container. For example `CAP_SETUID` or `CAP_NET_RAW`.	All	✕	✕	✓	Deploy
Add Capabilities	Linux capabilities that must not be added to the container, for instance the ability to send raw packets or override file permissions.	All	✕	✕	✓	Deploy
Process Name	Name of the process executed in a deployment.	All	✓	✓	✓	Runtime
Process Ancestor	Name of any parent process for a process executed in a deployment.	All	✓	✓	✓	Runtime
Process Arguments	Command arguments for a process executed in a deployment.	All	✓	✓	✓	Runtime
Process UID	Unix user ID for a process executed in a deployment.	All	✕	✓	✓	Runtime
Port Exposure	Exposure method of the service, for example, load balancer or node port.	All	✕	✓	✓	Deploy
Service Account	The name of the service account.	All	✓	✓	✓	Deploy
Writable Host Mount	Resource has mounted a path on the host with write permissions.	All	✕	✕	✕	Deploy
Unexpected Process Executed	Check deployments for which process executions are not listed in the deployment’s locked process baseline.	All	✕	✕	✕	Runtime
Minimum RBAC Permissions	Match if the deployment’s Kubernetes service account has Kubernetes RBAC permission level equal to `=` or greater than `>` the specified level.	All	✕	✓	✕	Deploy
Container Name	The name of the container.	3.0.52 and newer	✓	✓	✓	Deploy
Container CPU Request	Check for the number of cores reserved for a given resource.	All	✕	✕	✓	Deploy
Container CPU Limit	Check for the maximum number of cores a resource is allowed to use.	All	✕	✕	✓	Deploy
Container Memory Request	Check for the amount of memory reserved for a given resource.	All	✕	✕	✓	Deploy
Container Memory Limit	Check for the maximum amount of memory a resource is allowed to use.	All	✕	✕	✓	Deploy
Kubernetes Action	The name of the Kubernetes action, such as `Pod Exec`.	3.0.55 and newer	✕	✕	! `OR` only	Runtime
Kubernetes Resource	The name of the accessed Kubernetes resource, such as `configmaps` or `secrets`.	3.63 and newer	✕	✕	! `OR` only	Runtime
Kubernetes Resource Name	The name of the accessed Kubernetes resource.	3.63 and newer	✓	✓	! `OR` only	Runtime
Kubernetes API Verb	The Kubernetes API verb that is used to access the resource, such as `GET` or `POST`.	3.63 and newer	✕	✕	! `OR` only	Runtime
Kubernetes User Name	The name of the user who accessed the resource.	3.63 and newer	✓	✓	! `OR` only	Runtime
Kubernetes User Group	The name of the group to which the user who accessed the resource belongs to.	3.63 and newer	✓	✕	! `OR` only	Runtime
User Agent	The user agent that the user used to access the resource. For example `oc`, or `kubectl`.	3.63 and newer	✓	✓	! `OR` only	Runtime
Source IP Address	The IP address from which the user accessed the resource.	3.63 and newer	✓	✓	! `OR` only	Runtime
Is Impersonated User	Check if the request was made by a user that is impersonated by a service account or some other account.	3.63 and newer	✕	✕	✕	Runtime
Runtime Class	The RuntimeClass of the deployment.	3.67 and newer	✓	✓	✓	Deploy
Automount Service Account Token	Check if the deployment configuration automatically mounts the service account token.	3.68 and newer	✕	✕	✕	Deploy
Liveness Probe	Whether the container defines a liveness probe.	3.69 and newer	✕	✕	✕	Deploy
Readiness Probe	Whether the container defines a readiness probe.	3.69 and newer	✕	✕	✕	Deploy
Replicas	The number of deployment replicas.	3.69 and newer	✕	✓	✓	Deploy
Privilege escalation	Provides alerts when a development is configured to allow a container process to gain more privileges than its parent process.	3.70 and later	✕	✕	✕	Deploy
Ingress Network Policy	Check the presence or absence of ingress Kubernetes network policies.	3.70 and later	✕	✕	✓	Deploy
egress Network Policy	Check the presence or absence of egress Kubernetes network policies.	3.70 and later	✕	✕	✓	Deploy
Not verified by trusted image signers	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.	3.70 and later	✕	✕	! `OR` only	Deploy

Namespace

The name of the namespace.

3.0.51 and newer

✓

Deploy

Image Registry

The name of the image registry.

All

✓

Deploy

Image Remote

The full name of the image in registry, for example library/nginx.

All

✓

Deploy

Image Tag

Identifier for an image.

All

✓

Deploy

Days since image was created

The number of days from image creation date.

All

Build

Days since image was last scanned

The number of days since the last image scan.

All

Build

Dockerfile Line

A specific line in the Dockerfile, including both instructions and arguments.

All

! only for values

✓

Build

Image is NOT Scanned

No scan data is available for the image.

All

Build

CVSS

Common Vulnerability Scoring System, use it to match images with vulnerabilities whose scores are greater than >, less than <, or equal to = the specified CVSS.

All

✓

Build

Fixed By

The version string of a package that fixes a flagged vulnerability in an image.

All

✓

Build

CVE

Common Vulnerabilities and Exposures, use it with specific CVE numbers.

All

✓

Build

Image Component

Name and version number of a specific software component present in an image.

All

✓

Build

Image OS

Name and version number of the base operating system of the image.

3.0.47 and newer

✓

Build

Environment Variable

Check environment variables by name or value.

All

! only for key and value

✓

Deploy

Disallowed Annotation

An annotation which is not allowed to be present on Kubernetes resources in a specified environment.

All

✓

Deploy

Disallowed Image Label

Check for the presence of a Docker image label that should not be in use. 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 Disallowed Image Label policy criteria only works when you integrate with a Docker registry.

3.0.40 and newer

✓

Deploy

Required Image Label

Check for the presence of a required 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 Required Image Label policy criteria only works when you integrate with a Docker registry.

3.0.40 and newer

✓

Deploy

Required Label

Check for the presence of a required label in Kubernetes.

All

✓

Deploy

Required Annotation

Check for the presence of a required annotation in Kubernetes.

All

✓

Deploy

Volume Name

Name of the storage.

All

✓

Deploy

Volume Source

Indicates the form in which the volume is provisioned. For example, persistentVolumeClaim or hostPath.

All

✓

Deploy

Volume Destination

The path where the volume is mounted.

All

✓

Deploy

Volume Type

The type of volume.

All

✓

Deploy

Writable Volume

Volumes that are mounted as writable.

All

Deploy

Protocol

Protocol, such as, TCP or UDP, that is used by the exposed port.

All

✓

Deploy

Port

Port numbers exposed by a deployment.

All

✓

Deploy

Privileged

Privileged running deployments.

All

Deploy

Read-Only Root Filesystem

Containers running with the root file system configured as read only.

All

Deploy

Drop Capabilities

Linux capabilities that must be dropped from the container. For example CAP_SETUID or CAP_NET_RAW.

All

✓

Deploy

Add Capabilities

Linux capabilities that must not be added to the container, for instance the ability to send raw packets or override file permissions.

All

✓

Deploy

Process Name

Name of the process executed in a deployment.

All

✓

Runtime

Process Ancestor

Name of any parent process for a process executed in a deployment.

All

✓

Runtime

Process Arguments

Command arguments for a process executed in a deployment.

All

✓

Runtime

Process UID

Unix user ID for a process executed in a deployment.

All

✓

Runtime

Port Exposure

Exposure method of the service, for example, load balancer or node port.

All

✓

Deploy

Service Account

The name of the service account.

All

✓

Deploy

Writable Host Mount

Resource has mounted a path on the host with write permissions.

All

Deploy

Unexpected Process Executed

Check deployments for which process executions are not listed in the deployment’s locked process baseline.

All

Runtime

Minimum RBAC Permissions

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

All

✓

Deploy

Container Name

The name of the container.

3.0.52 and newer

✓

Deploy

Container CPU Request

Check for the number of cores reserved for a given resource.

All

✓

Deploy

Container CPU Limit

Check for the maximum number of cores a resource is allowed to use.

All

✓

Deploy

Container Memory Request

Check for the amount of memory reserved for a given resource.

All

✓

Deploy

Container Memory Limit

Check for the maximum amount of memory a resource is allowed to use.

All

✓

Deploy

Kubernetes Action

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

3.0.55 and newer

! OR only

Runtime

Kubernetes Resource

The name of the accessed Kubernetes resource, such as configmaps or secrets.

3.63 and newer

! OR only

Runtime

Kubernetes Resource Name

The name of the accessed Kubernetes resource.

3.63 and newer

✓

! OR only

Runtime

Kubernetes API Verb

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

3.63 and newer

! OR only

Runtime

Kubernetes User Name

The name of the user who accessed the resource.

3.63 and newer

✓

! OR only

Runtime

Kubernetes User Group

The name of the group to which the user who accessed the resource belongs to.

3.63 and newer

✓

! OR only

Runtime

User Agent

The user agent that the user used to access the resource. For example oc, or kubectl.

3.63 and newer

✓

! OR only

Runtime

Source IP Address

The IP address from which the user accessed the resource.

3.63 and newer

✓

! OR only

Runtime

Is Impersonated User

Check if the request was made by a user that is impersonated by a service account or some other account.

3.63 and newer

Runtime

Runtime Class

The RuntimeClass of the deployment.

3.67 and newer

✓

Deploy

Automount Service Account Token

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

3.68 and newer

Deploy

Liveness Probe

Whether the container defines a liveness probe.

3.69 and newer

Deploy

Readiness Probe

Whether the container defines a readiness probe.

3.69 and newer

Deploy

Replicas

The number of deployment replicas.

3.69 and newer

✓

Deploy

Privilege escalation

Provides alerts when a development is configured to allow a container process to gain more privileges than its parent process.

3.70 and later

Deploy

Ingress Network Policy

Check the presence or absence of ingress Kubernetes network policies.

3.70 and later

✓

Deploy

egress Network Policy

Check the presence or absence of egress Kubernetes network policies.

3.70 and later

✓

Deploy

Not verified by trusted image signers

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.

3.70 and later

! OR only

Deploy

If you are using Red Hat Advanced Cluster Security for Kubernetes version 3.0.44 or older, the policy criteria you specify in the Policy criteria section are "AND"ed. It means that the violation only triggers if all the specified policy criteria match.

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.

Beginning from Red Hat Advanced Cluster Security for Kubernetes version 3.0.44, you can share your security policies between different Central instances, by exporting and importing policies. It helps you enforce the same standards for all your clusters. To share policies, you export them as JSON files, and then import them back into another Central instance.

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. On the RHACS portal, navigate to Help → API reference to see the API reference.

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

On the RHACS portal, navigate to Platform Configuration → Policies.
From the Policies page, select the policy you want to edit.
Select Actions → Export policy to JSON.

Importing a security policy

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

Procedure

On the RHACS portal, navigate to Platform Configuration → Policies.
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 Red Hat Advanced Cluster Security for Kubernetes has a unique ID (UID) and a unique name. When you import a policy, Red Hat Advanced Cluster Security for Kubernetes handles the uploaded policy as follows:

If the imported policy UID and name do not match any existing policy, Red Hat Advanced Cluster Security for Kubernetes 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. Red Hat Advanced Cluster Security for Kubernetes 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, Red Hat Advanced Cluster Security for Kubernetes 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.

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

Using default security policies

Modifying existing security policies

Creating policy categories

Creating custom policies

Creating a security policy from the system policies view

Creating a security policy from the risk view

Policy criteria

Adding logical conditions for the policy criteria

Sharing security policies

Exporting a security policy

Importing a security policy