diff --git a/content/en/docs/Configuration/authentication/_index.md b/content/en/docs/Configuration/authentication/_index.md index 12bdb33f..7a1fb9ba 100644 --- a/content/en/docs/Configuration/authentication/_index.md +++ b/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]({{}}). +For multi-cluster, only `anonymous` and `openid` are currently supported. + Read the dedicated page of each authentication strategy to learn more. diff --git a/content/en/docs/Configuration/authentication/header.md b/content/en/docs/Configuration/authentication/header.md index 11501c3b..d816d078 100644 --- a/content/en/docs/Configuration/authentication/header.md +++ b/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,16 +39,16 @@ 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 @@ -54,31 +56,30 @@ directly to the API server. ### 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. diff --git a/content/en/docs/Configuration/authentication/openshift.md b/content/en/docs/Configuration/authentication/openshift.md index 24cf3c69..32592220 100644 --- a/content/en/docs/Configuration/authentication/openshift.md +++ b/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, diff --git a/content/en/docs/Configuration/authentication/token.md b/content/en/docs/Configuration/authentication/token.md index d67df087..4783f7af 100644 --- a/content/en/docs/Configuration/authentication/token.md +++ b/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