[Ingest] Enforce security required and superuser permissions #65315
Conversation
jen-huang
added
v8.0.0
release_note:skip
|
Pinging @elastic/ingest-management (Team:Ingest Management) |
| <PackageInstallProvider notifications={notifications}> | ||
| <FleetStatusProvider> |
There was a problem hiding this comment.
These two providers were moved here from IngestManagerApp so that they are loaded only after permissions & setup checks are done
| if (permissionsResponse.success) { | ||
| const { isInitialized: success } = await core.http.post(setupRouteService.getSetupPath()); |
There was a problem hiding this comment.
Only send setup if permissions check passed
| const permissionsResponse = await sendGetPermissionsCheck(); | ||
| setIsPermissionsLoading(false); | ||
| if (permissionsResponse.data?.success) { | ||
| try { |
There was a problem hiding this comment.
nitpick: maybe put this in a new function for readability, the level of indentation start to be hard to read
nchaulet
left a comment
nchaulet
left a comment
There was a problem hiding this comment.
Tested locally it worked as expected
|
Pushed up a change that hides the global settings link if there is a permission/security issue. As a bonus, this also kicks in if there were any setup issues:
|
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
…#65315) * Add check permissions route and request hook * Conditionally register routes * Add security not enabled and permissions missing warning UIs * Hide global settings when there is an error # Conflicts: # x-pack/plugins/ingest_manager/server/plugin.ts
…#65368) * Add check permissions route and request hook * Conditionally register routes * Add security not enabled and permissions missing warning UIs * Hide global settings when there is an error # Conflicts: # x-pack/plugins/ingest_manager/server/plugin.ts Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
|
@jen-huang the route Since endpoint has a dependency on Ingest (APIs), we will also need to implement something like this on our side for the views that interact directly with Ingest APIs. We also have one of our API that uses the ingest service to enrich our host metadata with an agent status value, so that might be impacted as well. cc: @kevinlog , @nnamdifrankie |
|
@paul-tavares thank you for the ping. We currently use the security of the data client from the core. Does this change that? |
|
@nnamdifrankie not sure. If that client uses the login user's security profile, then yes it would be impacted (I assume). Although - I think @jen-huang indicated above that its not being enforced at the API route level, but what about at the ingest API service level? |
Yes that's correct.
No enforcement (neither security enabled nor permissions) is done at API service level atm. |
|
I added this to the agenda for the next sync so we can discuss it more. |
7 participants
Resolves #64236
Resolves #64242
Summary
This PR makes it so that accessing Ingest Manager UI requires that 1) security is enabled and 2) user has
superuserrole privileges. This is done by adding a new route/api/ingest_manager/check-permissionsand sending a request to that from the UI.On the server side, routes will only be registered if security is enabled. Due to additional complexity involved with checking for
superuserrole for each route, this PR does not cover that.To test security disabled, set
xpack.security.enabled=falsein Kibana and ES. You should see this UI:To test
superuserrole privileges, create a new user that does not havesuperuserrole and log in with that user. You should see this UI: