Kibana: Alerting TLS requirement should be a blocking action in the UI

[snide]

From a design standpoint we should handle the TLS requirement better. If Alerting does not work until TLS is set up, we should not display create actions for alerts till that section is done.

Off-hand the suggestion would be to use a road block, rather than a warning for these items. Otherwise they confuse what the next steps are. Specifically running through the creation flows lead to dead ends, so we shouldn't be showing the forms.

Also, try not to use buttons for links. Use links for links. The buttons here look like they are toggles. We should telegraph to the user what clicking that button does. "Check the docs for how to set up TLS"...etc.

cc @mdefazio @andreadelrio

[elasticmachine]

Pinging @elastic/kibana-design (Team:Design)

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[mdefazio]

We will discuss and finalize the decision for this tomorrow at our sync.

[mikecote]

As discussed during today's sync, we'll display the banner and remove other functionality. The same would apply to the create alert flyout.

[gmmorris]

I'm picking this up along with https://github.com/elastic/kibana/issues/62595 (there's context in that issue) as we feel they can be addressed as one.

The intention is to:

1. Remove the Alerting List and the content of the flyout when TLS is disabled and when xpack.encryptedSavedObjects.encryptionKey isn't set.
2. Display a banner when xpack.encryptedSavedObjects.encryptionKey isn't set.

This means we need to figure out the copy for the banner in (2), and it's important to note that it's quite likely users will have both banners displayed at the same time.

For example, if a user on a non TLS Kibana starts a 30 day trial and navigates to the Alerting UI, it's very likely they don't have a value set for xpack.encryptedSavedObjects.encryptionKey, which means they will encounter both banners side by side.

So I guess the questions we need to answer next are:

1. What banner do we want to display when xpack.encryptedSavedObjects.encryptionKey isn't set. I guess this one is for @gchaps & @mdefazio ?
2. Do we want to merge these into a single banner when both need to be displayed? I guess this is more for @mdefazio and @snide ?

Any thoughts?

[andreadelrio]

I'm picking this up along with #62595 (there's context in that issue) as we feel they can be addressed as one.

The intention is to:

1. Remove the Alerting List and the content of the flyout when TLS is disabled and when xpack.encryptedSavedObjects.encryptionKey isn't set.
2. Display a banner when xpack.encryptedSavedObjects.encryptionKey isn't set.

This means we need to figure out the copy for the banner in (2), and it's important to note that it's quite likely users will have both banners displayed at the same time.

For example, if a user on a non TLS Kibana starts a 30 day trial and navigates to the Alerting UI, it's very likely they don't have a value set for xpack.encryptedSavedObjects.encryptionKey, which means they will encounter both banners side by side.

So I guess the questions we need to answer next are:

1. What banner do we want to display when xpack.encryptedSavedObjects.encryptionKey isn't set. I guess this one is for @gchaps & @mdefazio ?
2. Do we want to merge these into a single banner when both need to be displayed? I guess this is more for @mdefazio and @snide ?

Any thoughts?

What if instead of showing (another) banner we use the empty prompt for instructing the users to enable TLS? Something like this (copy is a placeholder only)

cc @mdefazio

[gmmorris]

Oh, we could definitely replace the Banner with that from my perspective. 🤷‍♂

We'd still need additional copy for the encryptionKey issue.

It's also worth noting that the CTA (Enable TLS) only applies to the TLS issue, it doesn't apply to the encryptionKey which requires adding a keystore or configuring their _kibana.yml_.
For the later we'd want to link to the Alerting docs I think, here: https://www.elastic.co/guide/en/kibana/7.7/alerting-getting-started.html#alerting-setup-prerequisites or https://www.elastic.co/guide/en/kibana/7.7/alert-action-settings-kb.html

[andreadelrio]

Oh, we could definitely replace the Banner with that from my perspective. 🤷‍♂

We'd still need additional copy for the encryptionKey issue.

It's also worth noting that the CTA (Enable TLS) only applies to the TLS issue, it doesn't apply to the encryptionKey which requires adding a keystore or configuring their _kibana.yml_.
For the later we'd want to link to the Alerting docs I think, here: https://www.elastic.co/guide/en/kibana/7.7/alerting-getting-started.html#alerting-setup-prerequisites or https://www.elastic.co/guide/en/kibana/7.7/alert-action-settings-kb.html

@gmmorris I talked with @mdefazio about this. The general direction where we'd like to take this is to use an empty prompt for both the management page and the flyout. Ideally this empty prompt would be "universal" and cover both TLS and the encryption key but we're not sure what that means in terms of copy/layout yet. We'll explore some options and share them with you asap.

[andreadelrio]

@gmmorris Follow up on the above. We'll be having three different scenarios for the empty prompt:

1) Needs to enable TLS only
2) Needs to set encryptionKey only
3) Needs both TLS and encryptionKey - copy on this one should be more generic and refer to setup and prerequisites for alerting. Maybe link to this?

Some screenshots below for reference. I'll work with @gchaps on the copy tomorrow.

[gmmorris]

@andreadelrio that's perfect, thanks 👍

[gmmorris]

Hi all,
moving this into the empty prompt has one edge case to it- what do we do if there are already Alerts / Connectors in the system?

We now support preconfigured Connectors, so the Connectors list might not be empty in a fresh installation (I believe this will always be the case in Cloud, but @YulNaumenko would know more).
In addition, it _is_ possible, though unlikely, that a Kibana installation had TLS and/or an encryptionKey configured and then had these removed. In such a case we might have several Alerts / Connectors in the table and still need to display the warning.
Previously this wasn't an issue, as the callout appears in addition to the table, but now it is supposed to be displayed instead.

