I want to give users permission to create their own index patterns and use Discover functionality in a private tenant. I found that assigning the all_access role completely meets these requirements, but I don’t actually want to give users such broad permissions. Is there a way to restrict which indices they can read while still allowing them to have permissions for index patterns and Discover?
@sandy You could give write permission to the Tenant (index pattern) and limit access to indices by specifying exact index patterns in the role configuration.
@pablo Thank you for your response. Are you suggesting creating a separate tenant for each user and assigning permissions to restrict access? If that’s the case, we are currently using a similar approach, but instead of managing permissions per user, we’re doing it by group to reduce the operational workload.
However, managing by group has a drawback — when users work with dashboards or visualizations, the objects they save can potentially be modified by others in the same group. The reason I initially set it up this way is because most users were unfamiliar with the system, so I had to prepare a simple template for them to get started easily. Once they got used to working with dashboards, they naturally wanted to customize their own views, which led to users interfering with each other’s configurations.
Creating individual tenants per user isn’t a problem in itself, but when the number of users grows large, it becomes quite burdensome from a maintenance perspective, as it involves many setup steps.
That’s why I wanted users to switch to using their own private tenant for customization. However, I found that even when users already had the other_tenant permission provided earlier by the admin, they still couldn’t replicate those permissions in their private tenant. Unless I grant them all_access permission in one of the tenants, they are unable to create index patterns or review data in Discover within their private tenant.