Alert users when authentication features are not enabled

[legrego]

Kibana should alert users when it isn't configured to use stack authentication features.
Kibana should also inform users of the OSS distribution that free authentication features are available with the default distribution.

This alert should be prominently displayed, but dismissible by the current user for the duration of their session.

We should also allow this alert to be disabled altogether via configuration setting in kibana.yml for administrators who wish to intentionally run an unsecure cluster.

Background

There are clusters that don't have security enabled, even if they are in production mode and so reachable by other hosts. These clusters are potentially giving access to anyone, with high risk of data leaks.
We want raise awareness to users, and minimize the scenarios where unsecured clusters are not intentionally exposed.

TL;DR

Summary of this conversation is here: #73929 (comment)

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[ryankeairns]

Given the sensitivity, this prominent location feels suitable. Perhaps it doesn't need to be an error style, but rather a caution/info (yellow/blue). With regards to the top header location, we could revisit this positioning (and desired emphasis) once we have a notifications UI up there.

[alexfrancoeur]

Dropping in some thoughts and questions around UI/UX . When @arisonl is back we can fine tune the requirements and scope. We don't need to address all of the questions below in the first iteration, but it'll be good to know where we want to go.

• When do we we want to show this? After a trial? After a certain amount of time? Does data need to be in the cluster to trigger?
• What should the upgrade experience be like? Do we show this warning every time they upgrade?
• Who sees this notice? Admins only? Roles with certain permissions? Everyone?
• What does it mean to dismiss the banner? Is it stored locally in cache? Is it dismissed for the whole space?
• Should we offer a way to disabled this banner via config? (probably yes as Larry suggested)
• Should this be an error banner, an info banner, warning?
• What's the call to action, do we bring them to the docs?
• Should we capture telemetry on this banner and behavior?
• Should we provide this banner to OSS users? And if so, what should we show them?

[legrego]

@arisonl @alexfrancoeur @VijayDoshi @joshbressers @aravindputrevu @elastic/kibana-security:

👋 Hey folks! I was going to make this a meeting, but this is a hard group to schedule, so I think starting this as an async discussion would be easier. We have a sync on Wednesday September 23rd at 8:00am ET that you are all welcome to attend (find it on the Kibana Cal), but I think we can handle most if not all of the feedback directly in this issue.

Our goal is to have a version of this alert in the 7.10 release, so I am looking to solicit feedback this week, with a cutoff of Thursday, September 24th so that we have time to finish implementation.

The @elastic/kibana-security team has been meeting to discuss the available ux options. I'm going to attempt to distill those conversations down to a few points that we can collaborate on as a larger group. I will not attempt to present all of our ideas, but I rather want to focus on the two "main" concepts that we explored, and our current preference.

Option 1: Dismissible Banner

The original idea was to display a banner at the top of the home page (or possibly at the top of all pages) to warn users that their installation was not secure. This is not the final design, but something similar to:

This banner would be dismissible by the current user for the duration of their session (via cookies, session storage, etc).

Administrators would also be able to configure Kibana (via kibana.yml) to not display this warning. This is useful for setups that are protected by a reverse-proxy, or for setups where they're willing to accept the risk of running without security.

Pros

1. A banner is hard to miss
2. The banner is easy to implement

Cons

