RBAC - Using a legacy fallback

[kobelb]

Background

To facilitate rolling out RBAC in a minor, we've been planning on requiring users to change a setting in their kibana.yml to enable RBAC and create parallel roles equivalent to the kibana_user and kibana_dashboard_only_user roles that utilize the application privileges instead of direct index privileges. We were planning to do so because changing the fundamental way that the kibana end-user roles worked was considered a breaking change for two main user groups:

1. Those with multi-tenant deployments of Kibana, as they aren't using the built-in kibana_user roles and they have configured their own roles which are for different .kibana indices
2. The customers that have hand-rolled their own access control utilizing document-level-security and field-level-security

There are a few issues with this approach, that create a less than ideal user experience. Requiring users to change a setting in their kibana.yml to utilize this new authorization mode is a rather large hindrance. Additionally, having to create parallel roles is a rather large ask from system administrators and providing seamless automation for this process becomes a significant development effort. Also, this new authorization approach is something that we really want to become the default, and the only reason why we were planning on allowing users to opt-in to it was because it's seen as a breaking change in a minor.

I was talking with @skearns64 the other day with regard to the way that customers are hand-rolling their own access control using DLS/FLS and as far as he is aware we don't have any customers actually doing this in production. This eliminates one of the user groups that we were worried about this being a breaking change for, and leaves us with the multi-tenant deployments of Kibana. This has opened up the possibility of an alternate solution, which I have presented below.

Solution

To mitigate the breaking change that using RBAC authorization for all deployments of Kibana has, we'd like to implement a "legacy fallback" that will be utilized in 6.x , where if the authenticated end-user accessing Kibana has no application privileges, that instead we check to see whether they have index or read privileges on the underlying .kibana index and grant them the implicit application privileges that these privileges infer. When we are forced to utilize this "legacy fallback" we'll log a deprecation warning in their kibana log files in 6.x and then remove this fallback entirely in 7.0.

Implementing this legacy fallback allows us to no longer have to require users to change anything in their kibana.yml, or maintain parallel roles. Instead, we'll change the reserved kibana_user and kibana_dashboard_only_user roles to use the application privileges by default, and this will be a seamless transition for all single-tenant deployments of Kibana that utilize the reserved/built-in roles.

[kobelb]

/cc @jinmu03 @skearns64 @joshbressers @legrego @clintongormley @kimchy @epixa

[joshbressers]

I think the answer to this is yes but I want to double check. Will users that have defined a .kibana index name in the configuration file see any changes to existing behavior if they use fallback?

I do like this idea, it will be less disruptive

[kobelb]

The only change that they will see is the requirement to set the ‘xpack.security.rbac.application’ if they have changed the ‘kibana.index’, besides that everything will function effectively the exact same.

[epixa]

I like this line of thinking.

The only change that they will see is the requirement to set the ‘xpack.security.rbac.application’ if they have changed the ‘kibana.index’, besides that everything will function effectively the exact same.

What's the value in separating these configurations rather than just having the security plugin rely on kibana.index? When would we ever want those to be different?

I was talking with @skearns64 the other day with regard to the way that customers are hand-rolling their own access control using DLS/FLS and as far as he is aware we don't have any customers actually doing this in production. This eliminates one of the user groups that we were worried about this being a breaking change for

@skearns64 knows pretty much everything about everything, and I trust his knowledge on this more than anyone else, but I want to emphasize how critical of a problem this would be for any customers we don't know about: the effect of this change for anyone using DLS/FLS on the kibana index will be to expose all of their previously private data to everyone with access to Kibana. If it's used in a publicly accessible Kibana, this would mean exposing all of your previously private Kibana objects to the world. This is the sort of thing we'd rush an emergency patch release to address, hotfix builds, etc. About the only saving grace is that it would probably only be read access.

Is there a way for us to determine whether a user (or their roles) have DLS/FLS permissions on the .kibana index? Even if we could provide no graceful solution here and simply block authentication on users in this scenario, it would be infinitely better to simply lock a person out than it would be to expose all of your private objects to the world.

[kobelb]

What's the value in separating these configurations rather than just having the security plugin rely on kibana.index? When would we ever want those to be different?

We generally don't ever want these to be different. Separating this settings was for two reasons historically:

1. There was a "philosophical" issue with making the user specify the internal index that Kibana uses, so we were trying to prevent having another setting tied specifically to this.

2. I believe that there are different validation rules for index names compared to application names, so there were situations where we couldn't rely on using the index names in these situations. @legrego would you mind verifying this to make sure I'm not mis-remembering.

Is there a way for us to determine whether a user (or their roles) have DLS/FLS permissions on the .kibana index? Even if we could provide no graceful solution here and simply block authentication on users in this scenario, it would be infinitely better to simply lock a person out than it would be to expose all of your private objects to the world.

I think this is a good idea, unfortunately, I'm not familiar with the APIs that we'd use to check this, would you mind looking into this as well @legrego?

[legrego]

I believe that there are different validation rules for index names compared to application names, so there were situations where we couldn't rely on using the index names in these situations. @legrego would you mind verifying this to make sure I'm not mis-remembering.

I think this used to be an issue for a couple of reasons:

