Skip to content

Commit 21ac70e

Browse files
committed
Wrap markdown text
Signed-off-by: Nabarun Pal <[email protected]>
1 parent 03e2976 commit 21ac70e

File tree

1 file changed

+26
-5
lines changed

1 file changed

+26
-5
lines changed

content/en/docs/reference/access-authn-authz/authorization.md

Lines changed: 26 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -213,14 +213,35 @@ so an earlier module has higher priority to allow or deny a request.
213213

214214
{{< feature-state state="alpha" for_k8s_version="v1.29" >}}
215215

216-
Kubernetes API Server authorizer chain can be configured using a config file by passing it through the `--authorization-config` flag. This feature enables creation of authorization chains with multiple webhooks with well-defined parameters that validate requests in a certain order and enables fine grained control like explicit Deny on failures. An example configuration with all possible values is provided below. In order to use the feature, the `StructuredAuthorizationConfiguration` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) has to be enabled.
216+
The Kubernetes API server's authorizer chain can be configured using a
217+
configuration file.
217218

218-
Note: When the feature is enabled, setting both `--authorization-config` and configuring an authorization webhook using the `--authorization-mode` and `--authorization-webhook-*` command line flags is not allowed. If done, there will be an error and API Server would exit right away.
219+
You specify the path to that authorization configuration using the
220+
`--authorization-config` command line argument. This feature enables
221+
creation of authorization chains with multiple webhooks with well-defined
222+
parameters that validate requests in a certain order and enables fine grained
223+
control - such as explicit Deny on failures. An example configuration with
224+
all possible values is provided below.
219225

220-
{{< caution >}}
221-
While the feature is in Alpha/Beta, there is no change if you want to keep on using command line flags. When the feature goes Beta, the feature flag would be turned on by default. The feature flag would be removed when feature goes GA.
226+
In order to customise the authorizer chain, you need to enable the
227+
`StructuredAuthorizationConfiguration` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
228+
229+
Note: When the feature is enabled, setting both `--authorization-config` and
230+
configuring an authorization webhook using the `--authorization-mode` and
231+
`--authorization-webhook-*` command line flags is not allowed. If done, there
232+
will be an error and API Server would exit right away.
222233

223-
When configuring the authorizer chain using a config file, make sure all the apiserver nodes have the file. Also, take a note of the apiserver configuration when upgrading/downgrading the clusters. For example, if upgrading to v1.29+ clusters and using the config file, you would need to make sure the config file exists before upgrading the cluster. When downgrading to v1.28, you would need to add the flags back to their bootstrap mechanism.
234+
{{< caution >}}
235+
While the feature is in Alpha/Beta, there is no change if you want to keep on
236+
using command line flags. When the feature goes Beta, the feature flag would
237+
be turned on by default. The feature flag would be removed when feature goes GA.
238+
239+
When configuring the authorizer chain using a config file, make sure all the
240+
apiserver nodes have the file. Also, take a note of the apiserver configuration
241+
when upgrading/downgrading the clusters. For example, if upgrading to v1.29+
242+
clusters and using the config file, you would need to make sure the config file
243+
exists before upgrading the cluster. When downgrading to v1.28, you would need
244+
to add the flags back to their bootstrap mechanism.
224245
{{< /caution >}}
225246

226247
```yaml

0 commit comments

Comments
 (0)