Introduce kibana_system user, deprecate kibana user

[kobelb]

The kibana user is named awkwardly and there are quite a few users who confuse this with a user that they can login to Kibana with, which is not the case.

We'd like to deprecate the kibana user and have users begin using a new kibana_system user during 7.x lifecycle, and then remove the kibana user entirely in 8.0. This will put us inline with the "logstash_system", "beats_system", and "apm_system" users:

We'll need to figure out the best approach to issuing the deprecation warnings, and displaying this via the Kibana user management UI.

[elasticmachine]

Pinging @elastic/kibana-security

[elasticmachine]

Pinging @elastic/kibana-operations

[kobelb]

@clintongormley you're good at naming, and have good visibility into what the other teams are doing; does this proposed rename make sense to you or do you have an alternate suggestion?

[tylersmalley]

Do you want to include changing the kibana_user to kibana_admin here as well to align with other products?

[kobelb]

@tylersmalley I'm tracking that in a separate issue here: #25722

[clintongormley]

makes sense to me. btw, this has been an open request in ES for well over a year now :) elastic/elasticsearch#29808

[jinmu03]

My only concern is we already have a built in role called Kibana_system, now we are going to have a built-user called Kibana_system also. Will it cause more confusion?

[legrego]

My only concern is we already have a built in role called Kibana_system, now we are going to have a built-user called Kibana_system also. Will it cause more confusion?

I don't think it'd be too confusing. Having groups named after specific users is a pattern that's pretty common in *nix environments

[kobelb]

We were initially hoping to tackle this during the 7.0 upgrade process, but we determined it's effect on the end-user was going to be too great, so I've updated the description to specify the new deprecation plan.

[kobelb]

/cc @AlonaNadler

[StingyJack]

calling any account or role by the name system implies its for some non-user purpose like a background service.

To add to the confusion there is a kibana_user role that per the current docs is what I would want to grant to someone so they can use the dev tools or manage indexes but not users. However per es.co support, kibana_system is what I want to use (but I dont, because its named wrongly).

Continuing a confusing naming pattern just "to be consistent" is like pulling a log from a fire bare-handed, just because some of the others did it too. And its just one more potential roadblock to adoption.

[legrego]

@StingyJack,

calling any account or role by the name system implies its for some non-user purpose like a background service.

This is exactly how I think about the kibana/kibana_system user though. This is the account specified in your kibana.yml which is used by the Kibana server to connect to Elasticsearch. It is not supposed to be used by end-users, so our thinking here was that changing the account from kibana to kibana_system would make the account name less confusing, while also making the name consistent with the rest of the service accounts.

To add to the confusion there is a kibana_user role that per the current docs is what I would want to grant to someone so they can use the dev tools or manage indexes but not users.

Yep, the kibana_user role will grant users full access to Kibana, without giving them privileges to manage users or roles. (see also #25722)

However per es.co support, kibana_system is what I want to use (but I dont, because its named wrongly).

This doesn't seem accurate, sorry if you were misled.

Continuing a confusing naming pattern just "to be consistent" is like pulling a log from a fire bare-handed, just because some of the others did it too. And its just one more potential roadblock to adoption.

I hope I helped to clarify things -- let me know if you have more questions, or if I misunderstood your point in any way.

[StingyJack]

If that's the intent for kibana_system, then it shouldn't be in the list of choices for accounts that will be logging into kibana.

ES.co support did suggest creating a custom role before closing the support request, but I'm not terribly interested in getting into any kind of weeds with ES and this role grant is for a short term contractor helping us out.

The problem with kibana_user is that it doesn't actually do what the docs say. I assigned it to that contractor' newly created user account recently and a few things didn't work, most notably queries in dev tools (report auth errors.)

[legrego]

If that's the intent for kibana_system, then it shouldn't be in the list of choices for accounts that will be logging into kibana.

I completely agree! We are actively working on improving this experience here: #18270

ES.co support did suggest creating a custom role before closing the support request, but I'm not terribly interested in getting into any kind of weeds with ES and this role grant is for a short term contractor helping us out.

Custom roles are indeed the way to go here, as you can take advantage of the feature toggles introduced in 7.2: https://www.elastic.co/blog/introducing-kibana-feature-controls-curating-and-securing-feature-access, and assign additional index/cluster privileges as necessary.

The problem with kibana_user is that it doesn't actually do what the docs say. I assigned it to that contractor' newly created user account recently and a few things didn't work, most notably queries in dev tools (report auth errors.)

The kibana_user role grants access to Kibana, but it doesn't automatically grant access to your other data indices, and it doesn't grant cluster privileges. To grant access to your data indices or cluster operations, you'll need to create/assign additional roles to grant access. Perhaps we can clarify this point in our documentation to make it easier to understand.

[StingyJack]

access to Kibana, but it doesn't automatically grant access to your other data indices, and it doesn't grant cluster privileges. To grant access to your data indices or cluster operations

This sounds like there is an admin tool for es other than kibana where I would manage cluster permissions.

EDIT: perhaps this point was a bit too subtle. I dont think there are any other admin tools, so I would not be expecting that granting permissions in kibana is in any way separate from granting permission to the cluster, or that even if it were, then I would expect the grant in kibana to include any necessary cluster permissions.

I have no history with this program set until encountering it earlier this year, so I have no historical context of these being separate and distinct and growing together or whatever happened to come to the current, and I dont really want to have that information context because it isn't useful. The tool I use today is what should be consistent.

[joaociocca]

I see this is closed, but thought I'd leave my 2 cents about. Every time I run setup-passwords auto the resulting text makes me understand that the "Changed password for user kibana \ PASSWORD kibana = xxxxxxxx" is the one I should use for Kibana to authenticate with Elasticsearch on kibana.yml's elasticsearch.password setting. Is this going to change as well?

[legrego]

I see this is closed, but thought I'd leave my 2 cents about. Every time I run setup-passwords auto the resulting text makes me understand that the "Changed password for user kibana \ PASSWORD kibana = xxxxxxxx" is the one I should use for Kibana to authenticate with Elasticsearch on kibana.yml's elasticsearch.password setting. Is this going to change as well?

@joaociocca yes this will change as well. We introduced corresponding changes to the password setup utility in elastic/elasticsearch#54967 for version 7.8.0 (not released yet), which will setup a password for both the kibana and kibana_system users. We need to support both users for the remainder of 7.x so as not not break any existing setups during the upgrade process.

8.0 will remove the kibana user altogether, so you won't see this user referenced at all from that point on.

[flo-ryan]

At the beginnen of this page in the guide it still says "kibana", while later on it says "kibana_system".
https://www.elastic.co/guide/en/elasticsearch/reference/current/built-in-users.html

[legrego]

At the beginnen of this page in the guide it still says "kibana", while later on it says "kibana_system".
elastic.co/guide/en/elasticsearch/reference/current/built-in-users.html

@flo-ryan thanks for letting us know! I opened elastic/elasticsearch#58422 to track this.