Fix fleet route protections #85626

legrego · 2020-12-10T19:21:39Z

#85136 Introduced additional route checks for Fleet's endpoints.

These checks did not account for the fact that security might be disabled in Elasticsearch. When that happens, these routes were incorrectly returning a 401 response to the UI, which triggered a logout response.

cc @elastic/kibana-qa

elasticmachine · 2020-12-10T19:21:43Z

Pinging @elastic/ingest-management (Team:Ingest Management)

ph · 2020-12-10T19:38:47Z

The above linked PR is also in 7.10

jfsiii · 2020-12-10T20:51:17Z

@legrego thanks for the PR! We definitely want to fix the logout regression.

What happens if security is disabled and the user requests one of these routes? Will it succeed? I'd try myself but I'm not near a computer right now.

cc @ph @nchaulet @ruflin @mostlyjason who have greater context

legrego · 2020-12-10T21:05:48Z

What happens if security is disabled and the user requests one of these routes? Will it succeed? I'd try myself but I'm not near a computer right now.

Before or after this change?

Prior to this change, accessing any page that leveraged a Fleet API would cause the user to be redirected a few times, and eventually end up on the home page. The sample data screen, for example, makes a call to /api/fleet/settings. When this returns a 401, Kibana thinks that the user is not authenticated, and attempts to redirect the logout flow so that the user can reauthenticate. Since security is not enabled, the user will end up on the Kibana home page following the "logout". The result is that any page that uses a Fleet API will be inaccessible to the end user when security is disabled.

After this change, the call will succeed. Since security isn't enabled, there's no need to check for superuser status, since we don't have the concept of users or roles at that point.

nchaulet · 2020-12-10T21:10:46Z

@legrego Thanks for looking at this I think we do not want Fleet API to succeed if security is not enabled, so we should probably change this to return a 403 instead no?
The superuser role is enforced in the UI so Kibana will not make any request to Fleet API if the user do not have the superuser role.

legrego · 2020-12-10T21:14:34Z

Thanks for looking at this I think we do not want Fleet API to succeed if security is not enabled, so we should probably change this to return a 403 instead no?

Fleet currently has an optional dependency on the security plugin, so that lead me to believe that Fleet should continue to work if security wasn't enabled. If that's not the case then I'm happy to return a 403 instead, but we should probably update your dependencies to reflect that as well.

The superuser role is enforced in the UI so Kibana will not make any request to Fleet API if the user do not have the superuser role.

That's good to know. If that's the case, then shouldn't the sample data screen not even attempt the call to /api/fleet/settings when security is disabled?

nchaulet · 2020-12-10T21:26:23Z

@legrego We do not enable API routes if the security plugin is not here, and we display a message to the user that it should have security enabled and the superuser role, in the fleet plugin.

Looks like we missed a check in the sample data screen

jfsiii · 2020-12-10T21:32:34Z

@legrego I meant after. I was asking for the reason @nchaulet mentioned.

I agree with the 403 failure if it's disabled.

I understand the assumption/confusion about the optional security dependency. There was some confusion internally about when superuser was required (e.g. only agent or all routes) and @ruflin recently clarified that we want all our routes protected.

I'm not sure if that means we should make security required, or if it can remain optional and we reject if it's not available.

legrego · 2020-12-10T21:42:51Z

We do not enable API routes if the security plugin is not here, and we display a message to the user that it should have security enabled and the superuser role, in the fleet plugin.

Ah gotcha. For what it's worth, enabling Kibana's security plugin isn't enough to enable the stack security features. Elasticsearch's security plugin must also be enabled, and Kibana doesn't know if it's enabled until it's had a chance to connect and potentially authenticate to the cluster.

I meant after. I was asking for the reason @nchaulet mentioned.

I agree with the 403 failure if it's disabled.

I understand the assumption/confusion about the optional security dependency. There was some confusion internally about when superuser was required (e.g. only agent or all routes) and @ruflin recently clarified that we want all our routes protected.

I'm not sure if that means we should make security required, or if it can remain optional and we reject if it's not available.

Thanks for clarifying. I'll go ahead and change the response to 403 instead of allowing the request to continue.

This reverts commit cbc22b4.

nchaulet

🚀 LGTM I will create a follow up issue to avoid to send a request from the sample data if the user do not have permissions or if security is not enabled

legrego · 2020-12-13T14:35:21Z

@elasticmachine merge upstream

kibanamachine · 2020-12-13T16:47:55Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request
Commit: 0b448d8

Metrics [docs]

Distributable file count

