Secure visibility of index-patterns

[woodywalton]

Just the knowledge about the existence of an index-pattern can sometimes be too much information, even though RBAC prevents access of the data within the related indices. Perhaps this requires a new permission type on the ability to list-indices or something similar?

[elasticmachine]

Pinging @elastic/es-security (Team:Security)

[tvernum]

Do you mean Kibana index patterns, or something else? Can you provide a concrete example?

[woodywalton]

Hi @tvernum ! Sure thing - and yes I do mean Kibana index-patterns. Let's say that we have a Role called black_speech (this was leftover from a LOTR-themed demo that pretended kibana_sample_data_logs was a protected data set from Mordor):

We have a wizard user Gandalf who should be the only one who can read that black_speech data set, and we should definitely keep our hapless Hobbit users from reading it aloud - but unfortunately even our non-wizard users can see the existence of the index and wonder what's in it:

We all know how curious Pippin can be and what trouble that gets him into...

So it would be cool if we could hide the existence of resources that our users don't have access to.

[woodywalton]

@derickson for visibility

[derickson]

@bytebilly @tvernum
Is this something that would only be secured in our security model once we achieve Object level security for kibana inside of a space? @woodywalton , does this even manifest as a problem cross-space?

[woodywalton]

I think it could be a problem, depending on the customer expectations about whether a user should know about the existence of a data source or not. In the example I outlined it's exposed cross-space, hence why I suggest adding the ability to put security controls on index-patterns like we would for other saved objects.

[tvernum]

I'm going to move this to the kibana repository, because I think the solution needs to be driven from there.

Would we prefer to

1. Apply security to the index pattern as an object. That is, attach some sort of permissions model to an index pattern so that black_speech can be locked down to just Gandalf.
   OR
2. Automatically determine whether the user has permission to some/all of the underlying indices and only show index patterns that would resolve to an index (Important: I don't think this should mean "an index exists", because that would hide index patterns from everyone if data that was deleted. It should mean "if an index was created for this pattern, would the current user be able to search in it").

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[legrego]

This is a duplicate of #23294. Closing in favor of the original

[woodywalton]

Thanks @legrego - sorry for he late response, didn't realize this got closed.

I just did some testing on my same "Minas Tirith" cluster for this... While pushing users through the Spaces construct would work if the Space isn't shared amongst users of differing roles, and it does indeed prevent users from seeing actual data (or selecting indices they don't have access to during index_pattern creation process), it does not prevent the user from seeing index_patterns created within the same Space by another user with a different role.

User aragorn does not have the black_speech role and cannot access that data, but because he shares a Space with user gandalf and he did create that index_pattern, aragorn can see it:

[legrego]

Hey @woodywalton,

While pushing users through the Spaces construct would work if the Space isn't shared amongst users of differing roles, and it does indeed prevent users from seeing actual data (or selecting indices they don't have access to during index_pattern creation process), it does not prevent the user from seeing index_patterns created within the same Space by another user with a different role.

Yes, I agree. I think the issue I linked above (#23294) describes this requirement, regardless of which Space the user us currently in. Ideally we wouldn't show index patterns Data Views to users who aren't authorized to read any of the underlying indices.

[woodywalton]

Thanks again @legrego !