address feedback

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

Author: ritazh

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

@@ -1,17 +1,15 @@
 ---
 layout: blog
-title: 'Multi-Webhook and Modular Authorization Made Easy'
-date: 2024-04-nn
-slug: multi-webhook-and-modular-authorization-made-easy
+title: 'Kubernetes 1.30: Multi-Webhook and Modular Authorization Made Much Easier'
+date: 2024-04-25
+slug: multi-webhook-and-modular-authorization-made-much-easier
 ---
 
 **Authors:** [Rita Zhang](https://github.com/ritazh) (Microsoft), [Jordan
 Liggitt](https://github.com/liggitt) (Google), [Nabarun
 Pal](https://github.com/palnabarun) (VMware), [Leigh
 Capili](https://github.com/stealthybox) (VMware)
 
-# Enhancing Kubernetes Authorization with Multiple Webhooks and Structured Configuration
-
 ## Introduction
 Kubernetes continues to evolve to meet the intricate requirements of system
 administrators and developers alike. A critical aspect of Kubernetes that
@@ -33,23 +31,22 @@ detailed behavior like timeout and failure policy for each webhook. This need
 arises from the desire to create layered security policies, where requests can
 be validated against multiple criteria or sets of rules in a specific order. The
 previous limitations also made it difficult to dynamically configure the
-authorizer chain, leaving no room to efficiently manage complex authorization
-scenarios.
+authorizer chain, leaving no room to manage complex authorization scenarios
+efficiently.
 
 The [Structured Authorization Configuration
 feature](/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file)
 addresses these limitations by introducing a configuration file format to
-configure Kubernetes API Server Authorization chain. This format allows
+configure the Kubernetes API Server Authorization chain. This format allows
 specifying multiple webhooks in the authorization chain (all other authorization
-types are specified no more than once). Each webhook authorizer comes with its
-well-defined parameters, including timeout settings, failure policies, and
-conditions for invocation with [CEL](/docs/reference/using-api/cel/) rules to
-pre-filter requests before they are dispatched to webhooks, helping you to
-prevent unnecessary invocations. The configuration also supports automatic
-reloading, ensuring changes can be applied dynamically without restarting the
-kube-apiserver. This feature not only addresses current limitations, but also
-opens up new possibilities for securing and managing Kubernetes clusters more
-effectively.
+types are specified no more than once). Each webhook authorizer has well-defined
+parameters, including timeout settings, failure policies, and conditions for
+invocation with [CEL](/docs/reference/using-api/cel/) rules to pre-filter
+requests before they are dispatched to webhooks, helping you prevent unnecessary
+invocations. The configuration also supports automatic reloading, ensuring
+changes can be applied dynamically without restarting the kube-apiserver. This
+feature addresses current limitations and opens up new possibilities for
+securing and managing Kubernetes clusters more effectively.
 
 ## Sample Configurations
 Here is a sample structured authorization configuration along with descriptions
@@ -153,24 +150,24 @@ authorizers:
         type: InClusterConfig
 ```
 
-The following configuration examples illustrate real world scenarios that need
+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
-startup has been a key demand. One of the blockers for having a controller
-reconciling those CRDs is to have a protection mechanism for them, which can be
-achieved through multiple authorization webhooks. This was not possible before
-as specifying multiple authorization webhooks in the Kubernetes API Server
-authorization chain was simply not possible. Now with the Structured
+Ensuring of Custom Resource Definitions (CRDs) availability at cluster startup
+has been a key demand. One of the blockers of having a controller reconcile
+those CRDs is having a protection mechanism for them, which can be achieved
+through multiple authorization webhooks. This was not possible before as
+specifying multiple authorization webhooks in the Kubernetes API Server
+authorization chain was simply not possible. Now, with the Structured
 Authorization Configuration feature, administrators can specify multiple
-webhooks offering a solution where RBAC falls short, especially in denying
+webhooks, offering a solution where RBAC falls short, especially when denying
 permissions to 'non-system' users for certain CRDs.
 
 Assuming the following for this scenario:
 - The "protected" CRDs are installed.
-- They can only be modified by users in the group `admin`
+- They can only be modified by users in the group `admin`.
 
 ```yaml
 apiVersion: apiserver.config.k8s.io/v1beta1
@@ -201,7 +198,7 @@ authorizers:
 
 ### Preventing unnecessarily nested webhooks
 A system administrator wants to apply specific validations to requests before
-handling them off to webhooks using frameworks like Open Policy Agent. In the
+handing them off to webhooks using frameworks like Open Policy Agent. In the
 past, this would require running nested webhooks within the one added to the
 authorization chain to achieve the desired result. The Structured Authorization
 Configuration feature simplifies this process, offering a structured API to
@@ -255,20 +252,21 @@ authorizers:
 ```
 
 ## What's next?
-For Kubernetes v1.31, we expect the feature to stay in beta while we get more
-feedback. Then once the feature is ready for GA, the feature flag will be
-removed and the configuration file version will be promoted to v1.
+From Kubernetes 1.30, the feature is in beta and enabled by default. For
+Kubernetes v1.31, we expect the feature to stay in beta while we get more
+feedback from users. Once it is ready for GA, the feature flag will be removed,
+and the configuration file version will be promoted to v1.
 
-You can learn more about this feature on the [structured authorization
+Learn more about this feature on the [structured authorization
 configuration](/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file)
-Kubernetes doc website. You can also follow along on the
-[KEP-3221](https://kep.k8s.io/3221) to track progress across the coming
-Kubernetes releases.
+Kubernetes doc website. You can also follow along with
+[KEP-3221](https://kep.k8s.io/3221) to track progress in coming Kubernetes
+releases.
 
 ## Call to action
-In this post, we have covered the benefits the Structured Authorization
-Configuration feature brings in Kubernetes v1.30 and few sample configurations
-for real world scenarios. To use this feature, you must specify the path to the
+In this post, we have covered the benefits of the Structured Authorization
+Configuration feature in Kubernetes v1.30 and a few sample configurations for
+real-world scenarios. To use this feature, you must specify the path to the
 authorization configuration using the `--authorization-config` command line
 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,
@@ -307,22 +305,22 @@ nodes:
 
 We would love to hear your feedback on this feature. In particular, we would
 like feedback from Kubernetes cluster administrators and authorization webhook
-implementors as they go through the process of building their integrations with
-this new API. Please reach out to us on the
+implementors as they build their integrations with this new API. Please reach
+out to us on the
 [#sig-auth-authorizers-dev](https://kubernetes.slack.com/archives/C05EZFX1Z2L)
 channel on Kubernetes Slack.
 
 ## How to get involved
-If you are interested in getting involved in the development of this feature,
-share feedback, or participate in any other ongoing SIG Auth projects, please
+If you are interested in helping develop this feature,
+sharing feedback, or participating in any other ongoing SIG Auth projects, please
 reach out on the [#sig-auth](https://kubernetes.slack.com/archives/C0EN96KUY)
 channel on Kubernetes Slack.
 
 You are also welcome to join the bi-weekly [SIG Auth
 meetings](https://github.com/kubernetes/community/blob/master/sig-auth/README.md#meetings)
-held every-other Wednesday.
+held every other Wednesday.
 
-## Acknowledgements
-This feature has been an effort driven by contributors from several different
-companies. We would like to extend a huge thank you to everyone that contributed
-their time and effort to help make this possible.
+## Acknowledgments
+This feature was driven by contributors from several different
+companies. We would like to extend a huge thank you to everyone who contributed
+their time and effort to make this possible.