[Fleet] Multiple output UI

[nchaulet]

Description

Implementation task for the multiple output UI.

Taks

• Move the settings and outputs UI outside to their own tab
• Crud operation for the outputs
• Validate internal ES cluster or display a warning

TODO Add more description here,

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[joshdover]

One thought I had: since we'll now be exposing additional Elasticsearch outputs (for the same cluster) to the user, should we be trying to validate that the Elasticsearch host is for the same cluster? It's tricky because we may not always have network access, but I think we could do a best effort to at least validate that the kibana_system user's credentials work on the cluster and the same cluster UUID is returned. If we can't access we could at least show a warning.

[nchaulet]

One thought I had: since we'll now be exposing additional Elasticsearch outputs (for the same cluster) to the user, should we be trying to validate that the Elasticsearch host is for the same cluster? It's tricky because we may not always have network access, but I think we could do a best effort to at least validate that the kibana_system user's credentials work on the cluster and the same cluster UUID is returned. If we can't access we could at least show a warning.

I think it's always a good idea to validate user input. What do you have in mind validating before creating or updating and show a toast warning if Kibana was not able to reach ES or the cluster UUID is different?

We could try to reach the output, but I guess there will a be a few time where we cannot reach ES. Also which credentials should we use to call ES? the user one? Is there any security issues here?

[joshdover]

What do you have in mind validating before creating or updating and show a toast warning if Kibana was not able to reach ES or the cluster UUID is different? We could try to reach the output, but I guess there will a be a few time where we cannot reach ES.

I think we can follow logic like:

• If we can reach ES, but get a 401 Unauthorized: don't allow them to add the output
• If we can reach ES but the cluster UUID is different: don't allow them to add the output
• If we can't reach ES, show a warning that we couldn't validate access (with the underlying error message) and allow them add the output anyways if they choose

In terms of where in the flow to put this, I think we should work with @dborodyansky to integrate this in to the current designs.

Also which credentials should we use to call ES? the user one? Is there any security issues here?

It's a good point, because we'd be sending credentials to a potentially untrusted source. We need to be careful to make sure that a user couldn't use this to retrieve the kibana_system credentials. So I think we have to use the current user's credentials, which may or may not have access to the GET / API (I can't find the docs right now on what privilege is required, if any). We should make sure there is some API that we can be sure all users have access to before worrying about design.

[nchaulet]

Resolved by #118910