Add notes about which auth strategies are supported in MC (#751)

content/en/docs/Configuration/authentication/_index.md

@@ -5,9 +5,11 @@ description: "Choosing and configuring the appropriate authentication strategy."
 
 Kiali supports five authentication mechanisms.
 
-* The default authentication strategy for OpenShift clusters is `openshift`.
-* The default authentication strategy for all other Kubernetes clusters is `token`.
+- The default authentication strategy for OpenShift clusters is `openshift`.
+- The default authentication strategy for all other Kubernetes clusters is `token`.
 
 All mechanisms other than `anonymous` support [limiting per-user namespace access control]({{<relref "../rbac" >}}).
 
+For multi-cluster, only `anonymous` and `openid` are currently supported.
+
 Read the dedicated page of each authentication strategy to learn more.

content/en/docs/Configuration/authentication/header.md

@@ -7,23 +7,25 @@ weight: 20
 
 ## Introduction
 
-The `header` strategy assumes a reverse proxy is in front of Kiali, such as 
+The `header` strategy assumes a reverse proxy is in front of Kiali, such as
 OpenUnison or OAuth2 Proxy, injecting the user's identity into each request to
-Kiali as an `Authorization` header.  This token can be an OpenID Connect
+Kiali as an `Authorization` header. This token can be an OpenID Connect
 token or any other token the cluster recognizes.
 
 In addition to a user token, the `header` strategy supports impersonation
-headers.  If the impersonation headers are present in the request, then Kiali
+headers. If the impersonation headers are present in the request, then Kiali
 will act on behalf of the user specified by the impersonation (assuming the
 token supplied in the `Authorization` header is authorized to do so).
 
 The `header` strategy allows for [namespace access control]({{< relref "../rbac" >}}).
 
+The `header` strategy is only supported for single cluster.
+
 ## Set-up
 
-The `header` strategy will work with any Kubernetes cluster.  The token provided 
-must be supported by that cluster.  For instance, most "on-prem" clusters support
-OpenID Connect, but cloud hosted clusters do not.  For clusters that don't support 
+The `header` strategy will work with any Kubernetes cluster. The token provided
+must be supported by that cluster. For instance, most "on-prem" clusters support
+OpenID Connect, but cloud hosted clusters do not. For clusters that don't support
 a token, the [impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation)
 headers can be injected by the reverse proxy.
 
@@ -37,48 +39,47 @@ The `header` strategy doesn't have any additional configuration.
 
 ## HTTP Header
 
-The `header` strategy looks for a token in the `Authorization` HTTP header with the 
-`Bearer` prefix.  The HTTP header should look like:
+The `header` strategy looks for a token in the `Authorization` HTTP header with the
+`Bearer` prefix. The HTTP header should look like:
 
 ```
 Authorization: Bearer TOKEN
 ```
 
-Where `TOKEN` is the appropriate token for your cluster.  This `TOKEN` will be 
-submitted to the API server via a `TokenReview` to validate the token *ONLY*
-on the first access to Kiali.  On subsequent calls the `TOKEN` is passed through
+Where `TOKEN` is the appropriate token for your cluster. This `TOKEN` will be
+submitted to the API server via a `TokenReview` to validate the token _ONLY_
+on the first access to Kiali. On subsequent calls the `TOKEN` is passed through
 directly to the API server.
 
 ## Security Considerations
 
 ### Network Policies
 
 A policy should be put in place to make sure that the only "client" for Kiali is
-the authenticating reverse proxy.  This helps limit potential abuse and ensures 
+the authenticating reverse proxy. This helps limit potential abuse and ensures
 that the authenticating reverse proxy is the source of truth for who accessed
 Kiali.
 
 ### Short Lived Tokens
 
-The authenticating reverse proxy should inject a short lived token in the 
-`Authorization` header.  A shorter lived token is less likely to be abused if 
-leaked.  Kiali will take whatever token is passed into the reqeuest, so as tokens 
+The authenticating reverse proxy should inject a short lived token in the
+`Authorization` header. A shorter lived token is less likely to be abused if
+leaked. Kiali will take whatever token is passed into the reqeuest, so as tokens
 are regenerated Kiali will use the new token.
 
 ### Impersonation
 
 #### TokenRequest API
 
-The authenticating reverse proxy should use the TokenRequest API instead of static 
-`ServiceAccount` tokens when possible while using impersonation. The 
+The authenticating reverse proxy should use the TokenRequest API instead of static
+`ServiceAccount` tokens when possible while using impersonation. The
 `ServiceAccount` that can impersonate users and groups is privileged and having it
-be short lived cuts down on the possibility of a token being leaked while it's being 
+be short lived cuts down on the possibility of a token being leaked while it's being
 passed between different parts of the infrastructure.
 
 #### Drop Incoming Impersonation Headers
 
-The authenticating proxy *MUST* drop any headers it receives from a remote client 
-that match the impersonation headers.  Not only do you want to make sure that the
+The authenticating proxy _MUST_ drop any headers it receives from a remote client
+that match the impersonation headers. Not only do you want to make sure that the
 authenticating proxy can't be overriden on which user to authenticate, but also
-what groups they're a member of. 
-
+what groups they're a member of.

content/en/docs/Configuration/authentication/openshift.md

@@ -17,6 +17,8 @@ logged in if the user has enough privileges.
 
 The `openshift` strategy supports [namespace access control]({{< relref "../rbac" >}}).
 
+The `openshift` strategy is only supported for single cluster.
+
 ## Set-up
 
 Since `openshift` is the default strategy when deploying Kiali in OpenShift,

content/en/docs/Configuration/authentication/token.md

@@ -13,6 +13,8 @@ token of a Kubernetes ServiceAccount. This is similar to the
 
 The `token` strategy supports [namespace access control]({{< relref "../rbac" >}}).
 
+The `token` strategy is only supported for single cluster.
+
 ## Set-up
 
 Since `token` is the default strategy when deploying Kiali in Kubernetes, you