Fix fleet route protections

[legrego]

#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]

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

[ph]

The above linked PR is also in 7.10

[jfsiii]

@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]

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]

@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]

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]

@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]

@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]

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.

[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]

@elasticmachine merge upstream

[kibanamachine]

💚 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