Closes#154252
## Summary
This PR implements a default [permissions policy
header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy)
for Kibana. It takes into consideration only the directives that are
_not_ still in development/pre-release. These directives are:
- camera
- display-capture
- fullscreen
- geolocation
- microphone
- web-share
All directives above are set to an empty or "none" allow list, with the
exception of `fullscreen`. The default permissions policy for Kibana
will be: `camera=(), display-capture=(), fullscreen=(self),
geolocation=(), microphone=(), web-share=()`.
The `display-capture` directive only affects access to the [Screen
capture
API](https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capture_API),
whereas our reporting utilities rely on a headless Chrome feature.
FullyStory also does not appear to rely on capturing the screen, but
rather on [capturing the DOM and
CSS](3600206230-Does-FullStory-work-with-my-complex-site-)
to reproduce the screen and user stories. We have confirmed with
FullStory support that they do not use the Screen capture API
(`getDisplayMedia()`).
The `fullscreen` directive affects access to the
[element.requestFullscreen
API](https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen).
Our fullscreen view for Dashboards and visualizations appear to be
scoped to the Kibana application and not the browser or system, but
there is one use of `requestFullscreen` in the synthetics plugin's
`grid_group_item`, hence the default setting of 'self' here.
## Testing
Due to screen capture reports (PNG & PDF) and fullscreen modes working
with the configuration defined above, I wanted to double-check the
header was working, so I tested both camera and microphone access. I did
this by adding some code into our team's user management screen that
would attempt to access both the camera and microphone. I could confirm
that with the permissions policy header (as defined), no access prompts
would appear for either resource. When I removed the directives for the
camera and microphone from the permissions policy header, prompts
appeared in the browser (Chrome) to approve access to the camera and
microphone.
### Manual Test:
1. Start Elasticsearch and Kibana from this PR
2. Sign into Kibana and open your browser's dev tools
3. In the network tab, inspect one of the requests for localhost
4. In the Headers tab, verify the permissions-policy header is present
with the new default value defined above, `camera=(),
display-capture=(), fullscreen=(self), geolocation=(), microphone=(),
web-share=()`
5. Edit the kibana.yml file, add
`server.securityResponseHeaders.permissionsPolicy: camera=(self)`
6. Refresh Kibana in the browser, verify the permissions-policy header
is present with the value set in kibana.yml in step 5
7. Edit the kibana.yml file, add
`server.securityResponseHeaders.permissionsPolicy: null`
8. Refresh Kibana in the browser, verify the permissions-policy header
is no longer present
## Release Notes:
Security
Adds default Permissions-Policy header including all non-experimental
directives [#158514](https://github.com/elastic/kibana/pull/158514)
---------
Co-authored-by: James Rodewig <james.rodewig@elastic.co>
This PR adds the new configuration settings to the docs. The
configurations were added in this PR:
https://github.com/elastic/kibana/pull/154013
---------
Co-authored-by: lcawl <lcawley@elastic.co>
This change ensures that the `unsafe-eval` source expression isn't included in
the Kibana Content Security Policy (CSP) by default.
Users can set `csp.disableUnsafeEval: false` to reintroduce `unsafe-eval`.
However, since this config option is deprecated as of this commit, it's
recommended to instead set `csp.script_src: ['unsafe-eval']`.
Closes#150156
Part of #141780
## Release notes
Include Cross-Origin-Opener-Policy in default response headers
## Testing
Load Kibana; you should see Kibana respond with
`Cross-Origin-Opener-Policy: same-origin` header for page loads and API
requests.
* Use brotli compression
* [CI] Auto-commit changed files from 'node scripts/eslint --no-cache --fix'
* Add integration test for brotli support
* Use import instead of require()
* Suppress build error on importing brok
* [CI] Auto-commit changed files from 'node scripts/precommit_hook.js --ref HEAD~1..HEAD --fix'
* add brok as explicit package dep
* add `server.compression.brotli` config settings
* update documentation
* fix test utils
* fix more test configs
* add tests for endpoints too
* remove against endpoint for now
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: pgayvallet <pierre.gayvallet@elastic.co>
This removes indication that the `server.publicBaseUrl` setting is supported on Elasticsearch Service. While the setting is technically available in ESS it's not configurable and it's best not documented.
Adds a new experimental Kibana setting called `csp.disableUnsafeEval` which will default to `false`. When set to `true`, it will remove `unsafe-eval` from our CSP.
Also introduces a new module called `@kbn/handlebars` which is a replacement for the official `handlebars` module used in the frontend. This new module is necessary in order to avoid calling `eval`/`new Function` from within `handlebars` which is not allowed once `unsafe-eval` is removed from our CSP.
The `@kbn/handlebars` module is simply an extension of the main `handlebars` module which adds a new compile function called `compileAST` (as an alternative to the regular `compile` function). This new function will not use code-generation from strings to compile the template but will instead generate an AST and return a render function with the same API as the function returned by the regular `compile` function.
This is a little bit slower method, but since this is only meant to be used client-side, the slowdown should not be an issue.
The following limitations exists when using `@kbn/handlebars`:
The Inline partials handlebars template feature is not supported.
Only the following compile options will be supported:
- `knownHelpers`
- `knownHelpersOnly`
- `strict`
- `assumeObjects`
- `noEscape`
- `data`
Only the following runtime options will be supported:
- `helpers`
- `blockParams`
- `data`
Closes#36311
The `server.uuid` setting MUST be a valid UUIDv4.
Also, the setting was added in the middle of other SSL settings and it was misleading (due to a banner related to SSL settings).
* Remove kibana.defaultAppId setting
* Fix typings
* Remove plugin dependency
* Use proper navigation method to get to home
* Default route for home
* Address discover new routing code
* Make non existing /kibana URLs working
* Fix space awareness
* Remove documentation
* Remove the setting from docker file
* Make defaultRoute forward work properly
* Add forward_url tests
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
* Fix logging for existing integration test
* First stab at limiting batches to batchSizeBytes
* Fix tests
* Fix batch size calculation, NDJSON needs to be terminated by an empty line
* Integration tests
* Fix type failures
* rename migration integration tests and log files to be consistent & more descriptive
* Review feedback
* Remove duplication of fatal error reasons
* migrations.maxBatchSizeBytes to docker environment vars
* docs for migrations.maxBatchSizeBytes
* [DOCS] Creates separate doc for security in production
* Use Kibana attribute
* Update CSP section
* Move SSL section to the top
This is the highest priority item for securing a production installation
of Kibana.
* Add section on using secure HTTP headers
* Write intro
* [DOCS] Fixes broken link and other minor edits
* [DOCS] Changes man to manipulator
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Joe Portner <5295965+jportner@users.noreply.github.com>
