[Controls] Use Internal User to Get Value of allow_expensive_queries

[ThomThomson]

Summary

This PR changes the way we access allow_expensive_queries to use the internal user. The internal user will have monitor permissions in almost every case, so this PR also removes the fallback added in #155082.

Additionally, because we're now using the internal user, this PR renames getClusterSettings endpoint for Controls into a getExpensiveQueriesSetting endpoint to be more specific.

I tested this PR by:

• Creating a new role that has no monitor privilege and assigning a user to that role
• Logging in as that user and ensuring that the controls are using expensive queries
• Logging back in as the elastic user and setting

  PUT _cluster/settings
  {
    "transient": {
      "search.allow_expensive_queries": "false"
    }
  }
  

• Logging in as the user without monitor privilege again and ensuring that the Controls are now not using the expensive queries.

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 09d2c48

Metrics [docs]

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
controls	32.8KB	32.8KB	+8.0B

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
securitySolution	394	397	+3

Total ESLint disabled count

id	before	after	diff
securitySolution	474	477	+3

History

• 💚 Build #121685 succeeded e32407b

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

[jeramysoucy]

Looks good from our perspective.

[nreese]

Would it make sense to add an integration test to ensure kibana user has continued permission access? I could see kibana user roles getting changed and this breaking but no one noticing.

[ThomThomson]

Good question! I think we will be okay without functional tests specifically designed to catch changes in permissions on the Kibana Internal User.

One reason for this is that we're now using the internal user for all scenarios, not just for some cases - or certain roles etc.
This means that if the kibana internal user no longer had monitor permissions, we would see that reflected as a failing test in CI because:

• Many of our tests require allow_expensive_queries to be on.
• If the internal user has had the monitor permission removed the server would throw a permissions error in this endpoint.
• The client side catches that error and returns false.
• All of our tests that require expensive_queries will begin to fail because of missing functionality.

Another reason is because we are far from the only application to require the internal Kibana user to have this permission - from @legrego on slack:

At this point Kibana requires that it’s internal user account be granted the kibana_system role. It’s safe to assume this will always be the case. If customers are running an unsupported setup, then we can help them get the right role assigned. These privileges change often enough that other parts of Kibana would also break if users had this misconfigured.

[nreese]

LGTM
code review only

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.7

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation