kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

address feedback 

Signed-off-by: Rita Zhang <rita.z.zhang@gmail.com>
pull/45137/head
Rita Zhang 2024-04-01 17:22:03 -07:00
parent a27b1584a6
commit aba193faae
No known key found for this signature in database
GPG Key ID: 3ADE11B31515DF8C
1 changed files with 44 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
content/en/blog/_posts/2024-04-xx-structured-authz-beta.md → content/en/blog/_posts/2024-04-25-structured-authz-beta.md
View File

@ -1,8 +1,8 @@
---
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
@ -10,8 +10,6 @@ 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.