Version: SG FLX
Enterprise

Kibana Kerberos Authentication

Prerequisites

To user Kerberos-based authentication with Kibana, you first need to configure Kerberos authentication for the Elasticsearch backend.

Depending on the browser you are using, make sure you have configured the Kibana domain correctly for Kerberos authentication. Please refer to the documentation of your browser for further instructions.

Kibana configuration

The remaining configuration for Kibana is rather simple; configure it as authentication type in kibana.yml like:

searchguard.auth.type: "kerberos"

You can use all Search Guard features like multi tenancy and the configuration GUI with Kerberos.

Due to bugs and limitations in Kibana and X-Pack, not all X-Pack features will work however, please see below.

Accessing external monitoring clusters via Kibana

If you want to use both Kerberos authentication for Kibana and want to access an external monitoring cluster with Kibana (using the settings `monitoring.ui.elasticsearch.*´), some further special configuration is needed. This is necessary because the monitoring cluster will need to use sessions managed by the main cluster in order to authenticate Kibana users.

Note: Using sessions to access external monitoring clusters via Kibana is an Enterprise feature. A license is needed to use this in production.

The first part is to configure an explicit session signing hash key for the main cluster. You need to edit sg_sessions.yml and add the following lines. If you do not yet have the file sg_sessions.yml, you must create it.

jwt_signing_key_hs512: "base64url encoded 512 bit value"
jwt_audience: "session_prod1" 

The value for jwt_signing_key_hs512 can be for example generated with the following command:

$ openssl rand 64 | basenc --base64url 

The setting jwt_audience identifies the cluster which created the session JWT. Thus, the monitoring cluster can tell where the JWT originally came from.

The configuration can be updated using

$ ./sgctl.sh update-config path/to/sg_sessions.yml 

The second part is the configuration on the monitoring cluster. An additional authentication domain of type jwt/external_session needs to be added to sg_authc.yml. That might look like this:

auth_domains:
- ...
- type: jwt/external_session
  jwt.signing.jwks.keys:
  - kty: oct
    kid: kid_a
    k: "the same key as used in sg_sessions.yml on the main cluster "
    alg: HS512
  jwt.required_audience: "session_prod1"
  external_session.hosts:
  - "https://node1.prod_cluster:9200"
  external_session.tls.trusted_cas:
  - "public certificates 1" 

The options jwt.signing.jwks.keys and jwt.required_audience must be adapted to the corresponding settings in sg_sessions.yml on the main cluster. If several clusters are using the same monitoring cluster, you can create several entries, one for each cluster.

The option external_session.hosts requires the URL of at least one node of the main cluster. You can also specify more than one node for load-balancing.

The option external_session.tls.trusted_cas can be used if TLS connections to the main cluster need to use a special PKI. You can directly specify the CA certificate as PEM file here.

Known Issues/Limitations

X-Pack Machine Learning

Due to the way HTTP requests are handled by the machine learning module internally, it is currently not possible to use X-Pack Machine Learning with Kerberos.

Kibana URL shortener

It’s currently not possible to use the Kibana URL shortener together with Kibana/SPNEGO due to technical limitations of the Kibana architecture.

Kibana Index Management UI

It’s currently not possible to use the Kibana Index Management UI together with Kibana/SPNEGO due to technical limitations of the Kibana architecture.

Disabling the replay cache

Kerberos/SPNEGO has a security mechanism called “Replay Cache”. The replay cache makes sure that an Kerberos/SPENGO token can be used only once in a certain timeframe. This conflicts with the Kibana request handling, where one browser request to Kibana can result in multiple requests to Elasticsearch.

These sub-requests will all carry the same Kerberos token and are thus interpreted as replay attack. You will see error messages like:

[com.floragunn.dlic.auth.http.kerberos.HTTPSpnegoAuthenticator] Service login not successful due to java.security.PrivilegedActionException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Request is a replay (34)) 

At the moment, the only way to make Kerberos work with Kibana is to disable the replay cache. This is of course not optimal, but so far the only known way.

With Oracle JDK, you can set

-Dsun.security.krb5.rcache=none

in jvm.options of Elasticsearch.



Not what you were looking for? Try the search.