From 675e76e9103f93feef2db324073aa787941cb719 Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Thu, 28 Mar 2024 14:32:29 +0000 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Rita Zhang --- content/en/docs/reference/access-authn-authz/authorization.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/docs/reference/access-authn-authz/authorization.md b/content/en/docs/reference/access-authn-authz/authorization.md index 457060f75cd60..b1156f5c70509 100644 --- a/content/en/docs/reference/access-authn-authz/authorization.md +++ b/content/en/docs/reference/access-authn-authz/authorization.md @@ -184,7 +184,7 @@ You specify the path to that authorization configuration using the via a local file allows you to define authorization chains with multiple webhooks. Authorization chain elements can have well-defined parameters that validate requests in a certain order; this enables fine grained -control - such as explicit Deny on failures. +control - such as timeout and failure policy for each webhook. Setting both `--authorization-config` path and configuring an authorization webhook using the `--authorization-mode` and `--authorization-webhook-*` @@ -314,7 +314,7 @@ escalation include Kubernetes [API extensions](/docs/concepts/extend-kubernetes/ and their associated {{< glossary_tooltip term_id="controller" text="controllers" >}}. {{< caution >}} -As a cluster administrators, take care when granting access to create or edit workloads. +As a cluster administrator, use caution when granting access to create or edit workloads. Some details of how these can be misused are documented in [escalation paths](/docs/reference/access-authn-authz/authorization/#escalation-paths) {{< /caution >}}