openid authentication strategy lets you integrate Kiali to an external
identity provider that implements OpenID
Connect, and allows users to login to Kiali using their existing accounts of a
openid strategy takes advantage of the cluster’s RBAC. See the Role-based access control documentation for more details.
Currently, Kiali supports the authorization code flow (preferred) and the implicit flow of the OpenId Connect spec.
You need either:
A Kubernetes cluster configured with OpenID connect integration, which results in the API server accepting tokens issued by your identity provider; or
A replacement or reverse proxy for the Kubernetes cluster API capable of handling the OIDC authentication.
The first option is preferred if you can manipulate your cluster API server startup flags, which will result in your cluster to also be integrated with the external OpenID provider.
The second option is provided for cases where you are using a managed
Kubernetes and your cloud provider does not support configuring OpenID
integration. Kiali assumes an implementation of a Kubernetes API server. For
example, a community user has reported to successfully configure Kiali’s OpenID
strategy by using
kube-oidc-proxy which is a
reverse proxy that handles the OpenID authentication and forwards the
authenticated requests to the Kubernetes API.
If you want to enable usage of the OpenId’s authorization code flow, make sure that the Kiali’s signing key is 16, 24 or 32 bytes long. If you install Kiali via the operator and don’t set a custom signing key, the operator should create a 16 bytes long signing key. If you setup a signing key of a different size, Kiali will only be capable of using the implicit flow.
We recommend using the authorization code flow.
Register Kiali as a client application in your OpenId Server. Use the root path of your Kiali instance as the callback URL. If the OpenId Server provides you a client secret, or if you manually set a client secret, issue the following command to create a Kubernetes secret holding the OpenId client secret:
kubectl create secret generic kiali --from-literal="oidc-secret=$CLIENT_SECRET" -n $NAMESPACE
$NAMESPACE is the namespace where you installed Kiali and
$CLIENT_SECRET is the secret you configured or provided by your OpenId
This secret is not needed if you don’t want Kiali to use the authorization code flow (i.e. if your signing key is neither 16, 24 or 32 bytes long).
Then, to enable the OpenID Connect strategy, the minimal configuration you need to set in the Kiali CR is like the following:
spec: auth: strategy: openid openid: client_id: "kiali-client" issuer_uri: "https://openid.issuer.com"
This assumes that your Kubernetes cluster is configured with OpenID Connect
integration. In this case, the
issuer_uri attributes must
to start the cluster API server. If these values don’t match, users will fail
to login to Kiali.
If you are using a replacement or a reverse proxy for the Kubernetes API server, the minimal configuration is like the following:
spec: auth: strategy: openid openid: api_proxy: "https://proxy.domain.com:port" api_proxy_ca_data: "..." client_id: "kiali-client" issuer_uri: "https://openid.issuer.com"
The value of
issuer_uri must match the values of the
configuration of your reverse proxy or cluster API replacement. The
attribute is the URI of the reverse proxy or cluster API replacement (only
HTTPS is allowed). The
api_proxy_ca_data is the public certificate authority
file encoded in a base64 string, to trust the secure connection.
The Kiali front-end will, by default, retrieve the string of the
sub claim of
the OpenID token and display it as the user name. You can customize which field
to display as the user name by setting the
username_claim attribute of the
Kiali CR. For example:
spec: auth: openid: username_claim: "email"
Usually, you will want the
username_claim attribute to match the
--oidc-username-claim flag used to start the Kubernetes API server, or the
equivalent option if you are using a replacement or reverse proxy of the API
By default, Kiali will request access to the
scopes attribute in the Kiali CR. For example:
spec: auth: openid: scopes: - "openid" - "email" - "groups"
openid scope is forced. If you don’t add it to the list of scopes to
request, Kiali will still request it from the identity provider.
When the user is redirected to the external authentication system, by default
Kiali will wait at most 5 minutes for the user to authenticate. After that time
has elapsed, Kiali will reject authentication. You can adjust this timeout by
authentication_timeout with the number of seconds that Kiali
should wait at most. For example:
spec: auth: openid: authentication_timeout: 60 # Wait only one minute.
If your OpenID provider is using a self-signed certificate, you can disable
certificate validation by setting the
the Kiali CR:
spec: auth: openid: insecure_skip_verify_tls: true
You should use self-signed certificates only for testing purposes.