Kibana still trying to use some unauthenticated access to ES


Kibana looks to have the bad habit of making some requests to the ES without account info even if we use elasticsearch.username: and elasticsearch.password:

On 7.8.1 I already needed to allow unauthenticated access to make it work:
actions: [“cluster:monitor/xpack/info”, “cluster:monitor/main”, “cluster:monitor/xpack/license/get”, “cluster:admin/xpack/monitoring/bulk”]

With 7.11.12 I needed to also allow unauthenticated access for the following action to have kibana started and working fine:
actions: [“indices:data/read/search”, “indices:data/read/get”]
indices: [".kibana"]

The 8.0 Upgrade Assistant still fail with a Error: Internal Server Error
at HapiResponseAdapter.toError (/home/kibana/src/core/server/http/router/response_adapter.js:121:19)
at HapiResponseAdapter.toHapiResponse (/home/kibana/src/core/server/http/router/response_adapter.js:75:19)
at HapiResponseAdapter.handle (/home/kibana/src/core/server/http/router/response_adapter.js:70:17)
at Router.handle (/home/kibana/src/core/server/http/router/router.js:164:34)
at runMicrotasks ()

I tried to cover the reject I had in the audits (unauthenticated) allowing unauthenticated action:
“indices:admin/mappings/get” (for apm-* indexes)

The 8.0 upgrade page still end with a system error :frowning:

I don’t know if it is a normal behavior. I may have misconfigured something in kibana.

Can we see your settings? And, just to get this out of the way: have you patched Kibana?


Here is my kibana config: host1 {ELK_ROOT}/kibana-data xpack.graph.enabled: false false xpack.watcher.enabled: false elasticsearch.hosts: ["https://host1:9200", "https://host2:9200"] elasticsearch.username: "kibana" elasticsearch.password: "xxxx" elasticsearch.ssl.verificationMode: none server.ssl.keystore.path: "{ES_PATH_CONF}/host.p12"
server.ssl.keystore.password: “xxxx”
server.ssl.enabled: true
elasticsearch.ssl.certificateAuthorities: [ "{ES_PATH_CONF}/cacert.pem" ] logging.dest: {ELK_ROOT}/log/kibana/kibana.log
logging.json: false
xpack.encryptedSavedObjects.encryptionKey: “xxxx”
xpack.reporting.encryptionKey: “xxxx” “xxxx”

I’ve checked a second time and the Kibana instance I was using for the test was well patched. I’m using 1.29.0_es7.11.2.

On ES plugin I’m having the following block to deal with kibana needs:

- name: "::KIBANA-SRV::"
 type: allow
 auth_key: kibana:xxxx
 verbosity: error

It should have worked if kibana was not trying to reach ES sometime without the expected login:

FORBIDDEN by default req={ ID:1916462101-2035573290#58436, TYP:GetMappingsRequest, CGR:N/A, USR:[no info about user], BRS:false, KDX:null, ACT:indices:admin/mappings/get, OA:IP/32, XFF:null, DA:IP/32, IDX:apm-, MET:GET, PTH:/apm-/_mapping

FORBIDDEN by default req={ ID:805340606-939176580#139223, TYP:GetRequest, CGR:N/A, USR:[no info about user], BRS:true, KDX:null, ACT:indices:data/read/get, OA:IP/32, XFF:null, DA:IP/32, IDX:.kibana, MET:GET, PTH:/.kibana/_doc/space:default, CNT:<N/A>, HDR:Accept-Charset=utf-8, Host=host1:9200, connection=close, content-length=0, user-agent=elasticsearch-js/7.11.0-rc.1 (linux 3.10.0-1160.11.1.el7.x86_64-x64; Node.js v14.16.0), x-elastic-client-meta=es=7.11.0-rc.1,js=14.16.0,t=7.11.0-rc.1,hc=14.16.0, x-elastic-product-origin=kibana, x-opaque-id=79c08611-3688-49b5-812b-672ae8ece4e4

Having a look again to the kibana interface I was surprised by the Fleet page asking be to be super user.

It looks like some recommended parameters have disappeared in my kibana config at some point :frowning: :

xpack.monitoring.enabled: true false
xpack.telemetry.enabled: false

Adding these helped (security mainly) to have a normal kibana behavior. I will test later if the additional actions I have added are still necessary or not.

I don’t have anymore Error: Internal Server Error on the upgrade page.

Now the fleet page tell me that I need to activate xpack security to be able to use it. Are you planning to support the fleet page in the free ROR kibana plugin ?

Yes we will try to make fleet and other parts that require xpack security to work. We are still in explorative phase. Will update with more.