Deprecate xpack:default_admin_email for monitoring use

[legrego]

The Spaces plugin will be making the Advanced UI Settings space-aware. There are a couple of UI Settings that do not make sense to be space-specific, such as xpack:default_admin_email. The email address to be used for monitoring alerts should be set for the entire Kibana instance, rather than for each individual space within the instance.

Instead of supporting one-off cases for specific configuration settings like this one, we are proposing deprecating Monitoring's use of xpack:default_admin_email in favor of a new kibana.yml setting (e.g., xpack.monitoring.clusterAlertsEmail)

For the remainder of 6.x, Monitoring will use the xpack:default_admin_email from the Default Space if the yml option is not set. A deprecation warning will be logged the first time this happens. From 7.0 forward, Monitoring will only use the yml setting.

This setting will still be used by Watcher in order to populate the default email when creating a new email alert, but this can happen in a space-specific manner.

@kobelb @tsullivan @pickypg @chrisronline @ycombinator

[ycombinator]

First off, thanks for the excellent issue description, @legrego!

Perhaps this was discussed already but moving the setting out of Advanced Settings and into kibana.yml means restarting the the kibana server if the setting needs to be changed. I wouldn't expect this setting to be changed too frequently so perhaps this isn't a big deal. It also implies that users who have access to the Kibana UI might have (directly or indirectly) access to the Kibana server, which is sometimes not the case or not easy in larger organizations.

I don't know enough about Spaces but I don't suppose there can be a provision for designating certain advanced settings as per-kibana-instance as opposed to per-space?

[tsullivan]

@pickypg Does it seem possible to make this value a dynamic setting in Elasticsearch?

It's Elasticsearch that needs the value, from the context of a Watcher action.

[pickypg]

We could and it's not a bad idea. In fact, we could perhaps enhance the Cluster Alerts to use the default email for Watcher if it exists (as that is something that can already be specified there). However that would be a pretty big breaking change and one that shouldn't have a long shelf life given other plans.

[legrego]

@ycombinator

I wouldn't expect this setting to be changed too frequently so perhaps this isn't a big deal.

This is our hope/assumption too.

It also implies that users who have access to the Kibana UI might have (directly or indirectly) access to the Kibana server, which is sometimes not the case or not easy in larger organizations.

This is a good point. It's my hope that this won't be configured all that often, and that it could be set by an administrator, but I understand that this could be difficult for larger organizations.

I don't know enough about Spaces but I don't suppose there can be a provision for designating certain advanced settings as per-kibana-instance as opposed to per-space?

This is a concept that we are trying to avoid. It ends up complicating the way we secure access to these settings, and it adds additional UI work for the management screens that we'd rather not try to fit in for the Spaces release.

[epixa]

I have no objections to this, but it'll be critical to ensure that the appropriate kibana.yml configuration is whitelisted on cloud so that all cloud users could set it via the cloud dashboard. They might even want to provide a default value for it based on the account owner or something.

[chrisronline]

This is old, but wanted to raise a question.

Now that Stack Monitoring is migrating to Kibana alerting, alerts will exist on a space-by-space basis and we are using a saved object to save the recipient email address so theoretically, users could configure a separate recipient email for each space and that spaces' alerts.

I think we should re-introduce this setting back into Advanced Settings, as the PR linked above will change where we store this email address in the first place (which will align more closely with how most other Kibana apps handle configuration)

cc @elastic/stack-monitoring

[cachedout]

@chrisronline Thanks for bringing this up again. I'd like to understand more about how this setting would be used in the context of a migration to Kibana Alerting, however. Could you expand on that, please?

[chrisronline]

In #49219, we are moving away from watcher-based cluster alerts, which means we can manage the configuration of these differently. For watcher-based cluster alerts, the user needed to configure the smtp server in elasticsearch settings but with Kibana alerting, we persist action configurations within Kibana actions (which just used saved objects under the hood I think).

So in this PR, we created a curated UI to allow the user to configure these smtp email settings, and then we just send an API request to the actions plugin to persist them.

Now, what does this have to do with the recipient email address?

Well, now that the process of configuring the smtp email service is seamless in the UI, why make the user configure the recipient email address through kibana settings? Why don't we just make the experience the same, and have the user configure this email address in the UI too?

This does mean the monitoring UI needs to persist this somewhere (this wouldn't exist within the actions or alerting plugins), so we'll need to create a saved object to handle this. Why not just re-use the config saved object and let the user manage the email address in Advanced Settings too?