3221: update KEP according to 1.29 requirements

Signed-off-by: Nabarun Pal <pal.nabarun95@gmail.com>

keps/sig-auth/3221-structured-authorization-configuration/README.md

@@ -27,7 +27,6 @@
     - [Future Alpha versions](#future-alpha-versions)
     - [Beta](#beta)
     - [GA](#ga)
-    - [GA + 3 cycles](#ga--3-cycles)
   - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)
   - [Version Skew Strategy](#version-skew-strategy)
 - [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)
@@ -175,8 +174,8 @@ apiVersion: apiserver.config.k8s.io/v1alpha1
 kind: AuthorizationConfiguration
 authorizers:
   - type: Webhook
-    name: system-crd-protector
     webhook:
+      name: system-crd-protector
       unauthorizedTTL: 30s
       timeout: 3s
       subjectAccessReviewVersion: v1
@@ -217,6 +216,7 @@ authorizers:
   - name: system-webhook
     type: Webhook
     webhook:
+      name: system-crd-protector
       unauthorizedTTL: 30s
       timeout: 3s
       subjectAccessReviewVersion: v1
@@ -236,6 +236,7 @@ authorizers:
   - name: opa
     type: Webhook
     webhook:
+      name: opa
       unauthorizedTTL: 30s
       timeout: 3s
       subjectAccessReviewVersion: v1
@@ -359,6 +360,11 @@ authorizers:
       # Required, with no default
       # Valid values: v1beta1, v1
       subjectAccessReviewVersion: v1
+      # MatchConditionSubjectAccessReviewVersion specifies the SubjectAccessReview
+      # version the CEL expressions are evaluated against
+      # Valid values: v1
+      # Required, no default value
+      matchConditionsSubjectAccessReviewVersion: v1
       # Controls the authorization decision when a webhook request fails to
       # complete or returns a malformed response or errors evaluating
       # matchConditions.
@@ -435,9 +441,11 @@ the version supported by a webhook has to be mentioned using a required field
 
 The user can define a CEL expression to determine whether a request needs to dispatched
 to the authz webhook for which the expression has been defined. The user would have access
-to a `request` variable containing a `SubjectAccessReview` object in the `v1` version. If
-the version specified by `subjectAccessReviewVersion` in the request variable is `v1beta1`,
-the contents would be converted to the `v1` version before evaluating the CEL expression.
+to a `request` variable containing a `SubjectAccessReview` object in the version specified
+by the `matchConditionsSubjectAccessReviewVersion` field. If the version specified by
+`subjectAccessReviewVersion` in the request variable is `v1beta1`, the contents would be
+converted to the version specified in `matchConditionsSubjectAccessReviewVersion` before
+evaluating the CEL expression.
 
 When no matchConditions are satisfied for a request, the webhook would be skipped. In such
 situations, the decision is logged in the audit log with the `authorization.k8s.io/webhook-skipped`
@@ -561,12 +569,6 @@ the scenarios.
 #### GA
 
 - Feature flag removed
-- Existing command line flags will be marked as deprecated and config file will take
-precedence over the old flags
-
-#### GA + 3 cycles
-
-- Remove the existing command line flags
 
 ### Upgrade / Downgrade Strategy
 
@@ -589,7 +591,7 @@ Not applicable.
 ###### How can this feature be enabled / disabled in a live cluster?
 
 - [x] Feature gate
-  - Feature gate name: `StructuredAuthorizationConfig`
+  - Feature gate name: `StructuredAuthorizationConfiguration`
   - Components depending on the feature gate:
         - kube-apiserver
 
@@ -612,11 +614,10 @@ We will have extensive unit tests during feature implementation. There would be
 for the Authorizer chain in both the old and new configuration scenarios.
 
 We will add integration tests to validate the enablement/disablement flow.
-  - When the feature is disabled, only the existing command line flag `--authorization-webhook-*`
-based mode is allowed.
-  - When the feature is enable, setting both `--authorization-config` and
-configuring an authorization webhook using the `--authorization-webhook-*`
+  - When `--authorization-config` flags is defined, the feature flag must be turned on (when feature is in Alpha).
+  - Setting `--authorization-config` along `--authorization-modes` and `--authorization-webhook-*`
 command line flags should return an error.
+  - Configuring the authorizer using legacy flags should always be allowed
 
 ### Rollout, Upgrade and Rollback Planning
 
@@ -643,9 +644,7 @@ TBD.
 
 ###### Is the rollout accompanied by any deprecations and/or removals of features, APIs, fields of API types, flags, etc.?
 
-Existing command line flags will be marked as deprecated and config file will take
-precedence over the old flags once this feature graduates to GA. Then for GA + 3 releases,
-the existing command line flags will be removed.
+No.
 
 ### Monitoring Requirements
 
@@ -814,9 +813,10 @@ For each of them, fill in the following information by copying the below templat
 
 - [x] 2022-06-10 - Provisional KEP introduced
 - [x] 2023-05-08 - Provisional KEP re-introduced
-- [ ] KEP Accepted as implementable
-- [ ] Implementation started
-- [ ] First release (1.YY) when feature available
+- [x] 2023-06-15 - KEP Accepted as implementable
+- [x] 2023-07-05 - Implementation started
+- [x] 2023-09-27 - Update KEP according to actual state
+- [ ] 2023-12-DD First release (1.29) when feature available
 
 ## Drawbacks