fix(security_response_headers): update Permissions-Policy default val…

[Ruby-rc]

Summary

Closes #204721

• Changed the fullscreen setting in the Permissions-Policy header from (self) to * to allow loading from this source.

export const ONBOARDING_VIDEO_SOURCE = '//play.vidyard.com/K6kKDBbP9SpXife9s2tHNP.html?';

• Since fullscreen is considered a relatively safe browser feature, the setting has been adjusted to allow all sources.

Screen recording after modification:

20241220-191850.mp4

[afharo]

/ci

[afharo]

@Ruby-rc, thank you for the contribution!

The changes LGTM. But before approving, I'd love it if @elastic/kibana-security could take a look.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: 18d6f88

Failed CI Steps

• Jest Tests #4
• Jest Tests #4
• FTR Configs #15
• FTR Configs #15
• FTR Configs #20
• FTR Configs #20
• FTR Configs #113
• FTR Configs #113

Test Failures

• [job] [logs] Jest Tests #4 / has defaults for config
• [job] [logs] Jest Tests #4 / has defaults for config
• [job] [logs] FTR Configs #15 / serverless common API security/response_headers API endpoint response contains default security headers
• [job] [logs] FTR Configs #20 / serverless common API security/response_headers API endpoint response contains default security headers
• [job] [logs] FTR Configs #113 / serverless common API security/response_headers API endpoint response contains default security headers
• [job] [logs] FTR Configs #15 / serverless common API security/response_headers API endpoint response contains default security headers
• [job] [logs] FTR Configs #113 / serverless common API security/response_headers API endpoint response contains default security headers
• [job] [logs] FTR Configs #20 / serverless common API security/response_headers API endpoint response contains default security headers

Metrics [docs]

✅ unchanged

History

[Ruby-rc]

@Ruby-rc, thank you for the contribution!

The changes LGTM. But before approving, I'd love it if @elastic/kibana-security could take a look.

Thank you! There are some uncertainties that need further discussion.

I’ve just noticed an issue with this commit — the property value was incorrect, and some test files were not updated.

I’ve made the necessary fixes and committed the changes again. However, I’m not sure if setting the fullscreen value to allow same-origin (self) and specific sources would be a better approach.

Additionally, I noticed that the docs/setup/settings.asciidoc file contains instructions on how to modify the Permissions-Policy. The exact approach for modifying it should be discussed further.

[[settings]]
== Configure {kib}

The {kib} server reads properties from the `kibana.yml` file on startup. The
location of this file differs depending on how you installed {kib}. For example,
if you installed {kib} from an archive distribution (`.tar.gz` or `.zip`), by
default it is in `$KIBANA_HOME/config`. By default, with package distributions
(Debian or RPM), it is in `/etc/kibana`.  The config directory can be changed via the
`KBN_PATH_CONF` environment variable:

[azasypkin]

Hey @Ruby-rc,

Thanks a lot for the contribution!

Changed the fullscreen setting in the Permissions-Policy header from (self) to * to allow loading from this source.
export const ONBOARDING_VIDEO_SOURCE = '//play.vidyard.com/K6kKDBbP9SpXife9s2tHNP.html?';

Is this the only video source you wanted to relax the fullscreen restriction for, or are there other sources you believe we need to support fullscreen mode for? I’m asking because switching from self to * is a somewhat significant change, even for fullscreen, and I’m wondering if this specific video is the sole reason behind it.

I’m also tagging @agusruidiazgd, who I believe added this link in https://github.com/elastic/kibana/pull/190696/files#diff-ac85eb4cd1c126a214648960cb92a88735f61adcac7972c8670bc338fca22b4fR20, to understand the expected lifetime of this link, whether we plan to add more, and if vidyard.com is our video hosting service of choice for stuff like this (e.g. to consider switching from self to self "*.vidyard.com" instead *).

[elena-shostak]

Requesting changes for this one per Oleg's comment

[Ruby-rc]

Hey @Ruby-rc,

Thanks a lot for the contribution!

Changed the fullscreen setting in the Permissions-Policy header from (self) to * to allow loading from this source.
export const ONBOARDING_VIDEO_SOURCE = '//play.vidyard.com/K6kKDBbP9SpXife9s2tHNP.html?';

Is this the only video source you wanted to relax the fullscreen restriction for, or are there other sources you believe we need to support fullscreen mode for? I’m asking because switching from self to * is a somewhat significant change, even for fullscreen, and I’m wondering if this specific video is the sole reason behind it.

I’m also tagging @agusruidiazgd, who I believe added this link in https://github.com/elastic/kibana/pull/190696/files#diff-ac85eb4cd1c126a214648960cb92a88735f61adcac7972c8670bc338fca22b4fR20, to understand the expected lifetime of this link, whether we plan to add more, and if vidyard.com is our video hosting service of choice for stuff like this (e.g. to consider switching from self to self "*.vidyard.com" instead *).

Thank you for your response. The reason I'm quoting the specific video URL is to discuss whether there's a more appropriate way to write the video source configuration, so we can optimize the setup.

I fully agree with your point, especially when considering the choice of video hosting service and the details of how to handle the fullscreen restriction.

[Ruby-rc]

Hey @elena-shostak

The changes have been made as per comment(sorry , I'm not entirely sure which one is Oleg's 🤔).

However, notice that the Permissions-Policy needs to explicitly specify the protocol, so I have added the specific domain names for both http and https.

[Ruby-rc]

@elasticmachine merge upstream

[Ruby-rc]

@azasypkin

Sorry, I didn't realize this might be a topic for discussion earlier. If the internal solution hasn't been decided yet, feel free to close my PR for now.

[azasypkin]

@azasypkin
Sorry, I didn't realize this might be a topic for discussion earlier. If the internal solution hasn't been decided yet, feel free to close my PR for now.

@Ruby-rc No need to apologize, and sorry that it might take a bit longer to resolve! You’ve found a valid bug and proposed a reasonable solution, we just need a bit more time to ensure we handle it the right way for the long term. Let’s keep your PR open for now until we hear from @agusruidiazgd and have had a chance to discuss this internally. It’s the holiday season, and many people are out, but we’ll get back to you as soon as we’ve discussed it with all stakeholders.

Thanks!

sorry , I'm not entirely sure which one is Oleg's 🤔

That's me (#205039 (comment)) 🙂

[agusruidiazgd]

Hi @Ruby-rc thanks for your contribution!
@azasypkin As far as I now this is the only video I found hosted by .vidyard.com, I will discuss with the team today about the reason of this and will come back with a bit more of context. I'm expecting to add more videos to this page so I'm wondering if we consistently will use .vidyard.com or should we change the host provider

[agusruidiazgd]

Hey @Ruby-rc @azasypkin this is a duplicate of #177777 (comment).
Check the last comment it's blocked by #181812. I would advise to close this one to avoid confusion since it is being discussed internally 😄

[Ruby-rc]

Hey @Ruby-rc @azasypkin this is a duplicate of #177777 (comment). Check the last comment it's blocked by #181812. I would advise to close this one to avoid confusion since it is being discussed internally 😄

Hi @agusruidiazgd, @azasypkin,

Thanks for your feedback and for pointing out the related discussions. After reviewing them, I think this PR might not fully address all the considerations currently being discussed.

To avoid confusion and keep things aligned with the team's direction, I’ll close this PR for now. Once the team reaches a conclusion, I’d be happy to revisit this if needed.

Thanks for your guidance!