ROX-19928: Updates to policy after 4.9 gui changes

modules/add-logical-conditions-policy-criteria.adoc

@@ -16,8 +16,8 @@ You can expand and collapse these categories to view the policy criteria attribu
 . 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.
+** If you select an attribute with Boolean values, such as `Read-Only Root Filesystem`, you will see `READ-ONLY` and `WRITABLE` options.
+** If you select an attribute with compound values, such as `Environment variable`, you will see options to enter values for `Key`, `Value`, and `Value From` fields, and an icon to add more values for the available options.
 .. To combine multiple values for an attribute, click the *Add* icon.
 .. You can also click on the logical operator `AND` or `OR` listed in a policy section, to toggle between `AND` and `OR` operators.
 Toggling between operators only works inside a policy section and not between two different policy sections.

modules/configure-policy-enforcement-creating-policies.adoc

@@ -12,17 +12,17 @@ You can configure if {product-title-short} should only inform you with a notific
 
 . 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*: {product-title-short} fails your continuous integration (CI) builds when images match the criteria of the policy.
-* *Deploy*: For the *Deploy* stage, {product-title-short} blocks the creation and update of deployments that match the conditions of the policy if the {product-title-short} admission controller is configured and running.
+* *Inform and enforce*: Include the violation in the violation list and enforce actions that you have configured. If you select this option, you must select the enforcement behavior for the policy by using the toggle for the appropriate lifecycles.
+. If you choose to enforce the policy, configure the enforcement behavior. 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*: Select *Enforce on Build* to have {product-title-short} fail your continuous integration (CI) builds when images match the criteria of the policy. You can download the `roxctl` CLI and configure the `roxctl image check` command to work with the policy.
+* *Deploy*: Select *Enforce on Deploy* to have {product-title-short} block workload admission and updates that match the conditions of the policy if the {product-title-short} admission controller is configured and running.
 ** In clusters with admission controller enforcement, the Kubernetes or {ocp} API server blocks all noncompliant deployments. In other clusters, {product-title-short} 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*: {product-title-short} deletes all pods when an event in the pods matches the criteria of the policy.
+** 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 "Deploy stage enforcement".
+* *Runtime*: Select *Enforce on Runtime* to have {product-title-short} delete 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.
-====
+====
+. Click *Next*.

modules/configure-policy-rules.adoc

@@ -11,25 +11,24 @@ You can use policy fields, or criteria, to create rules for your policies.
 
 .Procedure
 
-To create 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.
+. In the *Rules* section, configure the conditions that you want to trigger the policy. You can edit the rule titles; for example, you can change `Rule 1` to something more descriptive. 
 . 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.
+The policy fields that are available depend on the lifecycle stage you chose for the policy. For example, criteria under *Networking* or *Workload activity* are available when creating a policy for the runtime lifecycle, but not when creating a policy for the build lifecycle. For more information about policy criteria, including information about criteria and the lifecycle phase in which they are available, see "Policy criteria".
 ====
 . 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`, the `READ-ONLY` and `WRITABLE` options are available.
-* If you select an attribute with compound values `Environment variable`, you can enter values for the `Key`, `Value`, and `Value From` fields, and click the icon to add more values for the available options.
+* If you select an attribute with Boolean values, such as `Read-Only Root Filesystem`, the `READ-ONLY` and `WRITABLE` options are available.
+* If you select an attribute with compound values, such as `Environment variable`, you can enter values for the `Key`, `Value`, and `Value From` fields, and then click the icon to add more values for the available options.
 +
 [NOTE]
 ====
-See "Policy criteria" in the "Additional resources" section for more information.
+For more information about values available for policy criteria, see "Policy criteria".
 ====
 . To combine multiple values for an attribute, click the *Add* icon.
+. Optional: Click *Add a new rule* to add an additional rule.
 . Click *Next*.

modules/configure-policy-scope.adoc

@@ -10,19 +10,20 @@ You can define the scope of a policy to restrict or allow the policy for certain
 
 .Procedure
 
-. 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.
+. Configure any of the following options:
+* *Restrict by 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 expressions in link:https://github.com/google/re2/wiki/Syntax[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 expressions in link:https://github.com/google/re2/wiki/Syntax[RE2 Syntax] for namespaces and labels. However, you cannot use regular expressions for selecting deployments.
+* *Exclude by scope*: Excludes specific deployments, clusters, namespaces, and deployment labels from the policy. The policy will not apply to the entities that you select. You can add multiple scopes and also use regular expressions in link:https://github.com/google/re2/wiki/Syntax[RE2 Syntax] for namespaces and labels. However, you cannot use regular expressions 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.
+* *Exclude images*: For policies configured for the build lifecycle stage, you can exclude images from the policy. Select the images for which you do not want to trigger a violation.
 +
 [NOTE]
 ====
-The *Excluded Images* setting only applies when you check images in a continuous integration system with the *Build* lifecycle stage.
+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*.

modules/create-new-system-policy.adoc

@@ -60,7 +60,7 @@ The enforcement behavior is different for each lifecycle stage.
 * For the *Build* stage, {product-title-short} fails your CI builds when images match the conditions of the policy.
 * For the *Deploy* stage, {product-title-short} blocks the creation and update of deployments that match the conditions of the policy if the {product-title-short} admission controller is configured and running.
 ** In clusters with admission controller enforcement, the Kubernetes or {ocp} API server blocks all noncompliant deployments. In other clusters, {product-title-short} 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".
+** 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 "Deploy stage enforcement".
 * For the *Runtime* stage, {product-title-short} stops all pods that match the conditions of the policy.
 ====
 +

modules/enable-policy.adoc

@@ -0,0 +1,14 @@
+// Module included in the following assemblies:
+//
+// * operating/manage_security_policies/custom-security-policies.adoc
+:_mod-docs-content-type: PROCEDURE
+[id="enable-policy_{context}"]
+= Enable the policy
+
+[role="_abstract"]
+Enable or disable the policy.
+
+.Procedure
+
+. Select *Enable* make the policy active, or *Disable* to disable it.
+. Click *Next*.

modules/enter-policy-details.adoc

@@ -6,13 +6,13 @@
 = Entering policy details
 
 [role="_abstract"]
-Enter details about your policy, such as the name, severity, description, and guidance to resolve violations of the policy.
+Enter details about your policy, such as the name, severity, description, and guidance to resolve violations of the policy. Required fields are marked with an asterisk.
 
 .Procedure
 
-. Enter a *Name* for the policy.
+. Enter a *Name* for the policy. A policy must have a name between 5 and 128 characters, and cannot contain new lines or dollar signs.
 . Select a *Severity* level for this policy.
-. Select a policy category for the policy. This is a required field.
+. Select a policy category for the policy from the *Categories* list.
 . 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.

modules/modify-existing-security-policies.adoc

@@ -15,6 +15,6 @@ You can edit the policies you have created and the existing default policies pro
 +
 [NOTE]
 ====
-You cannot edit default policies. You must clone a default policy and edit the cloned policy.
+You cannot edit certain fields of default system policies. To make changes to a default policy, clone the policy and edit the copy.
 ====
 . Edit the fields that you want to change and click *Save*.