NOTE: You are looking at documentation for an older release. For the latest information, see the current release documentation.
Security
editSecurity
editKibana has generally been able to implement security transparently to core and plugin developers, and this largely remains the case. Kibana on two methods that the elasticsearch plugin's Cluster
provides: callWithRequest
and callWithInternalUser
.
callWithRequest
executes requests against Elasticsearch using the authentication credentials of the Kibana end-user. So, if you log into Kibana with the user of foo
when callWithRequest
is used, Kibana execute the request against Elasticsearch as the user foo
. Historically, callWithRequest
has been used extensively to perform actions that are initiated at the request of Kibana end-users.
callWithInternalUser
executes requests against Elasticsearch using the internal Kibana server user, and has historically been used for performing actions that aren’t initiated by Kibana end users; for example, creating the initial .kibana
index or performing health checks against Elasticsearch.
However, with the changes that role-based access control (RBAC) introduces, this is no longer cut and dry. Kibana now requires all access to the .kibana
index goes through the SavedObjectsClient
. This used to be a best practice, as the SavedObjectsClient
was responsible for translating the documents stored in Elasticsearch to and from Saved Objects, but RBAC is now taking advantage of this abstraction to implement access control and determine when to use callWithRequest
versus callWithInternalUser
.