From ROR-ES to ROR-Pro

[parosio]

Hello,
after a long time using ROR ES plugin, we have finally received ROR Pro as holydays gift
Currently using ror 1.46 - 7.17.9, in a small multitenancy environment (2 kibana instances/indices)

I’d welcome suggestions on how to upgrade from the basic plugin to the PRO version.
In particular: how can I create the .readonly index from the current yaml configuration?

We only have the following constraint:
only one of the kibana instance will have the plugin installed (the second one is managed by a different team, with access to specific indices)

Regards,
Paolo

[sscarduzio (Simone Scarduzio)]

Hello @parosio!

Yes I remember you from the early days, how are you?

Congrats to Santa for the great gift choice!

First of all, I’d recommend to take this opportunity for a version upgrade. ROR is now at version 1.53.0, and a lot of fixes have been merged since 1.46.

This is how the upgrade is going to work:

• Upgrade ROR ES following the instructions (including the patching)
• Download ROR for Kibana (universal edition), and follow the instructions to upgrade it, here too: keep an eye in the patching.
• Login on the customer portal using your work email
• Create an activation key
• Install it in Kibana using the UI

About the creation of the .readonlyrest index: it’s automatic. The first time you go to the ROR security settings YAML editor in Kibana and press “Save”, it’s literally copying the readonlyrest.yml content, encrypting it and saving it to the index.

Ask us anything!

[parosio]

Hello Simone,
I’m “not too bad” , thank you, and yes, it took looong years to convince the purse keeper.

Some questions arise, actually:

1. we use two different kibana_index in current ACLs, and different flavors of kibana_access…
   those settings should all be rewritten under the kibana rule?

2. we operate behind an authentication service and a nginx reverse proxy, which forwards the userid of the authenticated user (it’s in elasticsearch.requestHeadersWhitelist kibana.yml setting). When I access the application now I’m blocked by the ROR authentication page, which is totally unwanted…
   

   
   
   How can it be avoided?

3. the kibana “home” url seems modified from https://<our_application>/kibana/app/home#/ to https://<our_application>/kibana/s/default/app/home#/ ( s/default/ added ). As a result, all the application pages containing an embedded dashboard (like <iframe id="frm" src="http://<application>/kibana/app/dashboards#/view/e1b079d0-631d-11e7-89f2-f7fdddd2dcee?embed=true& ... > ) show nothing anymore.
   Is it possible to revert it back?

4. How can I avoid ?

5. Finally, the license seems expiring in 72 days
   
   but the order confirmation letter tells a different date:
   

Points 2. and 3. are the most important / urgent.

Thank you,
Paolo

[sscarduzio (Simone Scarduzio)]

@parosio

we use two different kibana_index in current ACLs, and different flavors of kibana_access…
those settings should all be rewritten under the kibana rule?

The new syntax

    - name: "::RO::"
      auth_key: ro:dev
      kibana:
        access: ro
        index: ".kibana123"
        hide_apps: [ "Security", "Enterprise Search"]

as opposed to the old syntax

    - name: "::RO::"
      auth_key: ro:dev
      kibana_access: ro
      kibana_index: ".kibana_123"
      kibana_hide_apps: [ "Security", "Enterprise Search"]

Is not mandatory, we kept backwards compatibility. But it’s easy to change and it looks tidier IMO. Up to you.

@parosio

we operate behind an authentication service and a nginx reverse proxy, which forwards the userid of the authenticated user (it’s in elasticsearch.requestHeadersWhitelist kibana.yml setting). When I access the application now I’m blocked by the ROR authentication page, which is totally unwanted…

When you say “now I’m blocked” you mean you are already at work integrating ROR PRO on a newer version of Kibana? Or the very old installation you had years ago? Please let us know what Kibana and ROR plugin version are you integrating at the moment.

Nevertheless, in the newer ROR Kibana plugins for newer Kibana versions, we still support the proxy auth flow, but has to be enabled with readonlyrest_kbn.proxy_auth_passthrough: true in kibana.yml. It works so that the X-Forwarded-User header gets used as credential to download user metadata to begin the Kibana session, but also directly forwarded to Elasticsearch for any further request.
The requestHeadersWhitelist is not needed anymore.

1. the kibana “home” url seems modified from https://<our_application>/kibana/app/home#/ to https://<our_application>/kibana/s/default/app/home#/ ( s/default/ added ). As a result, all the application pages containing an embedded dashboard (like <iframe id="frm" src="http://<application>/kibana/app/dashboards#/view/e1b079d0-631d-11e7-89f2-f7fdddd2dcee?embed=true& ... > ) show nothing anymore.
   Is it possible to revert it back?

Not sure if and how it’s possible. @Dzuming do you know? Maybe if he disables spaces feature?

How can I avoid (spammy console logs)

We should fix this, you are right!

Finally, the license seems expiring in 72 days

The reseller suggested we create a “bridge” access token to cover the time between the order and the actual payment. This will give you (the integrator) a handle for applying pressure to the whole procurement food chain (which is a few hops long).
If you get in trouble because it’s expiring too soon, I can produce an emergency activation key for you. Don’t worry.
Heads up: 30 days before the expiration, it shows a banner about “please renew your license” or something, which looks weird for users. So come to me before the 30 days to the expiration.

[parosio]

Hi Simone,

• ror.yaml syntax: ok for back compatibility; we’ll change to the new one in the future
• ror auth page: I must have skipped the doc section that explain how to use the proxy auth; setting readonlyrest_kbn.proxy_auth_passthrough: true works as expected.
  (btw, I’m testing in a small environment, es & kib 7.17.9, ror still 1.46; I’ll update ror before going in prod)
• kibana “home” (default space): don’t bother about it, it only requires a minimal configuration change
• license: ok, I’ll forward the information upwards

I’ll be back with other questions in case of need.

Thank you
Paolo

[Dzuming (Dawid Poliszak)]

@sscarduzio

Not sure if and how it’s possible. @Dzuming do you know? Maybe if he disables spaces feature?

Yes, exactly. When xpack.spaces.enabled: false defined, URL won’t be overwritten. However since the Kibana 8.0.0 ``xpack.spaces.enabled` flag is removed and there is no way to disable spaces.

[parosio]

@parosio

license: ok, I’ll forward the information upwards

Hi Simone, sorry to bother you again…
On customer’s SAP everything seems ok, but we haven’t received the final activation key yet.
As you said, the supply chain has many rings; could you check on your side?
Let me know if you need additional information.

Besides, I just tried to suscribe at the customer portal using my work email address; possibly, the new license activation key has already been issued.

[sscarduzio (Simone Scarduzio)]

Hey @parosio did you manage to get access and affiliate your account? I was AFK for the weekend, hope all it’s good now and you can generate the activation keys?

[parosio]

Hello @sscarduzio,
yes, I’ve finally set up an affiliate account.
It seems that the expiration date is actually approaching (24 feb), and I already have a warning banner.
But, the fact is that the payment due date is 31 Jan, so…

Do we continue on customer portal, maybe?