Remove K8s Auth Requirement From Docs (#1058)

We no longer plan to require audiences in the kubernetes auth plugin. It
was later discovered that doing so could break some valid configurations
of our customers (more details
[here](hashicorp/vault-plugin-auth-kubernetes#300 (comment))).

Instead, we plan to simply recommend that customers specify an`audience`
if it does not break their workflow. We log a warning in Vault when an
audience is not configured so that customers will be aware.

Author: jaireddjawed

content/vault/v1.20.x/content/api-docs/auth/kubernetes.mdx

@@ -146,7 +146,7 @@ entities attempting to login.
   [LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#labelselector-v1-meta). Currently, label selectors with `matchExpressions` are not supported.
   To use label selectors, **Vault must have permission to read namespaces** on the Kubernetes
   cluster. If set with `bound_service_account_namespaces`, the conditions are `OR`ed.
-- `audience` `(string: "")` - Audience claim to verify in the JWT. Will be required in Vault 1.21+.
+- `audience` `(string: "")` - Audience claim to verify in the JWT.
 - `alias_name_source` `(string: "serviceaccount_uid")` - Configures how identity aliases are generated.
   Valid choices are: `serviceaccount_uid` and `serviceaccount_name`.
 

content/vault/v1.20.x/content/docs/auth/kubernetes.mdx

@@ -111,9 +111,6 @@ management tool.
       ttl=1h
   ```
 
-  !> **Note:** `audience` will be a required field in Vault 1.21+. This field is used
-  to verify the JWT token's audience claim.
-
   This role authorizes the "myapp" service account in the default
   namespace and it gives it the default policy.
 

content/vault/v1.20.x/content/docs/updates/important-changes.mdx

@@ -206,19 +206,30 @@ audience.
 
 #### Recommendation
 
-We recommend updating your policies before Vault makes the audience value
-required for all Kubernetes authentication roles so Vault can explicitly
-validate that the audience claim in JWT tokens (`aud`) is intended for Vault and
-not another service. For example:
+There are cases where configuring audience details can interfere with your
+workflow. For example, tokens created using `kubernetes.io/service-account-token`
+do not include an aud claim. But we recommend configuring an audience value for
+Kubernetes authentication roles whenever possible. Setting explicit audience
+details is best practice because it reduces the risk of token misuse by other
+services. Vault can use the configured values to validate that the `aud`
+(audience) claim in JWT tokens is intended for Vault.
+
+For example:
 
 ```shell-session
 $ vault write auth/kubernetes/role/demo      \
     bound_service_account_names=myapp        \
     bound_service_account_namespaces=default \
     policies=default                         \
+    audience="my_audience"                   \
     ttl=1h
 ```
 
+You would then authenticate with the command below.
+
+```shell-session
+$ vault write auth/kubernetes/login role=demo audience="my_audience" jwt=...
+```
 
 ---