search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.71k stars 8.12k forks source link

Improved Background Permissions Flow for Applications #190319

Open legrego opened 1 month ago

legrego commented 1 month ago

Originally requested by @andrewvc. Copying his description verbatim:

The current background permissions flow for applications requires too much interaction and creates bad user experiences. This flow, used in o11y projects such as Synthetics, SLOs, and our new Entities framework should be eliminated and fully automatic.

Today, if you want a task manager process, or a new transform created etc. that requires direct approval from an administrator. This is not considered normal throughout the industry and is a particularly poor match for Serverless. Instead of the experience being automatic, rather it feels rather manual and demands the same sort of sysop mentality as ESS / On-Prem.

We should strive to improve our permissions model over the long term to allow for Elastic devs to create background tasks and other processes that should generally be invisible to the user without any explicit opt-in or permissions.

elasticmachine commented 1 month ago

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

jasonrhodes commented 3 weeks ago

Hello, thanks for creating this. I just wanted to call attention to a similar, related-but-not-quite-the-same issue we're looking into. For SLOs, we want to create, edit, and delete some ES assets using a system user (transforms, ingest pipelines) but we want those assets to run using a real user's given permissions, so that they only operate on data that user has access to read. For that situation, the "secondary authorization" model seems to work perfectly. @dominiqueclarke has put together a great draft PR to demonstrate how we plan to use this for SLOs.

That said, for this issue, I think it's different because the background task is meant to start up on its own and operate with system user privileges, and to be able to read from source indices as well, so it's not really a "split auth" situation as much as needing a more powerful system user for background task management, I think? But I wanted to call out the similarity in the two scenarios, in case I'm missing something.