CHAOS-7562 Update chaosguard

docs/chaos-engineering/use-harness-ce/governance/governance-in-execution/_category_.json

@@ -1,6 +1,6 @@
 {
   "position": 50,
-  "label": "Governance in Execution",
+  "label": "ChaosGuard- Governance in Execution",
   "collapsed": "true",
   "customProps": {
     "description": "Set of policies, rules, and processes that manage and control how chaos experiments are created, executed, and monitored."

docs/chaos-engineering/use-harness-ce/governance/governance-in-execution/govern-run.md

@@ -16,19 +16,19 @@ This topic describes how you can configure **ChaosGuard** to enforce security po
 
 1. In the **Chaos** module, select **ChaosGuard**, and select **Conditions**. The **Conditions** page lists existing conditions (if any).
 
-	![navigate to chaos](./static/exec/navigate-1.png)
+	![navigate to chaos](../static/chaosguard/navigate-1.png)
 
 2. To create a condition, click **New condition**.
 
-	![new-condition](./static/exec/new-condition.png)
+	![new-condition](../static/chaosguard/new-condition.png)
 
 3. Provide a name, a description (optional), and tags (optional). Specify the infrastructure. If you select either **Linux** or **Windows**, click **Save**.
 
-	![infrastructure options](./static/exec/infra-options.png)
+	![infrastructure options](../static/chaosguard/infra-options.png)
 
-	3a. If you select **Kubernetes**, you can select one of **Harness Infrastructures** (or Harness Delegate) or **Dedicated Chaos Infrastructure**. Click **Save**.
+	3a. If you select **Kubernetes**, you can select one of **Harness Infrastructures** (also known as Harness Delegate) or **Dedicated Chaos Infrastructure**. Click **Save**.
 
-		![edit-condition](./static/exec/edit-condition.png)
+		![edit-condition](../static/chaosguard/edit-condition.png)
 
 This gives you 3 ways to define a condition from the **Condition Editor**:
 - [YAML manifest](#define-constraints-using-yaml)
@@ -39,33 +39,33 @@ This gives you 3 ways to define a condition from the **Condition Editor**:
 
 1. Select the **YAML** tab.
 
-	![select](./static/exec/select-1.png)
+	![select](../static/chaosguard/select-1.png)
 
-2. Specify the relevant values corresponding to the respective names. Click **Save**.
+2. Specify the relevant values corresponding to the respective names. Click **Save**. In this example, the YAML configuration indicates that a condition is applied to a fault named **pod-delete** with the specified **label**, **namespace**, and **serviceAccount**.
 
-	![yaml edit](./static/exec/yaml-edit.png)
+	![yaml edit](../static/chaosguard/yaml-edit.png)
 
 ### Define constraints using the visual editor
 
 1. To add conditions using a visual editor, navigate to the **VISUAL** tab of the condition you created earlier.
 
-	![condition](./static/exec/condition-create.png)
+	![condition](../static/chaosguard/condition-create.png)
 
-2. Add the **WHAT** clause. It blocks a fault that is **EQUAL TO** (or matches) or **NOT EQUAL TO** (everything else apart from the given value) pod delete. You can add more than one **WHAT** clause.
+2. Add the **WHAT** clause. It blocks a fault whose name is **EQUAL TO** (or matches) or **NOT EQUAL TO** (everything else apart from the given value) pod delete. You can add more than one **WHAT** clause. This clause also takes the experiment name as input.
 
-	![what](./static/exec/condition-what.png)
+	![what](../static/chaosguard/condition-what.png)
 
 3. Add the **WHERE** clause. It blocks one or more infrastructure. Select more than one infrastructure by hovering over the field.
 
-	![where](./static/exec/condition-where.png)
+	![where](../static/chaosguard/condition-where.png)
 
 4. Add the **WHICH** clause. It blocks the infrastructure that has specific entries for **APPLICATION MAP**, **SERVICES**, **NAMESPACE** (mandatory), **KIND** (mandatory), and **APP LABEL**. You can add more than one **WHICH** clause.
 
-	![which](./static/exec/condition-which.png)
+	![which](../static/chaosguard/condition-which.png)
 
 5. Add the **USING** clause. It blocks specific service account. You can add more than one service account by clicking the field and adding service account name to it. Click **Save**.
 
-	![using](./static/exec/condition-using.png)
+	![using](../static/chaosguard/condition-using.png)
 
 :::tip
 - You can use both **'EQUAL'** and **'NOT EQUAL TO'** operators in the condition logic for WHAT, WHERE, WHICH and USING. 
@@ -76,52 +76,52 @@ This gives you 3 ways to define a condition from the **Condition Editor**:
 
 1. Instead of selecting the required parameters, you can generate conditions with the help of Harness AIDA. AIDA assistant shows up when you are configuring a condition. You can choose one of the suggestions provided by Harness AIDA by clicking on it or writing something along the same lines as the suggestions.
 
-    ![aida suggestion](./static/exec/aida-sug-1.png)
+    ![aida suggestion](../static/chaosguard/aida-sug-1.png)
 
 2. When you type a condition, you will see that AIDA generates a YAML corresponding to your condition. If the YAML generated meets the conditions, you can click **Apply YAML**.
 
-    ![aida generation](./static/exec/aida-gen-2.png)
+    ![aida generation](../static/chaosguard/aida-gen-2.png)
 
 3. If the generated YAML does not meet your conditions, click **Try again**. In the snippet below, you will see that AIDA applies the YAML generated to the editor.
 
-    ![aida apply](./static/exec/aida-apply-3.png)
+    ![aida apply](../static/chaosguard/aida-apply-3.png)
 
 ### Save condition
 
 After you define the constraints of a condition either using [YAML](#define-constraints-using-yaml), [visual editor](#define-constraints-using-the-visual-editor), or [AIDA](#define-constraints-using-aida), select **Save**.
 
-    ![save constraints](./static/exec/save-constraint.png)
+    ![save constraints](../static/chaosguard/save-constraint.png)
 
 ## Configure a rule
 
 1. Click **New rule**.
 
-	![](./static/exec/new-rule.png)
+	![](../static/chaosguard/new-rule.png)
 
 2. Specify parameters such as name, description (optional), tags (optional), user group to apply the rule (you can apply the rule to multiple user groups), and time window to apply the rule. You can apply multiple time windows to apply the rule. Click **Next**.
 
-	![](./static/exec/add-des-2.png)
+	![](../static/chaosguard/add-des-2.png)
 
 3. Select user groups. Click **Apply Selected**.
 
-	![](./static/exec/usr-grp-3.png)
+	![](../static/chaosguard/usr-grp-3.png)
 
 4. Select a condition (or multiple conditions) that you wish to apply. Click **Done**.
 
-	![](./static/exec/select-cnd-4.png)
+	![](../static/chaosguard/select-cnd-4.png)
 
 	:::info note
 	* Below is a snap that shows a successful evaluation of all the rules in a chaos experiment.
 
-		![](./static/exec/rule-evaluation-pass.png)
+		![](../static/chaosguard/rule-evaluation-pass.png)
 
 	* Below is a snap that shows a failed evaluation of some (or all) rules in a chaos experiment.
 
-		![](./static/exec/rule-evaluation-fail.png)
+		![](../static/chaosguard/rule-evaluation-fail.png)
 	:::
 
 ### Enable and disable rules
 
 * The image below shows the two different states of a rule (enable and disable).
 
-	![chaosguard-rules](./static/exec/chaosguard-rules.png)
+	![chaosguard-rules](../static/chaosguard/chaosguard-rules.png)

docs/chaos-engineering/use-harness-ce/governance/governance-in-execution/governance-in-execution.md

@@ -28,8 +28,7 @@ The different levels of security policy enforcement include (but are not limited
 ## Flow of control
 The security evaluation step iterates over every active (or enabled) [rule](#rule) for every experiment run in the project. If the evaluation is successful, you can proceed with the experiment. Upon failure, you can't iterate further in the experiment. Below is a flowchart that summarizes the flow of control when you enable a ChaosGuard rule for a fault or set of faults.
 
-    ![flow-chart](./static/chaosguard/flow-chart-chaosguard.png)
-
+    ![flow-chart](../static/chaosguard-concepts/flow-chart-chaosguard.png)
 
 ## Low-level security governance requirements
 The table below describes the requirements for advanced environments.
@@ -85,10 +84,15 @@ A rule becomes active when all its conditions are met, controlling who can execu
 
 The example below describes the rule as **applicable on the cluster chaosday-k8s-cluster between [5 PM, Friday, Sept 15th] to [9 AM, Monday, Sept 18th] for the specific condition**.
 
-![rules-chaosguard](./static/chaosguard/add-conditions.png)
+![rules-chaosguard](../static/chaosguard-concepts/add-conditions.png)
 
 :::tip
 Creating the ChaosGuard rules is subject to Harness RBAC policies. By default, these rules are enabled only for the project admin. However, the admin can delegate this to trusted users (typically in multi- or secondary admin scenarios).
 
-![chaosguard-access-control](./static/chaosguard/chaosguard-access-control.png)
-:::
+![chaosguard-access-control](../static/chaosguard-concepts/chaosguard-access-control.png)
+:::
+
+## Next Steps
+
+- [Configure a Condition](/docs/chaos-engineering/use-harness-ce/governance/governance-in-execution/govern-run#configure-a-condition)
+- [Configure a Rule](/docs/chaos-engineering/use-harness-ce/governance/governance-in-execution/govern-run#configure-a-rule)