Provide sensible defaults for xpack.security.session.{lifespan|idleTimeout}.
#106061
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
azasypkin
added
release_note:breaking
Team:Security
|
Pinging @elastic/kibana-security (Team:Security) |
thomheymann
reviewed
Jul 19, 2021
There was a problem hiding this comment.
Looks good code wise but is an hour maybe a little too aggressive for idle timeout?
Imagine having to log into e.g. Gmail every time you don't use it for an hour. Sounds a bit annoying as default.
I would bring idle timeout and lifespan closer together so that customers using Kibana on a daily basis don't have to login all the time but also avoid having super long running sessions.
idleTimeout: 1d
lifespan: 7d
What do you think?
Well, we went back and forth on these values and decided to be as close to NIST/ENISA guidelines as possible. Our values is a compromise between industry standards and usability and, actually, even a bit less aggressive than what these standards suggest. Do you think we missed something important in this discussion - #68885? I'm not opposed to reconsidering this though, but I'd better stick to what we already agreed on and see how it's perceived by the Kibana devs first (not quite a representative group, but still we're active Kibana users) - we have a reasonable amount of time before 8.0 GA to get enough feedback and pivot if people aren't happy. |
jportner
reviewed
Jul 19, 2021
Ah great, thanks for linking to the original issue. The guidelines seem to say:
Governments institutions with high security requirements will configure these settings manually irregardless of whether we're providing a default or not. I think the default is for those who wouldn't otherwise do so and a 1 hour inactivity idle time makes it pretty unusable / frustrating experience. I think not having an inactivity timeout and instead specifying a reasonable lifespan might actually be a sensible approach here following the guidelines for low security baseline. |
@thomheymann I'm curious to know why you think an idle timeout of 1 hour is pretty unusable and frustrating? We've/you've done a lot of work to make the idle timeout based on client side activity and thus pretty seamless. If the user does get logged out, they get redirected back to where they were (granted if they were doing something like editing a role, their changes would not have been saved -- but I think if you're going to walk away or otherwise background a window for 1 hour in the middle of what you were doing, you probably wouldn't stop in the middle of something important). There are two main reasons for setting an idle timeout:
I personally think 1 hour strikes a good balance between usability and security. It's not too aggressive, but it does provide protection in these cases. With both the idle timeout and the lifespan set, the lifespan is basically a fall-back in case a session does get stolen by an attacker, they can't use it indefinitely. The sad truth is, a lot of system administrators won't ever think about or define security settings like this, but IMO we should do all we can to nudge them towards a more secure setup out-of-the-box. If they find it frustrating they can always extend the idle timeout or disable it! |
I was thinking about a situation where you have 5 tabs open with different visualisations and dashboards and then having to log in or refresh each and every one of them after your lunch break because we kicked you out after an hour. I don't think that would be a good user experience and I don't think that level of security will be justified for the majority of use cases. It's obviously hard to say since customers can store pretty much anything in Elasticsearch and some use cases will require more aggressive timeout policies. I'm not sure if that should be the default though. e.g. Compare this to Gmail and Github which don't log you out that quickly. |
Okay, that's a fair point. And that's not just limited to a lunch break either. If you got up for a long meeting, as long as you didn't set your dashboard to auto-refresh, the same thing would happen. But that's largely the point of the idle timeout 😄 What I'm really hearing is that we have too much friction in our UX for re-authentication when it comes to users who have multiple tabs. Do you think something like that would alleviate your concerns? Edit: opened ER for this in case we decide to implement it #106235
Fair point, but I don't think we are comparing apples to apples here, and in general I think whataboutism often isn't a good argument when it comes to security controls (or lack thereof!) |
Well, we never know until we try, it'd not hurt to add a bit telemetry around session settings to have some data to support our decisions in the future. I see both types of SDHs - the ones where users want to increase idle timeout and the ones where they want to decrease it, don't really see a single pattern there. I also investigated how our ESS User console behaves, it seems its session expires after 2 hours of inactivity ( ESS is not something we should be aligned to (I'd rather say it should be vice versa), just gathering more info on the topic. Having said, it'd be nice if we can decide by EOD today so that changes are included into 8.0.0 alpha1. |
|
I empathize with @thomheymann's position -- if Kibana was a central aspect of my job (oh, wait... 😄), then I would get really annoyed if my sessions expired after a single meeting or over a lunch break -- this could happen several times a day based on my schedule, which breaks my flow even more.] If I'm just viewing a dashboard, then this isn't the end of the world, but (for example) it takes me a while to author a visualization, so it's very possible that I'll work on that piecemeal over the course of a day, as time permits. If my session expires, then I may lose whatever progress I've made along the way. This gets back to Joe's comment about having too much friction in our re-auth flow, but I think more generally it comes down to different apps remembering transient state, which is a tricky problem to get right. I also think that our upcoming collaboration features could be frustrating to use with a small timeout window as well. I frequently start GitHub comments / issue descriptions, and leave them in the background if I get pulled away into something else (sometimes for days). I could easily see a similarly distracted Kibana user trying to work on a Security Solution Case in their spare time, but they keep losing their progress because of session expiration. This is again a problem of transient state, but I feel like we should consider the entire user experience of our proposal. Having said all of that, we are not enforcing a session timeout here, but rather suggesting a "sensible default" so that your installation is secure out-of-the-box. One of the goals of the alpha and beta releases is to collect feedback on our proposed changes to the next major release. If we find that this introduces too much friction, then we still have an opportunity to make changes before we go GA. To that end, I agree with @azasypkin that we should introduce telemetry in both 8.0 and 7.x to determine how our users configure session timeouts today, and how many choose to change the defaults in the future once we GA our new defaults, whatever they may be. |
legrego
reviewed
Jul 20, 2021
Yep, definitely! |
|
Okay, let's move forward, thanks everyone for feedback! I'll drop a larger Kibana team a note about this change and ask to come to us if the change makes their lives harder. |
💔 Build Failed
Failed CI StepsTest FailuresKibana Pipeline / general / Chrome UI Functional Tests.test/functional/apps/visualize/_vega_chart·ts.visualize app visualize ciGroup12 vega chart in visualize app vega chart initial render should have view and control containersStandard OutStack TraceKibana Pipeline / general / Chrome UI Functional Tests.test/functional/apps/visualize/_vega_chart·ts.visualize app visualize ciGroup12 vega chart in visualize app vega chart initial render should have view and control containersStandard OutStack TraceMetrics [docs]
History
To update your PR or re-run it, just comment with: |
|
Can you please help us to review two deprecation messages (for This is what we have today:
I was also considering something like this (almost the same, but we indicate the new default value right in the list view), but not sure if it brings any value:
Tnanks! |
|
@debadair and I chatted. Adding. the new value to the title is a good idea. Here is a suggestion for adding more context in the description snd eliminating the link. First deprecation"xpack.security.session.idleTimeout" is now 1 hour User sessions will automatically time out after 1 hour of inactivitiy starting in 8.0. Override this value to change the timeout. Fix manually
Second deprecation"xpack.security.session.lifespan" is now 30 days Users are automatically required to log in again after 30 days starting in 8.0. Override this value to change the timeout. Fix manually
|
Looks great, thank you! I'll prepare a PR to make these changes today. |
This was referenced Oct 14, 2021
KOTungseth
added a commit
to KOTungseth/kibana
that referenced
this pull request
Nov 1, 2021
KOTungseth
added a commit
that referenced
this pull request
Nov 1, 2021
KOTungseth
added a commit
to KOTungseth/kibana
that referenced
this pull request
Nov 1, 2021
KOTungseth
added a commit
that referenced
this pull request
Nov 3, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR changes default values for the session timeout settings. You can find more details on the decision in #68885
New defaults:
xpack.security.session.idleTimeout: 8h(we initially picked1h, but bumped it to8hin the follow-up Change default session idle timeout to 8 hours. #115565)xpack.security.session.lifespan: 30dDocs preview link: https://kibana_106061.docs-preview.app.elstc.co/diff
Fixes: #68885
Release note
We are enabling session expiration timeouts by default in Kibana: session idle or inactivity timeout is set to 8 hours, and session maximum lifespan is set to 30 days. Refer to
Session managementdocumentation for more info.