add config with comments for fields

Signed-off-by: Rita Zhang <[email protected]>

Author: ritazh

content/en/blog/_posts/2024-04-xx-structured-authz-beta.md

@@ -51,9 +51,110 @@ opens up new possibilities for securing and managing Kubernetes clusters more
 effectively.
 
 ## Sample Configurations
-These configuration examples illustrate real world scenarios that need the
-ability to specify multiple webhooks with distinct settings, precedence order,
-and failure modes.
+Here is a sample structured authorization configuration along with descriptions
+for all fields, their defaults, and possible values.
+
+```yaml
+apiVersion: apiserver.config.k8s.io/v1beta1
+kind: AuthorizationConfiguration
+authorizers:
+  - type: Webhook
+    # Name used to describe the authorizer
+    # This is explicitly used in monitoring machinery for metrics
+    # Note:
+    #   - Validation for this field is similar to how K8s labels are validated today.
+    # Required, with no default
+    name: webhook
+    webhook:
+      # The duration to cache 'authorized' responses from the webhook
+      # authorizer.
+      # Same as setting `--authorization-webhook-cache-authorized-ttl` flag
+      # Default: 5m0s
+      authorizedTTL: 30s
+      # The duration to cache 'unauthorized' responses from the webhook
+      # authorizer.
+      # Same as setting `--authorization-webhook-cache-unauthorized-ttl` flag
+      # Default: 30s
+      unauthorizedTTL: 30s
+      # Timeout for the webhook request
+      # Maximum allowed is 30s.
+      # Required, with no default.
+      timeout: 3s
+      # The API version of the authorization.k8s.io SubjectAccessReview to
+      # send to and expect from the webhook.
+      # Same as setting `--authorization-webhook-version` flag
+      # 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
+      matchConditionSubjectAccessReviewVersion: v1
+      # Controls the authorization decision when a webhook request fails to
+      # complete or returns a malformed response or errors evaluating
+      # matchConditions.
+      # Valid values:
+      #   - NoOpinion: continue to subsequent authorizers to see if one of
+      #     them allows the request
+      #   - Deny: reject the request without consulting subsequent authorizers
+      # Required, with no default.
+      failurePolicy: Deny
+      connectionInfo:
+        # Controls how the webhook should communicate with the server.
+        # Valid values:
+        # - KubeConfig: use the file specified in kubeConfigFile to locate the
+        #   server.
+        # - InClusterConfig: use the in-cluster configuration to call the
+        #   SubjectAccessReview API hosted by kube-apiserver. This mode is not
+        #   allowed for kube-apiserver.
+        type: KubeConfig
+        # Path to KubeConfigFile for connection info
+        # Required, if connectionInfo.Type is KubeConfig
+        kubeConfigFile: /kube-system-authz-webhook.yaml
+        # matchConditions is a list of conditions that must be met for a request to be sent to this
+        # webhook. An empty list of matchConditions matches all requests.
+        # There are a maximum of 64 match conditions allowed.
+        #
+        # The exact matching logic is (in order):
+        #   1. If at least one matchCondition evaluates to FALSE, then the webhook is skipped.
+        #   2. If ALL matchConditions evaluate to TRUE, then the webhook is called.
+        #   3. If at least one matchCondition evaluates to an error (but none are FALSE):
+        #      - If failurePolicy=Deny, then the webhook rejects the request
+        #      - If failurePolicy=NoOpinion, then the error is ignored and the webhook is skipped
+      matchConditions:
+      # expression represents the expression which will be evaluated by CEL. Must evaluate to bool.
+      # CEL expressions have access to the contents of the SubjectAccessReview in v1 version.
+      # If version specified by subjectAccessReviewVersion in the request variable is v1beta1,
+      # the contents would be converted to the v1 version before evaluating the CEL expression.
+      #
+      # Documentation on CEL: https://kubernetes.io/docs/reference/using-api/cel/
+      #
+      # only send resource requests to the webhook
+      - expression: has(request.resourceAttributes)
+      # only intercept requests to kube-system
+      - expression: request.resourceAttributes.namespace == 'kube-system'
+      # don't intercept requests from kube-system service accounts
+      - expression: !('system:serviceaccounts:kube-system' in request.user.groups)
+  - type: Node
+    name: node
+  - type: RBAC
+    name: rbac
+  - type: Webhook
+    name: in-cluster-authorizer
+    webhook:
+      authorizedTTL: 5m
+      unauthorizedTTL: 30s
+      timeout: 3s
+      subjectAccessReviewVersion: v1
+      failurePolicy: NoOpinion
+      connectionInfo:
+        type: InClusterConfig
+```
+
+The following configuration examples illustrate real world scenarios that need
+the ability to specify multiple webhooks with distinct settings, precedence
+order, and failure modes.
 
 ### Protecting Installed CRDs
 Ensuring the availability of Custom Resource Definitions (CRDs) at cluster
@@ -171,16 +272,15 @@ argument. From Kubernetes 1.30, the feature is in beta and enabled by default.
 If you want to keep using command line flags instead of a configuration file,
 those will continue to work as-is. 
 
-The following kind Cluster configuration sets that command argument on the 
+The following kind Cluster configuration sets that command argument on the
 APIserver to load an AuthorizationConfiguration from a file
-(`authorization_config.yaml`) in the files folder.
-Any needed kubeconfig and certificate files can also be put in the files
-directory.
+(`authorization_config.yaml`) in the files folder. Any needed kubeconfig and
+certificate files can also be put in the files directory.
 ```yaml
 kind: Cluster
 apiVersion: kind.x-k8s.io/v1alpha4
 featureGates:
-  StructuredAuthorizationConfiguration: true  # enabled by default in v1.30
+  StructuredAuthorizationConfiguration: true  # only required for v1.29; enabled by default in v1.30
 kubeadmConfigPatches:
   - |
     kind: ClusterConfiguration