1. A banner is easy to dismiss. It "gets in the way" of users doing their jobs, so they are incentivized to get it out of their way as quickly as possible.
2. This banner would be displayed in the same location as the Telemetry Notification that appears on startup. Having two banners displayed creates a lot of noise in the UI, and creates a further incentive to dismiss all alerts without reading them. If everything is important, then nothing is. We considered waiting to display the security banner until after the telemetry banner has been dismissed, but then the question becomes: "How long do we wait?". If we wait too long, we risk the administrator missing it (if they've since moved on to other tasks). It would also be strange if the alert suddenly appeared after an arbitrary delay, while users are already actively using Kibana.

Option 2: Persistent Navigation Control

When security is enabled, we display the user's avatar in the top-right corner of Kibana:

When security is not enabled, then we don't render anything there. We could use this location to instead show our alert. Here is a rough mockup to illustrate what this could look like:

Pros

1. The nav control is out of the way, so we don't have to offer a way for users to dismiss this via the UI (a kibana.yml setting would still be offered).
2. Since the nav control can't be dismissed like the banner, we will have a persistent notification available to educate our users about our free security features. It also won't interfere with their work, so users won't be dismissing a banner to get the visual noise out of their way.

Cons

1. The nav control isn't as obvious as the banner. One way to mitigate this would be to show the popover contents automatically after the telemetry banner has been dismissed.

Personal preference

As of now, my personal preference is Option 2: Persistent Navigation Control. This approach alleviates the question of when to show this warning -- it's unintrusive enough to always be displayed, unless configured via kibana.yml to remain hidden.

Other thoughts

Here's my thinking on the questions @alexfrancoeur posed:

When do we we want to show this? After a trial? After a certain amount of time? Does data need to be in the cluster to trigger?

If we use Option 2, then I think we can show this all of the time.

What should the upgrade experience be like? Do we show this warning every time they upgrade?

If we use Option 2, then I don't think the upgrade experience will have an impact. It will always be visible unless disabled via kibana.yml.

Who sees this notice? Admins only? Roles with certain permissions? Everyone?

Since security is not enabled, we don't have the concept of a user, admin, or roles. Therefore, I think we have to show this to everyone.

What does it mean to dismiss the banner? Is it stored locally in cache? Is it dismissed for the whole space?

If we take the banner approach, my thinking is to dismiss locally in cache for the current browser session.

Should this be an error banner, an info banner, warning?

My thinking is somewhere in between warning and info. I couldn't decide, so you'll notice my mockup for option 2 reflects both...

What's the call to action, do we bring them to the docs?

This is my thinking for the initial version. We can expand this behavior in the future.

Should we capture telemetry on this banner and behavior?

Yeah I think this would be a good idea.

Should we provide this banner to OSS users? And if so, what should we show them?

Yes, I think we need messaging for OSS users too. Instead of telling them to enable security features, we could instead tell them that the default distribution comes with free security features, and link them to the downloads page.

[joshbressers]

I agree 100% with everything @legrego wrote above.

The only suggestion I have is we should copy the chrome browser behavior as it is known to people

Use a scary triangle and the friendly lock. I think there could be value in also showing positive feedback like "You appear to have security properly configured", but we can consider that a different discussion, what's been suggested will make a perfect MVP.

[VijayDoshi]

Option 2 seems noticeable enough and it is reasonable to show it to all users all of the time IMO. My only hesitation is during trial - do we want the first experience to immediately have a warning? This won't be an issue for cloud trials though since those are secure, so perhaps we are okay.

Providing an indicator that your cluster is secure seems useful - my only concern is making the UI more complicated.
I suggest adding something to the life ring dialog under version. " your cluster is secure" | " Not secure (link)>" This seems like a logical place to tuck this info into without adding a top-level UI element. I think that gets at what @joshbressers is wanting and provides an easy way for anyone to check at any time.

[alexfrancoeur]

I spoke with @snide about the onboarding point specifically, and his response leaned more towards a subtle toast notification that eventually is persisted in the notifications center. If we take this approach, it ends up being a combination of 1 and 2, and almost phased accordingly. For the initial phase and MVP, we provide a concise, subtle and build-specific toast notification for when a cluster is not secure. This could show upon initial onboarding and on upgrade as a reminder. When we eventually add a notification center to the global header / nav (🤞 7.x), that notification will be persisted (and maybe even pinned?) there.

I like the idea of a security indicator as well. In addition to Vijay's suggestion, we might also be able to call out under management. Alternatively, we could show disabled security UI's under stack management in all builds.

[alexfrancoeur]

Hey @legrego and @arisonl, @VijayDoshi and I spoke earlier this afternoon around the approaches proposed and what would be the best way to implement without significantly impacting the onboarding experience for self-managed builds of Kibana. Please let us know what you think and if it's possible to introduce some or all of these requirements before FF. @snide if you have any additional comments on this approach related to onboarding, please let us know

• Toast notification
  • This toast will be made available to each user with two actions. Enable security or Dismiss (actual text tbd). The end user would need to take an action to get rid of the toast itself. Similar to the banner, and option 1 but a little less intrusive.
• Only show toast if data has been added that is not an internal index or sample data index.
  • This way new users are not presented with a warning / error feeling when opening up Kibana for the first time.
• Persist security state in the help menu / life ring with the current state and actions to enable security
  • This is similar to option 2
• When the notifications center is available, we can pin and persist this notification there
  • This is out of scope now as we have just started designing and creating requirements for the notification center
• This is probably out of scope for MVP, but we should start capturing telemetry on this to understand the conversion rate a bit better.
  • How many times was the toast presented, how many times was enable security or disable clicked, how many clusters actually enabled it, etc. This level of information will help us make more educated decisions in the future to see if we need to tweak and make this more obvious

[legrego]

Thanks all for the feedback so far!

@alexfrancoeur, @VijayDoshi, @snide -- here are my thoughts on the proposal for a toast notification:

This toast will be made available to each user with two actions. Enable security or Dismiss (actual text tbd). The end user would need to take an action to get rid of the toast itself. Similar to the banner, and option 1 but a little less intrusive.

This should be reasonable to address before FF. I'm not opposed to the toast, but I'm interested to know what benefits this option provides that the navigation control does not. Is the nav control too persistent? We were discussing the toast notification this morning, and our concern here was that it'd be really easy to dismiss this, and then promptly forget about it. The suggestions to mentioned below about persisting this in the help menu/notification center mitigate this, although likely not for the MVP.

Only show toast if data has been added that is not an internal index or sample data index.

This is probably doable, using the following heuristic:

1. indices that do not start with a .
2. indices that do not start with kibana_sample_

My concern here is having to enumerate all indices in the cluster. Large clusters could produce large payloads that the Kibana server would have to parse and process. We can cache this calculation, but we've seen instances where larger payloads end up crashing the Kibana server. This might not be a problem in practice, but I wanted to raise it.

Persist security state in the help menu / life ring with the current state and actions to enable security

The current help menu doesn't have extension points (yet) to allow plugins to inject content for all screens. The current model allows individual applications to inject their own custom support links, but we don't have a way yet to inject custom support for all applications.

This is certainly something we can address, but likely not in scope for FF.

When the notifications center is available, we can pin and persist this notification there

This is probably out of scope for MVP, but we should start capturing telemetry on this to understand the conversion rate a bit better.

Agree with both of the above -- not in scope for MVP, but worthwhile for us to do.

[snide]

but I'm interested to know what benefits this option provides that the navigation control does not. Is the nav control too persistent?

Actually you instincts are correct @legrego. It's more an issue of timing in design with other, similar initiatives. We have the concept of a "navigation center" coming in design within the next minor or two. Rather than do a custom implementation here that is just for this problem and adds another interface, I'd prefer we go with a less ideal, but generic (we deal with the IE security issue the same way, with a toast) solution till we get there. Hopefully that makes sense, but we're agreed this needs to be persistent.

Again just to consolidate the threads here:

1. Use a toast for now. It has the advantage of being easy to see on all pages, regardless of where they came in.
2. That means we don't double / triple up warnings with banners and compete with other similar ideas.
3. Design / @elastic/kibana-core-ui will have a notification "hey you need to address this" system that will handle this scenario. Assume that's a couple minors out, but on the near term horizon.

[legrego]

Thanks @snide, I appreciate the context. Unless there any objections, our goal will be to implement the following for FF:

• Toast notification

  • This toast will be made available to each user with two actions. Enable security or Dismiss (actual text tbd). The end user would need to take an action to get rid of the toast itself. Similar to the banner, and option 1 but a little less intrusive.

• Only show toast if data has been added that is not an internal index or sample data index.

  • This way new users are not presented with a warning / error feeling when opening up Kibana for the first time.

Dismissing the notification:

• Users can dismiss the notification. This will be remembered in either localStorage or sessionStorage (TBD)
• Administrators can turn off the notification via yml setting if they need to do so.

For the option to Enable Security, where would you like to send users? Is there an existing docs page that you all feel would make sense? I was thinking this page, but I'm interested to hear y'alls thoughts too.

[alexfrancoeur]

@snide given the additional work that would need to be done to check for non-internal and non-sample data indices, what are your thoughts on the impact of presenting this toast as one of the first things a new self managed user sees when opening Kibana? I ask because while it's not a Cloud flow, it does impact onboarding. Larry mentioned that it should be possible (potentially with some risk). It also raises the question around upgrade. If we build this logic in, we wouldn't be able to remind users that their cluster is not secure with each new release or would have to introduce more complex logic. We take a similar approach with telemetry opt-in right now.

For the option to Enable Security, where would you like to send users? Is there an existing docs page that you all feel would make sense? I was thinking this page, but I'm interested to hear y'alls thoughts too.

We'll probably need to huddle up with @gchaps and @arisonl on the language and endpoint to land on. I feel like we may want to take them to our website that show cases the features, presents Elastic the brand / company and links out to the documentation. This page looks like it might be the appropriate one: https://www.elastic.co/what-is/elastic-stack-security

[snide]

given the additional work that would need to be done to check for non-internal and non-sample data indices, what are your thoughts on the impact of presenting this toast as one of the first things a new self managed user sees when opening Kibana?

It's either important or it isn't. It sounds like we're saying it's important, so I think it's OK to let them know. Language is important. "Please add security" vs. "You stuff is broken" makes a big difference on perception of the default experience.

[gchaps]

We could use wording similar to what's on the web page that Alex pointed out:

Protect your data
Add our free security features to ensure the right people have the right access. Learn more.

Or something more similar to the screenshot above:

Please secure your installation
Our free security features can protect against unauthorized access. Learn more.

[arisonl]

To summarise (and add my two cents):

Short-term:

• Toast to all users. No data check. Ability to disable through yml.
• Message:

Protect your data. Basic security is free, easy to set up and will protect you against unauthorised access. Learn more

Post-MVP short-term:

• Data check to display if indices beyond the internal and sample exist, and only then display the toast.
• We produce simple dedicated, step-by-step guidance beyond the documentation and existing blogs. We may potentially be able to reuse some of the Elasticon material we are putting together, e.g. we have a secure your cluster in three simple steps section.

Mid term:

• Navigation control along the lines of what @legrego proposed in the context of the navigation center initiative.
• Security indication and progress indication via a security center. The navigation control to link to the security center.

How does this sound?

[legrego]

Toast to all users. No data check. Ability to disable through yml.

I have the data check implemented at this point, but I'm happy to remove it if others share my unfounded fear about payload sizes.

• Message:

Protect your data. Basic security is free, easy to set up and will protect you against unauthorised access. Learn more

Do you want the same message for both the OSS and Default distributions?

[gchaps]

Some minor edits to the message:

Protect your data. Basic security is free, easy to set up, and protects you against unauthorized access. Learn more.

If Protect your data is used as a title, then it doesn't require an ending period.

[alexfrancoeur]

Do you want the same message for both the OSS and Default distributions?

We'll want slightly different messaging for OSS. @arisonl, @gchaps and myself can put together some proposed text.