id	before	after	diff
`default`	47129	47889	+760

History

💚 Build #93684 succeeded 3ccb5de
💚 Build #93640 succeeded cbc22b4

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

* master: (116 commits) Fix UX E2E tests (elastic#85722) Increasing default api key removalDelay to 1h (elastic#85576) align cors settings names with elasticsearch (elastic#85738) unskip tests and make sure submit is not triggered too quickly (elastic#85567) Row trigger 2 (elastic#83167) Add session id to audit log (elastic#85451) [TSVB] Fields lists do not populate all the times (elastic#85530) [Visualize] Removes the external link icon from OSS badges (elastic#85580) fixes EQL tests (elastic#85712) [APM] enable 'log_level' for Go (elastic#85511) ini `1.3.5` -> `1.3.7` (elastic#85707) Fix fleet route protections (elastic#85626) [Monitoring] Some progress on making alerts better in the UI (elastic#81569) [Security Solution] Refactor Timeline Notes to use EuiCommentList (elastic#85256) [Security Solution][Detections][Threshold Rules] Threshold rule exceptions (elastic#85103) [Security Solution] Alerts details (elastic#83963) skip flaky suite (elastic#62060) skip flaky suite (elastic#85098) skip flaky suite (elastic#84020) skip flaky suite (elastic#85671) ...

Fix fleet route protections

cbc22b4

legrego added v8.0.0 release_note:skip Skip the PR/issue when compiling release notes v7.11.0 labels Dec 10, 2020

legrego requested a review from a team December 10, 2020 19:21

botelastic bot added the Team:Fleet Team label for Observability Data Collection Fleet team label Dec 10, 2020

legrego requested a review from nchaulet December 10, 2020 19:33

legrego added 2 commits December 10, 2020 16:43

Revert "Fix fleet route protections"

fa597f3

This reverts commit cbc22b4.

respond with 403 instead of 401 if a user cannot be retrieved

3ccb5de

nchaulet approved these changes Dec 10, 2020

View reviewed changes

nchaulet added the v7.10.0 label Dec 10, 2020

Merge branch 'master' into fleet/fix-superuser-check

0b448d8

legrego added v7.10.2 and removed v7.10.0 labels Dec 13, 2020

legrego merged commit 96bb72f into elastic:master Dec 13, 2020

legrego deleted the fleet/fix-superuser-check branch December 13, 2020 17:40

This was referenced Dec 13, 2020

[7.x] Fix fleet route protections (#85626) #85720

Merged

[7.10] Fix fleet route protections (#85626) #85721

Merged

legrego added a commit to legrego/kibana that referenced this pull request Dec 13, 2020

Fix fleet route protections (elastic#85626)

9995b73

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

legrego added a commit to legrego/kibana that referenced this pull request Dec 13, 2020

Fix fleet route protections (elastic#85626)

668f4d5

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix fleet route protections #85626

Fix fleet route protections #85626

legrego commented Dec 10, 2020 •

edited

Loading

elasticmachine commented Dec 10, 2020

ph commented Dec 10, 2020 •

edited

Loading

jfsiii commented Dec 10, 2020

legrego commented Dec 10, 2020

nchaulet commented Dec 10, 2020 •

edited

Loading

legrego commented Dec 10, 2020 •

edited

Loading

nchaulet commented Dec 10, 2020

jfsiii commented Dec 10, 2020

legrego commented Dec 10, 2020

nchaulet left a comment

legrego commented Dec 13, 2020

kibanamachine commented Dec 13, 2020

Fix fleet route protections #85626

Fix fleet route protections #85626

Conversation

legrego commented Dec 10, 2020 • edited Loading

elasticmachine commented Dec 10, 2020

ph commented Dec 10, 2020 • edited Loading

jfsiii commented Dec 10, 2020

legrego commented Dec 10, 2020

nchaulet commented Dec 10, 2020 • edited Loading

legrego commented Dec 10, 2020 • edited Loading

nchaulet commented Dec 10, 2020

jfsiii commented Dec 10, 2020

legrego commented Dec 10, 2020

nchaulet left a comment

Choose a reason for hiding this comment

legrego commented Dec 13, 2020

kibanamachine commented Dec 13, 2020

💚 Build Succeeded

Metrics [docs]

Distributable file count

History

legrego commented Dec 10, 2020 •

edited

Loading

ph commented Dec 10, 2020 •

edited

Loading

nchaulet commented Dec 10, 2020 •

edited

Loading

legrego commented Dec 10, 2020 •

edited

Loading