https://issues.redhat.com/browse/ACM-26213 note about fail-over

governance/gatekeeper_operator/config_gk_operator.adoc

@@ -3,17 +3,53 @@
 
 Install the {gate} from the {olm} catalog to install Gatekeeper on your cluster. With {acm-short} you can use a policy to install the {gate} by using the governance framework. After you install the {gate}, configure the {gate} custom resource to install Gatekeeper.
 
-[#configure-gk-operator-prerequisites]
-== Prerequisites
+*Required access*: Cluster administrator. 
 
-- *Required access*: Cluster administrator. 
+.Prerequisites
+
+- You need a {acm} or {ocp} Plus subscription to install Gatekeeper and apply Gatekeeper policies to your cluster.
 - Understand how to use the Operator Lifecycle Manager and the {ocp-catalog} by completing the _Adding Operators to a cluster_ and the _Additional resources_ section in the link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.18/html/operators/administrator-tasks#olm-adding-operators-to-a-cluster[{ocp-short} documentation].
 
-[#gatekeeper-custom-resource]
-== Gatekeeper custom resource sample
+.Procedure
+
+The {gate} custom resource tells the {gate} to start the Gatekeeper installation on the cluster. Complete the following steps to configure the {gate} custom resource:
+
+. Enable the `auditEventsInvolvedNamespace` parameter to manage the namespace audit event you want to create. When you enable this parameter, the Gatekeeper controller deployment runs with the following argument: `--audit-events-involved-namespace=true`.
+
+. Specify `containerArguments` in the `audit` and `webhook` specification by providing a list of argument names and values to pass to the container. Omit leading dashes from the argument name. An omitted value is treated as `true`. Arguments that you provide are ignored if the argument is set previously by the operator or configurations from other fields. See the following list of flags that are deny-listed and are not currently supported:
+
++
+- `port`
+- `prometheus-port`
+- `health-addr`
+- `validating-webhook-configuration-name`
+- `mutating-webhook-configuration-name`
+- `disable-cert-rotation`
+- `client-cert-name`
+- `tls-min-version`
+
+. For Gatekeeper version 3.20 and later, specify `audit.podAnnotations` that are specific to the audit pod by providing a list of annotation names and values to add to the pod. An omitted value is treated as `true`.
+
+. Enable the `admissionEventsInvolvedNamespace` parameter to manage the namespace admission event you want to create. When you enable this parameter, the Gatekeeper controller deployment runs with the following argument: `--admission-events-involved-namespace=true`.
+
+. *Optional:* If you want to enforce your Gatekeeper constraints, set the `failurePolicy` parameter to `Fail`. By default, the `failurePolicy` parameter for Gatekeeper is set to `Ignore`. If the Gatekeeper webhook becomes unavailable, constraints are not enforced.
+
+. Define `operations` for your webhook. Use one or more of the following supported values: `CREATE`, `UPDATE`, `CONNECT`, and `DELETE`.
+
+. For version 3.20 and later, specify `rules` to overwrite the `rules` configuration in the `webhook` configuration. The `rules` parameter preceeds the `operations` field.
 
-The {gate} custom resource tells the {gate} to start the Gatekeeper installation on the cluster. To install Gatekeeper, use the following sample YAML, which includes sample and default values:
+. For version 3.20 and later, specify the timeout for the webhook configuration by defining a value for the `timeoutSeconds` parameter.
 
+. For version 3.20 and later, configure the mutating webhook by adding configurations for the `mutatingWebhookConfig` specification. The configurations override the values from `spec.webhook` or are specific to the mutating webhook.
+
+. Use the `config` section to exclude namespaces from certain processes for all constraints on your cluster.
+
+. The `disableDefaultMatches` parameter is a boolean parameter that disables appending the default exempt namespaces provided by the Gatekeeper operator. The default exempt namespaces are {ocp-short} or Kubernetes system namespaces. By default, this parameter is set to `false` to allow the default namespaces to be appended.
+
++
+See the following sample YAML file:
+
++
 [source,yaml]
 ----
 apiVersion: operator.gatekeeper.sh/v1alpha1
@@ -23,11 +59,11 @@ metadata:
 spec:
   audit:
     auditChunkSize: 66
-    auditEventsInvolvedNamespace: Enabled <1>
+    auditEventsInvolvedNamespace: Enabled
     auditFromCache: Enabled
     auditInterval: 10s
     constraintViolationLimit: 55
-    containerArguments: <4>
+    containerArguments:
     - name: ""
       value: ""
     resources:
@@ -39,20 +75,20 @@ spec:
         memory: 130Mi
     emitAuditEvents: Enabled
     logLevel: DEBUG
-    podAnnotations: {} <2>
+    podAnnotations: {} 
     replicas: 1
   validatingWebhook: Enabled
   mutatingWebhook: Enabled
   webhook:
-    admissionEventsInvolvedNamespace: Enabled <3>
-    containerArguments: <4>
+    admissionEventsInvolvedNamespace: Enabled
+    containerArguments:
     - name: ""
       value: ""
     disabledBuiltins:
      - http.send
     emitAdmissionEvents: Enabled
     failurePolicy: Fail
-    operations: <5>
+    operations:
      - CREATE
      - UPDATE
      - CONNECT
@@ -64,25 +100,25 @@ spec:
       requests:
         cpu: 400m
         memory: 120Mi
-    rules: <6>
+    rules:
     - operations: []
       resources: []
-    timeoutSeconds: 3 <7>
-  mutatingWebhookConfig: <8>
+    timeoutSeconds: 3
+  mutatingWebhookConfig:
     failurePolicy: ""
     logMutations: Disabled
     mutationAnnotations: Disabled
     namespaceSelector: {}
     operations: []
-    rules: <6>
+    rules:
     - operations: []
       resources: []
-    timeoutSeconds: 1 <7>
-  config: <9>
+    timeoutSeconds: 1 
+  config:
     matches: 
       - excludedNamespaces: ["test-*", "my-namespace"] 
         processes: ["*"] 
-    disableDefaultMatches: false <10>
+    disableDefaultMatches: false
   nodeSelector:
     region: "EMEA"
   affinity:
@@ -100,34 +136,13 @@ spec:
     some-annotation: "this is a test"
     other-annotation: "another test"
 ----
-<1> Enable the `auditEventsInvolvedNamespace` parameter to manage the namespace audit event you want to create. When you enable this parameter, the Gatekeeper controller deployment runs with the following argument: `--audit-events-involved-namespace=true`.
-<2> For version 3.20 and later, specify `audit.podAnnotations` specific to the audit pod by providing a list of annotation names and values to add to the pod. An omitted value is treated as `true`.
-<3> Enable the `admissionEventsInvolvedNamespace` parameter to manage the namespace admission event you want to create. When you enable this parameter, the Gatekeeper controller deployment runs with the following argument: `--admission-events-involved-namespace=true`.
-<4> Specify `containerArguments` by providing a list of argument names and values to pass to the container. Omit leading dashes from the argument name. An omitted value is treated as `true`. Arguments that you provide are ignored if the argument is set previously by the operator or configurations from other fields. See the following list of flags that are deny-listed and are not currently supported:
-- `port`
-- `prometheus-port`
-- `health-addr`
-- `validating-webhook-configuration-name`
-- `mutating-webhook-configuration-name`
-- `disable-cert-rotation`
-- `client-cert-name`
-- `tls-min-version`
-<5> Use `operations` to manage the operations for which the webhook is invoked. For example, `CREATE`, `UPDATE`, `CONNECT`, and `DELETE`.
-<6> For version 3.20 and later, specify `rules` to overwrite the rules configuration in the webhook configuration. When set, this field takes precedence over the Operations field.
-<7> For version 3.20 and later, specify the timeout for the webhook configuration.
-<8> For version 3.20 and later, use the `mutatingWebhookConfig` section to configure the mutating webhook with configurations that override the values from `spec.webhook` or are specific to the mutating webhook.
-<9> Use the `config` section to exclude namespaces from certain processes for all constraints on your cluster.
-<10> The `disableDefaultMatches` parameter is a boolean parameter that disables appending the default exempt namespaces provided by the Gatekeeper operator. The default exempt namespaces are {ocp-short} or Kubernetes system namespaces. By default, this parameter is set to `false` to allow the default namespaces to be appended.
-
-[#config-audit-sync]
+
 == Configuring _auditFromCache_ for sync details
 
 The {gate} exposes a setting in the {gate} custom resource for the audit configuration with the `auditFromCache` parameter, which is disabled by default. Configure the `auditFromCache` parameter to collect resources from constraints.
 
 When you set the `auditFromCache` parameter to `Automatic`, the {gate} collects resources from constraints and inserts those resources into your Gatekeeper `Config` resource. If the resource does not exist, the {gate} creates the `Config` resource.
 
-If you set the `auditFromCache` parameter to `Enabled`, you need to manually set the Gatekeeper `Config` resource with the objects to sync to the cache. For more information, see _Configuring Audit_ in the Gatekeeper documentation.
-
 To configure the `auditFromCache` parameter for resource collection from constraints, complete the following steps: 
 
 . Set `auditFromCache` to `Automatic` in the `Gatekeeper` resource. See the following example:
@@ -146,6 +161,9 @@ spec:
     auditFromCache: Automatic
 ----
 
++
+*Note:* If you set the `auditFromCache` parameter to `Enabled`, you need to manually set the Gatekeeper `Config` resource with the objects to sync to the cache. For more information, see _Configuring Audit_ in the Gatekeeper documentation.
+
 . To verify that the resources are added to your `Config` resource, view that the `syncOnly` parameter section is added. Run the following command:
 
 +
@@ -175,14 +193,15 @@ spec:
      kind: "Pod"
 ----
 
-*Optional:* You can view the explanation of the `auditFromCache` setting from the description of the {gate} custom resource by running the following command:
+. *Optional:* You can view the explanation of the `auditFromCache` setting from the description of the {gate} custom resource by running the following command:
 
++
 [source,bash]
 ----
 oc explain gatekeeper.spec.audit.auditFromCache
 ----
 
-[#gk-add-resources]
-== Additional resources 
+.Additional resources 
 
 - For more information, see link:https://open-policy-agent.github.io/gatekeeper/website/docs/audit/#configuring-audit[Configuring Audit] in the Gatekeeper documentation.
+- For more information about configuring fail-open and fail-closed behavior, see link:https://open-policy-agent.github.io/gatekeeper/website/docs/failing-closed[Gatekeeper documentation].

governance/gatekeeper_operator/general_support.adoc

@@ -1,11 +1,13 @@
 [#general-support]
 = General support
 
+Red Hat supports only the Gatekeeper Operator and does not support individual Gatekeeper policies. Support ensures that the operator is functioning. To receive support, you need a {acm} or {ocp} Plus subscription for installing Gatekeeper and applying Gatekeeper policies to your cluster.
+
 To understand the support you receive from the {gate}, see the following list:
 
 - Supports current version of the {gate}, preceding versions, and all z-stream releases of those versions.
 - Receive maintenance support and relevant security vulnerability fixes for preceding and current versions. 
 - Support for all {ocp} versions that receive standard support.
 *Note*: The {gate} is not supported on end-of-life {ocp-short} versions or versions that receive extended support.
 
-To view the release notes for the {gate}, see link:https://catalog.redhat.com/software/containers/gatekeeper/gatekeeper-operator-bundle/64ba9da52b6048f1d6695232[gatekeeper-operator-bundle]. 
+To view the release notes for the {gate}, see link:https://catalog.redhat.com/software/containers/gatekeeper/gatekeeper-operator-bundle/64ba9da52b6048f1d6695232[gatekeeper-operator-bundle]. 

governance/gatekeeper_operator/gk_operator_overview.adoc

@@ -8,12 +8,10 @@ The {gate} installs Gatekeeper, which is a validating webhook with auditing capa
 - Evaluate Kubernetes resource compliance requests for the Kubernetes API by using the Gatekeeper constraints.
 - Use OPA as the policy engine and use Rego as the policy language.
 
-*Prerequisite:* You need a {acm} or {ocp} Plus subscription to install Gatekeeper and apply Gatekeeper policies to your cluster.
-
 To learn more about using the {gate}, see the following resources:
 
 - xref:../gatekeeper_operator/general_support.adoc#general-support[General support]
 - xref:../gatekeeper_operator/channels.adoc#operator-channels[Operator channels]
 - xref:../gatekeeper_operator/config_gk_operator.adoc#config-gk-operator[Configuring the {gate}]
 - xref:../gatekeeper_operator/manage_gk.adoc#managing-gk-policies[Managing the {gate} installation policies]
-- xref:../gatekeeper_operator/gk_policy_constraints.adoc#integrate-gk-constraints-templates[Integrating Gatekeeper constraints and constraint templates]
+- xref:../gatekeeper_operator/gk_policy_constraints.adoc#integrate-gk-constraints-templates[Integrating Gatekeeper constraints and constraint templates]

governance/gatekeeper_operator/gk_policy_constraints.adoc

@@ -1,7 +1,9 @@
 [#integrate-gk-constraints-templates]
 = Integrating Gatekeeper constraints and constraint templates
 
-To create Gatekeeper policies, use `ConstraintTemplates` and constraints. Add templates and constraints to the `policy-templates` of a `Policy` resource. View the following YAML examples that use Gatekeeper constraints in {acm-short} policies:
+Integrate Gatekeeper constraints and constraint templates for multicluster distribution of Gatekeeper constraints and audit results. Configure constraints by creating a configuration policy to check for Kubernetes API requests denied by the Gatekeeper admission webhook. To create Gatekeeper policies, use `ConstraintTemplates` resources and constraints. Add templates and constraints to the `policy-templates` of a `Policy` resource.
+
+View the following YAML examples that use Gatekeeper constraints in {acm-short} policies:
 
 * `ConstraintTemplates` and constraints: Use the Gatekeeper integration feature by using {acm-short} policies for multicluster distribution of Gatekeeper constraints and Gatekeeper audit results aggregation on the hub cluster. The following example defines a Gatekeeper `ConstraintTemplate` and constraint (`K8sRequiredLabels`) to ensure the `gatekeeper` label is set on all namespaces:
 

governance/gatekeeper_operator/manage_gk.adoc

@@ -5,6 +5,10 @@ Use the {acm-short} policy to install the {gate} and Gatekeeper on a managed clu
 
 *Required access*: Cluster administrator
 
+.Prerequisite
+
+- You need a {acm} or {ocp} Plus subscription to install Gatekeeper and apply Gatekeeper policies to your cluster.
+
 To create, view, and update your {gate} installation policies, complete the following sections: 
 
 - <<installing-gk-operator-policy,Installing Gatekeeper using a {gate} policy>>