1. We were creating roles based off this name, but we aren't doing so anymore as of last week.
   2. I believe we used to prefix the privilege actions with the application name, which had naming restrictions we had to abide by. We are no longer doing this either, since the privilege api was recently refactored. (this is still a restriction)

Is there a way for us to determine whether a user (or their roles) have DLS/FLS permissions on the .kibana index? Even if we could provide no graceful solution here and simply block authentication on users in this scenario, it would be infinitely better to simply lock a person out than it would be to expose all of your private objects to the world.

This is explicitly disallowed through the _has_privileges API, and the way that index permissions are setup makes this rather tricky to figure out by parsing the role definitions manually.

@elastic/es-security -- do you know if it's possible for us to determine if a user (or their roles) have DLS/FLS permissions on the .kibana index? ?

[skearns64]

do you know if it's possible for us to determine if a user (or their roles) have DLS/FLS permissions on the .kibana index?

I'm still not sure it's worth writing code to catch this case, but if we strongly want to, one simple way to do it would be with two simple checks. First, does the current use have read-only access to .kibana, and second, is the document count in the .kibana index different between what the kibana server user sees, vs what the user sees. If there is a difference, other than being a race condition when a new doc is added, it means that the current user has a filtered view of .kibana.

[epixa]

There was a "philosophical" issue with making the user specify the internal index that Kibana uses, so we were trying to prevent having another setting tied specifically to this.

@kobelb I don't understand this. If users only ever need to specify xpack.security.rbac.application when they specify a non-default kibana.index, and they always must specify the former when specifying the latter, how is there a philosophical difference between the approach?

I'm still not sure it's worth writing code to catch this case, but if we strongly want to, one simple way to do it would be with two simple checks. First, does the current use have read-only access to .kibana, and second, is the document count in the .kibana index different between what the kibana server user sees, vs what the user sees. If there is a difference, other than being a race condition when a new doc is added, it means that the current user has a filtered view of .kibana.

This is a clever suggestion, but I don't think we should go down this route due to the race condition. The last thing we want to do is introduce a behavior that randomly denies login for some people that otherwise have no business being rejected. If there isn't a reliable way to do this check, then I don't think we should do the check at all.

[legrego]

If there isn't a reliable way to do this check, then I don't think we should do the check at all.

If it turns out that we can't reliably do this check, and we don't hear about any customers using DFS/FLS in this manner, then are we still comfortable with this legacy fallback approach? If it helps, we can call out/remind users in our release notes for 6.4 that DLS/FLS is not supported on the .kibana index.

[epixa]

@legrego I think fundamentally the legacy fallback approach is ideal, so if we've done our due diligence and still aren't aware of any problems, we should do it.

[kobelb]

@kobelb I don't understand this. If users only ever need to specify xpack.security.rbac.application when they specify a non-default kibana.index, and they always must specify the former when specifying the latter, how is there a philosophical difference between the approach?

The philosophical reason stemmed from a conversation with regard to requiring the user to specify a different index at all, as opposed to specifying a more logical “group” or “application”, that I don’t think has any weight given the current situation, so it’s probably best to ignore at this point in time.

[epixa]

@kobelb Makes sense. I think that's a good direction, but it should be treated holistically rather than feature by feature. Especially when it would actually make the experience worse of using an otherwise awesome feature, which seems to be the case here.

[tvernum]

I can't think of any easy way to check for DLS / FLS on the Kibana index short of parsing the roles yourselves (and even that is a problem because we still support roles that are defined in files and there is no API to access those).

We could add something to _has_privileges to indicate that the are DLS/FLS restrictions on an index check, but it's not trivial (mostly due to being an API change, the check itself shouldn't be too bad), and it doesn't sound like it's a huge priority for you. If you think you need it, shout and I'll try and get a better estimate for you.

[legrego]

Thanks for confirming, Tim! Right, let's not plan on that API change unless you hear otherwise.

I believe we used to prefix the privilege actions with the application name, which had naming restrictions we had to abide by. We are no longer doing this either, since the privilege api was recently refactored.

I take this back -- Application names still have a naming restriction that differs from the index naming restrictions, so I think we still have a need for xpack.security.rbac.application. (e.g., ".kibana" is a valid index, but not a valid application name)

[tvernum]

The validation for application names is a little arbitrary, (I typically opt for an overly conservative validation) so if we need to change it, we that's open for discussion.

[epixa]

@tvernum It would be helpful if we could make it so the application name has the same validation rules as indices. If the current validation rules are mostly arbitrary and you can't think of a reason why the index validation rules would be a problem for application privileges, then this will make the upgrade path for more Kibana users seamless.

I'd love to get rid of this whole custom index approach that we have in Kibana today, but it's a big change and it's not urgent, and there's no reason for us to couple that to such a high impact change like this authorization model.

[kobelb]

@tvernum It would be helpful if we could make it so the application name has the same validation rules as indices. If the current validation rules are mostly arbitrary and you can't think of a reason why the index validation rules would be a problem for application privileges, then this will make the upgrade path for more Kibana users seamless.

Seconding this, is it within the realm of possibility to get this changed for the initial merge in 6.4? If so, we can begin to work on making Kibana default to using the index name as the application.