More SSO enabled Kibana instances at one server.

jony · November 26, 2020, 10:20am

Hi,
we have more Kibana instances (for more elasticsearch instaces) at one server, each one have own ip address and hostname, but the same port.
netstat -ltnp | grep 5601
tcp 0 0 10.0.10.10:5601 0.0.0.0:* LISTEN 39982/node
tcp 0 0 10.0.10.11:5601 0.0.0.0:* LISTEN 39370/node
tcp 0 0 10.0.10.12:5601 0.0.0.0:* LISTEN 60427/node

When we enable saml sso on the first Kibana instance a new service on 5602 port appears on our server.

netstat -ltnp | grep 5602
tcp6 0 0 :::* LISTEN 39982/node

And SSO is working well.

When we try to configure the second instance, the Kibana crash with the error:

ROR log level: info. Kibana logger chosen: info
Warning: connect.session() MemoryStore is not
designed for a production environment, as it will leak
memory, and will not scale past a single process.
/srv/app/sys/trace/elastic/kibana-6.7.2-linux-x86_64/plugins/readonlyrest_kbn/server/routes/lib/connectors/saml/samlExpressServer.js:249
const bind = typeof port === ‘string’ ? 'Pipe ’ + port : 'Port ’ + port;
^

ReferenceError: port is not defined
at Server.server.on.error (/srv/app/sys/trace/elastic/kibana-6.7.2-linux-x86_64/plugins/readonlyrest_kbn/server/routes/lib/connectors/saml/samlExpressServer.js:244:23)
at Server.emit (events.js:189:13)
at emitErrorNT (net.js:1304:8)
at process._tickCallback (internal/process/next_tick.js:63:19)
.[60G[.[0;31mFAILED.[0;39m]

When we stop the first Kibana SSO instance, the second starts OK.

Then when we try to start the first, kibana crash with the same error as you can see above.

It seems that problem is in service running at :::5602.

Is there a way how to config a specific IP address for this service?

ReadonlyREST Security version enterprise-1.24.0_es6.7.2
our config:

readonlyrest_kbn.auth:
signature_key: “some_key”
saml_serv1:
enabled: true
type: saml
issuer: ‘https://our_url.com/our-instance/’
buttonName: ‘SSO Login’
entryPoint: ‘https://our-idp.com/adfs/ls/’ # ← identity Provider’s URL, to request to sign on
kibanaExternalHost: ‘our_url.com/’ # ← public URL used by the Identity Provider to call back Kibana with the “assertion” message
protocol: https # ← is the Kibana server listening for “http” “https” connections? Default: http
usernameParameter: ‘nameID’
identifierFormat: ‘urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified’
groupsParameter: ‘http://schemas.xmlsoap.org/claims/Group’
logoutUrl: ‘https://our-idp.com/adfs/ls/?wa=wsignout1.0’
disableRequestedAuthnContext: true

I try to find how to configure the service here:

github.com

beshu-tech/readonlyrest-docs/blob/master/kibana.md#saml

---
description: User manual for ReadonlyREST Enterprise/PRO/Free
---

# For Kibana

🧙 **Are you using Kibana version 7.8.x or older? Go to the** [**old platform manual page**](details/kibana-7.8.x-and-older.md)**.**

### Kibana Plugin overview

ReadonlyREST plugin for Kibana is not open source, and it's offered as part of the [ReadonlyREST PRO](https://readonlyrest.com/pro.html) and [ReadonlyREST ENTERPRISE](https://readonlyrest.com/enterprise.html), and [ReadonlyREST Free](https://readonlyrest.com/free) packages. See product descriptions and a comparison chart in the official [ReadonlyREST website](https://readonlyrest.com)

ReadonlyREST plugins for Kibana **always require** ReadonlyREST opens source plugin to be installed in the Elasticsearch nodes your Kibana instance(s) will connect to.

It's not mandatory to install ReadonlyREST in all Elasticsearch nodes, but only in the ones in where you need the HTTP interface to be secured.

### After purchasing

If you didn't install it yet, download the latest [universal build](https://docs.readonlyrest.com/universal-builds) from our [download page](https://readonlyrest.com/download/) and install it manually.
Alternatively, see below if you want to install it directly via the command line without downloading it from the browser.

This file has been truncated. show original

github.com

beshu-tech/readonlyrest-docs/blob/master/elasticsearch.md#ror_kbn_auth

# For Elasticsearch

## Overview: The ReadonlyREST Suite

ReadonlyREST is a light weight Elasticsearch plugin that adds encryption, authentication, authorization and access control capabilities to Elasticsearch embedded REST API. The core of this plugin is an ACL engine that checks each incoming request through a sequence of **rules** a bit like a firewall. There are a dozen rules that can be grouped in sequences of blocks and form a powerful representation of a logic chain.

The Elasticsearch plugin known as `ReadonlyREST Free` is released under the GPLv3 license, or alternatively, a commercial license \(see [ReadonlyREST Embedded](https://readonlyrest.com/embedded)\) and lays the technological foundations for the companion Kibana plugin which is released in two versions: [ReadonlyREST PRO](https://readonlyrest.com/pro) and [ReadonlyREST Enterprise](https://readonlyrest.com/enterprise).

Unlike the Elasticsearch plugin, the Kibana plugins are commercial only. But rely on the Elasticsearch plugin in order to work.

For a description of the Kibana plugins, skip to the [dedicated documentation page](kibana/) instead.

### ReadonlyREST Free plugin for Elasticsearch

In this document we are going to describe how to operate the Elasticsearch plugin in all its features. Once installed, this plugin will greatly extend the Elasticsearch HTTP API \(port 9200\), adding numerous extra capabilities:

* **Encryption**: transform the Elasticsearch API from HTTP to HTTPS
* **Authentication**: require credentials
* **Authorization**: declare groups of users, permissions and partial access to indices.
* **Access control**: complex logic can be modeled using an ACL \(access control list\) written in YAML.

This file has been truncated. show original

But without success…

sscarduzio · November 26, 2020, 10:29am

So you are using “server.host” in your kibana.yml to bind a Kibana instance to a specific address?

jony · November 26, 2020, 11:24am

Yes
server.port: 5601
server.host: our-instance-name.our-url.com

sscarduzio · November 26, 2020, 4:43pm

OK that’s what I expected. You are right, we don’t really specify what host we should bind our internal SSO server. Will add a JIRA ticket for this, and check it out.

In the meantime, as a workaround (which actually would be a better way to operate), I suggest you try putting those Kibana instances into containers.

sscarduzio · April 1, 2021, 2:07pm

@jony this is fixed in ROR for 7.9.x and newer (rewritten version of ROR, aka “new platform”). Would you like to try?