Should we only render the list of Alerts / Connectors if the system is healthy? Should we render both the list and the security CTA?

I'm assuming the former, meaning, we'll only render the alert/connector lists when the system is healthy with both TLS and Encryption Key. Please let me know if I've assumed incorrectly. 😬 😆

[gmmorris]

This is now done in https://github.com/elastic/kibana/pull/62772 and I'm just waiting on the copy 😄

The list now displays the Alert/Connectors list as per the design @andreadelrio posted, and as you can see in the screens below, this is how the flyout now looks for the 3 cases:

[mdefazio]

@gmmorris Are the screenshots above for the edge case you mentioned where there could already be alerts (preconfigured or otherwise) in the list? Her comment was about using the empty state for _both_ the main screen and the flyout—so we don't have a flyout with just a single callout at the top.

[gmmorris]

@gmmorris Are the screenshots above for the edge case you mentioned where there could already be alerts (preconfigured or otherwise) in the list? Her comment was about using the empty state for _both_ the main screen and the flyout—so we don't have a flyout with just a single callout at the top.

Gotcha, will do.
I'll try it out and post screenshots of what it looks like.

[gmmorris]

Here is what it looks like using the same prompt - actually looks ok, but I'll look into whether we can align the content a little higher on the page. Vertical middle feels too low on a screen wide flyout (unless you feel otherwise?)

[gmmorris]

@mdefazio Would using the same prompt in both mean the copy is the same in both places? 🤔

[mdefazio]

@mdefazio Would using the same prompt in both mean the copy is the same in both places? 🤔

I think that make sense.

[gmmorris]

Updated alignment so just waiting for copy now 👍

[cchaos]

Just to jump in here regarding the copy. What is TLS? Is there any way to explain this in the empty state even if it's just spelling out the acronym? It just reads super technical and I know I would then shy away from clicking the link because I wouldn't know what I'd be enabling.

[gchaps]

Just discussed the text with @mdefazio. Here are some suggestions:

TLS

You must enable Transport Layer Security to create an alert
Alerting relies on API keys, which require TLS between Elasticsearch and Kibana. Learn how to enable TLS.

Encryption key

You must set an encryption key to create an alert
Set a value for xpack.encrypted_saved_objects.encryptionKey in your kibana.yml file. Learn how.

Generic

Additional setup required
You must enable Transport Layer Security between Kibana and Elasticsearch and configure an encryption key in your kibana.yml file. Learn how.

[gmmorris]

@andreadelrio @mdefazio any advice what parts of the copy should be the link?
I'm thinking the "Learn how to enable TLS." / " Learn how." / " Learn how." in each of the 3 options accordingly.

Perhaps all 3 should just be "Learn how"?

[mdefazio]

I'm thinking the "Learn how to enable TLS." / " Learn how." / " Learn how." in each of the 3 options accordingly.

^^ Yes.

We discussed having them all read 'Learn how', but we think it makes more sense to have the TLS be slightly more specific.

We also need to make sure we have the external link icon after each of them.

[gmmorris]

[mdefazio]

Are the headings correct? Looks like they are duplicated

[gmmorris]

Wrong screenshot 🤦‍♂ updating

[andreadelrio]

@gmmorris these are looking good! thanks for making those changes. The header text for TLS / encryptionKey feel a bit too long for me but they're very clear so probably ok.

[gchaps]

@andreadelrio What do you think about removing "to create an alert" from the heading?

[andreadelrio]

@andreadelrio What do you think about removing "to create an alert" from the heading?

@gchaps I think that would work better. Can we move the "to create an alert" bit to the text below if we do that? I would just like to make it very clear to the user that this is needed in order to create an alert.

[gchaps]

I think it's clear in the TLS one that it's needed to create an alert because the description starts with Alerting.

@andreadelrio, @mdefazio What about these suggestions:

You must enable Transport Layer Security
Alerting relies on API keys, which require TLS between Elasticsearch and Kibana. Learn how to enable TLS.

You must set an encryption key
To create an alert, set a value for xpack.encrypted_saved_objects.encryptionKey in your kibana.yml file. Learn how.

[andreadelrio]

I think it's clear in the TLS one that it's needed to create an alert because the description starts with Alerting.

@andreadelrio, @mdefazio What about these suggestions:

You must enable Transport Layer Security
Alerting relies on API keys, which require TLS between Elasticsearch and Kibana. Learn how to enable TLS.

You must set an encryption key
To create an alert, set a value for xpack.encrypted_saved_objects.encryptionKey in your kibana.yml file. Learn how.

Agreed that nothing else is needed on the TLS one. I think the encryptionKey looks a lot better in this version.

[gmmorris]

Updated the copy 👍

[arisonl]

@gmmorris @mdefazio so how does the main view look in the edge-case when there are pre-existing alerts but TLS/SavedObjects configuration is needed?

[mdefazio]

In that scenario, is it the case where TLS would ever remain un-configured? If they need to update these settings, isn't this urgent? And so they need to fix it right away anyway—instead of being able to manage/view any existing alerts? Or is that a difficult ask for someone?

[gmmorris]

@gmmorris @mdefazio so how does the main view look in the edge-case when there are pre-existing alerts but TLS/SavedObjects configuration is needed?

Sorry, just saw this.
With these changes theAlerts list will only appear if TLS is fixed (which makes sense to me as you can't actually interact with the alerts (Add, and most Edit operations would fail anyway)