clean up examples and text around enforcement modes

Add PRR file

keps/sig-api-machinery/3488-cel-admission-control/README.md

@@ -443,7 +443,6 @@ spec:
     - key: environment,
       operator: In,
       values: ["test"]
-  enablement: Enabled
 ```
 
 ```yaml
@@ -474,7 +473,6 @@ spec:
     - key: environment,
       operator: NotIn,
       values: ["test"]
-  enablement: Enabled
 ```
 
 ```yaml
@@ -501,7 +499,6 @@ spec:
     namespaceSelectors:
     - key: environment,
       operator: Exists
-  enablement: Enabled
 ```
 
 With this binding, the test and global policy bindings overlap. Resources
@@ -560,12 +557,7 @@ Each `PolicyBinding` contains:
   validate
 - `spec.params` - Reference to the custom resource containing the params to use
   when validating resources 
-- `spec.enablement`:
-  - `Enforce` (default) - the validation enforcements apply
-  - `Canary` - for testing out a new binding during rollout, no failures of any
-    kind result in a deny, validations set to `enforcement: {deny: {...}}` are
-    redirected to `enforcement: {warning{}}`
-
+- `spec.mode` - See "Decisions and Enforcement" for details.
 
 Example:
 
@@ -581,7 +573,7 @@ spec:
     namespaceSelectors:
     - key: environment,
       operator: Exists
-  enablement: Canary
+  mode: DryRun
 ```
 
 Each parameter CRD defines the custom resources that are referenced by the
@@ -902,11 +894,6 @@ Policy bindings:
 
 - `mode` may be set to one of:
   - `Enforce` (default) - the policy validation enforcements apply.
-  - `Warn` - Similar to DryRun. But failures and violations are also sent to
-    client as warnings with a clear indication of what would have happened if
-    the `mode` were instead set to `Enforce`. This is a good mode for
-    communicating to clients that requests will result in `deny` for a period of
-    time before enabling `Enforce`.
   - `DryRun` - for testing out a new binding during rollout, no failures or
     violations of any kind result in a deny, but are instead redirected to logs.
     This is a good mode for cluster administrators to use to check the potential
@@ -1272,6 +1259,15 @@ Rough plan:
   used as the audit annotation key.
 - Can add an `audit` option next to the `deny` and `warn` enforcement options.
 
+#### Client visibility
+
+In order to make `DryRun` more visibility to clients we will add a client
+visibility option to policy bindings.
+
+This is largely focused at making deployment/rollout more manageable.
+
+It _might_ be generalized to control visibility of enforced violations.
+
 #### Metrics
 
 Goals:
@@ -1603,22 +1599,22 @@ xref: https://kyverno.io/docs/writing-policies/autogen/
    the same settings as policy definition A otherwise (e.g. it uses the same
    param CR)
 1. Policy bindings X1..Xn are replicated as Y1..Yn but modified to use policy
-   definition B and `enablement: Canary`
+   definition B and `mode: DryRun`
 1. Cluster administrators observe violations (via metrics, audit logs or logged warnings)
 1. Cluster administrator determines new validation is safe
-1. Policy bindings X1..Xn are set to `enablement: Enabled`
-1. If anything goes wrong, revert enablement back to `Canary`
+1. Policy bindings X1..Xn are set to `mode: Enabled`
+1. If anything goes wrong, revert mode back to `DryRun`
 1. Policy definition A is updated to include the new validation
 1. Policy definition B and policy bindings Y1..Yn are deleted
 
 #### Use Case: Canary-ing a policy
 
 1. New policy definition is created
 1. Any needed param CRs are created
-1. policy bindings are created and set to `enablement: Canary`
+1. policy bindings are created and set to `mode: DryRun`
 1. Cluster administrators observe violations (via metrics, audit logs or logged warnings)
 1. Cluster administrator determines new policy is safe
-1. policy bindings are set to `enablement: Enabled`
+1. policy bindings are set to `mode: Enabled`
 
 ### Potential Applications
 

keps/sig-api-machinery/3488-cel-admission-control/kep.yaml

@@ -6,9 +6,9 @@ authors:
   - "@tallclair"
   - "@maxsmythe"
   - "@soorena776"
-owning-sig: sig-xyz
+owning-sig: sig-api-machinery
 participating-sigs:
-  - sig-api-machinery
+  - sig-auth
 status: implementable
 creation-date: 2022-09-02
 reviewers: