Custom security policies - Managing security policies | Operating | Red Hat Advanced Cluster Security for Kubernetes 4.6

Creating a security policy from the system policies view
- Adding logical conditions for the policy criteria
Creating a security policy from the risk view
Modifying existing security policies
Managing polices as code

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.

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.

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

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.

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.

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

Attach notifiers to the policy to send policy violations to email recipients or external tooling such as Jira, Splunk, or other applications that use webhooks.

Select the notifiers from the list.

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.

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.

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.

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

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.

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.

Managing polices as code

You can create and manage policies as code by saving policies as Kubernetes custom resources (CRs) and applying them to clusters by using a Kubernetes-native continuous delivery (CD) tool such as Argo CD.

Policy as code is 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.

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.

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.

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.

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
# ...
```
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.

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.