Kibana: Allow for cookie's `SameSite` attribute to be configurable

[legrego]

Currently, Kibana does not set the SameSite attribute on its session cookie. Up until recently, this was tolerable, but Chrome recently (version 80) updated its default configuration to treat unset SameSite attributes to mean Lax (https://www.chromestatus.com/feature/5088147346030592).

This is problematic for users who embed Kibana in an iframe. We should allow the SameSite setting to be configurable via kibana.yml, so users can choose if they want Strict, Lax, or None.

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

Seing https://github.com/hapijs/hapi/issues/3987,

Unfortunately this breaks some not that old browsers including Safari 12 and Chrome 67, so I suspect it needs to be set or not based on the User-Agent header of the request

it seems we will need to only set this header when the user's browser supports it?

[legrego]

Seing hapijs/hapi#3987,

Unfortunately this breaks some not that old browsers including Safari 12 and Chrome 67, so I suspect it needs to be set or not based on the User-Agent header of the request

it seems we will need to only set this header when the user's browser supports it?

That depends. According to our support matrix, we only support the latest GA version of each browser listed. We support both Chrome and Safari, but both of their latest versions appear to support SameSite=None.

If this was a configurable value (defaulting to unset like today), then users can opt-in to a different behavior if they wish to, but at that point, it's up to each user to decide how they want to configure their cookies.

I think we should discuss changing our default to Lax in the future - perhaps as a breaking change in 8.0.

[patodevilla]

Is there a solution for kibana on elastic cloud?

[rowan-m]

You may want to consider backporting or documenting some kind of proxy solution for existing users. This change is currently rolling out in Chrome stable which will mean any of your users with a cross-site iframe embed for their dashboard will not be able to access it.

[SpencerTranter]

This definitely threw us through a loop. Would be great to have some proxy documentation to get around this for new Kibana developers :)

[restrry]

You may want to consider backporting or documenting some kind of proxy solution for existing users.

@legrego Does the Security team have the capacity to work on documentation?

That depends. According to our support matrix, we only support the latest GA version of each browser listed. We support both Chrome and Safari, but both of their latest versions appear to support SameSite=None.

@joshdover What is the earliest release we can work on this? I suppose v7.9, providing we document a workaround with proxy.

[joshdover]

@joshdover What is the earliest release we can work on this? I suppose v7.9, providing we document a workaround with proxy.

Yeah 7.8 is pretty full for us. Do we have an idea of how difficult of a fix this is?

[joshdover]

We've decided to go ahead and fix this and maybe make it configurable (opt-in) to ensure we don't break older browser support (esp. IE11).

We will backport this to 7.7 with @LeeDr's blessing.

[restrry]

can be postponed by 7.8-7.9 https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

[sergibondarenko]

@restrry @joshdover

We should allow the SameSite setting to be configurable via kibana.yml, so users can choose if they want Strict, Lax, or None

If you provide a service that other sites consume such as widgets, embedded content, affiliate programs, advertising, or sign-in across multiple sites then you should use None to ensure your intent is clear.

To make Kibana work in an iframe on a 3rd party website we will need to set cookies like this Set-Cookie: key=value; SameSite=None; Secure. Kibana is still using hapi v17 webserver to run itself on a host. And hapi introduced support for SameSite=None in v19.0.0. Here is the related commit to the hapi state plugin. Thus hapi server must be upgraded in order to use SameSite=None.

[kobelb]

Is the current plan to introduce a setting to configure the SameSite attribute, but default it to being unset?

[legrego]

Is the current plan to introduce a setting to configure the SameSite attribute, but default it to being unset?

We can, but without the Hapi upgrade, I don't think it'll solve the embeddable problem with Chrome, as it doesn't appear we can set the value to None unless we manage to patch our version of Hapi to add support for this.

My understanding is that the Hapi upgrade is at least soft-blocked on removal of the Legacy Platform. @watson experimented with an upgrade to 18.4.1 in https://github.com/elastic/kibana/pull/61959, but put it on hold due to complications with legacy plugins. The subsequent move from 18 to 19 (or just straight to 19) has an unknown level of effort at this point.

[restrry]

We can, but without the Hapi upgrade, I don't think it'll solve the embeddable problem with Chrome,

There a couple of options:

• to patch existing Hapi version. For example, there was a workaround for v18. We can make it work for v17 as well https://github.com/hapijs/hapi/issues/3987#issuecomment-575061467
• to update the Hapi version. There are just a few plugins with the server-side left. I can take a look at https://github.com/elastic/kibana/pull/61959 If I can timebox the version update ~2 days, I'd go this way.

As a note: Chrome resumed the Same Site cookie changes in July. It means we must fix the issue in 7.9 and it cannot wait for the plugins to finish migration (https://github.com/elastic/kibana/issues/56205 targeted v7.10) https://blog.chromium.org/2020/05/resuming-samesite-cookie-changes-in-july.html

[restrry]

The solution depends on how deep we are going to backport the fix. Hapi version update we can backport to v7.7 at best.