## Summary
Fix https://github.com/elastic/kibana/issues/185042
- Add a new `elasticsearch.maxResponseSize` config option
- Set this value to `100mb` on our serverless configuration file
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/7104
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
*Note: by default, enabling `http2` requires a valid `h2c`
configuration, meaning that it can only run over HTTPS with TLS1.2+*
```yaml
## kibana.yaml
server.protocol: http2
server.ssl.enabled: true
server.ssl.key: path/to/key
server.ssl.certificate: path/my/cerf
```
## What is this PR doing
### Add HTTP2 support for the Kibana server
#### - Plug http2 to the Kibana server
Even if HAPI was never officially updated to really support HTTP2,
node's `http`/`https`/`http2` modules are compatible enough to be able
to just instantiate an http2 server/listener and provide it to HAPI "as
a plain https listener". There were some tweaks to do (mostly silencing
a few warnings that HAPI was causing by sending http2-illegal headers
such as `Connection`), but overall, it went smoothly.
#### - Add config validation
By default, Kibana will require a valid `h2c` configuration to accept
enabling `http2`. It means that TLS must be enabled and that TLS1.2+
should at least be in the list of supported SSL protocols
(`server.ssl.supportedProtocols`). Note that default value of this
setting includes TLS1.2 and 1.3.
#### - Add escape hatch to run `h2` without `h2c`
In some situations, it may be required to enable http2 without a valid
`h2c` configuration. Kibana supports it, by setting
`server.http2.allowUnsecure` to `true`.
(*Note, however, that if http2 is enabled without TLS, ALPN protocol
negotiation won't work, meaning that most http2 agents/clients will fail
connecting unless they're explictly configured to use http2.*)
### Add documentation about this new feature
#### - Update the user-facing doc about this new `server.protocol`
setting
Update the user-facing Kibana settings documentation to include this
`http.protocol` setting (and refer to `server.http2.allowUnsecure`)
**Note: this setting, and this feature, are considered as experimental**
### Adapt our dev tooling to support running Kibana with http2 enabled
#### - Add a `--http2` flag to the dev CLI
Enabling this flag will add the proper configuration settings to run
Kibana with `http2` enabled in an (almost) valid `h2c` configutation.
*Note: when using this flag, even if listening on the same port, the
Kibana server will be accessible over https, meaning that you need to
use https in your browser to access it. Aka `http://localhost:5601`
won't work, you need to use `https://localhost:5601`. Also, we're using
the self-signed dev certificates, meaning that you must go though the
scary warning of your browser*
#### - Implement an http2-compatible base-path proxy
The current base path proxy is based on `hapi` and `hapi/h2o2`. I tried
for a bunch hours trying to hack around to make it work with http2
proxying, but ultimately gave up and implemented a new version from
scratch.
Note that with some additional efforts, this new http2 basepath proxy
could probably fully replace the existing one and be used for both http1
and http2 traffic, but it's an optimization / refactoring that did not
feel required for this PR.
### Adapt the FTR to run suites against http2
#### - Add support to run FTR test suite against an h2c-enabled Kibana
Note that with ALPN, clients using http1 should be (and are) able to
communicate with http2 Kibana, given h2c/alpn allows protocol
negitiation. So adapting our FTR tooling was not really about making it
work with http2 (which worked out of the box), but making it work with
**the self signed certifcates we use for https on dev mode**
Note that I'm not a big fan of what I had to do, however, realistically
this was the only possible approach if we want to run arbitrary test
suites with TLS/HTTP2 enabled without massively changing our FTR setup.
Operations and QA, feel free to chime in there, as this is your
territory.
#### - Change some FTR test suites to run against an HTTP2-enabled
server
I added a quick `configureHTTP2` helper function to take any "final" FTR
suite config and mutate it to enable `http2`. I then enabled it on a few
suites locally, to make sure the suites were passing correctly.
I kept two suites running with http2 enabled:
- the `console` oss functional tests
- the `home` oss functional tests
We could possibly enable it for more, but we need to figure out what
kind of strategy we want on that matter (see below)
## What is this pull request NOT doing
#### - Making sure everything works when HTTP2 is enabled
I navigated the applications quite a bit, and did not see anything
broken, however I obviously wasn't able to do a full coverage. Also, the
self-signed certificate was a huge pain to detect issues really caused
by http2 compared to issues because the local setup isn't valid `h2c`.
In theory though (famous last words) anything not doing http/1.1
specific hacks such as bfetch should work fine with http2, given that
even if using non-http2 clients, ALPN should just allow to fallback to
http/1.x (this part was tested)
#### - Enabling HTTP2 by default
PR isn't doing it for obvious reasons.
#### - Enabling HTTP2 for all FTR suites
First of all, it's not that easy, because it requires adapting various
parts of the config (and even some var env...), and we don't have any
proper way to override config "at the end". For instance, if you add the
http2 config on a top level config (e.g. the oss functional one that is
reuse by the whole world - learned the hard way), it won't work because
higher-level configs redefined (and override) the `browser` part of the
config, loosing the settings added to run the browser in insecure mode.
Secondly, I'm not sure we really need to run that many suites with http2
enabled. I learned working on that PR that we only have like one suite
where https is enabled for the Kibana server, and I feel like it could
be fine to have the same for http2. In theory it's just a protocol
change, unless parts of our apps (e.g. bfetch) are doing things that are
specific to http/1.1, switching to http2 should be an implementation
detail.
But I'd love to get @elastic/kibana-operations and @elastic/appex-qa
opinion on that one, given they have more expertise than I do on that
area.
- Running performances tests
We should absolutely run perf testing between http/1.1 over https and
http/2, to make sure that it goes into the right directly (at least in
term of user perceived speed), but I did not do it in the scope of this
PR (and @dmlemeshko is on PTO so... 😅)
## Release Note
Add support for `http2` to the Kibana server. `http2` can be enabled by
setting `server.protocol: http2` in the Kibana config file.
Note: by default, enabling `http2` requires a valid `h2c` configuration,
meaning that it can only run over HTTPS with TLS1.2+
Please refer to the Kibana config documentation for more details.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This adds support a password protected keystore. The UX should match
other stack products.
Closes https://github.com/elastic/kibana/issues/21756.
```
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore create --password
A Kibana keystore already exists. Overwrite? [y/N] y
Enter new password for the kibana keystore (empty for no password): ********
Created Kibana keystore in /tmp/kibana-8.15.0-SNAPSHOT/config/kibana.keystore
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore add elasticsearch.username
Enter password for the kibana keystore: ********
Enter value for elasticsearch.username: *************
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore add elasticsearch.password
Enter password for the kibana keystore: ********
Enter value for elasticsearch.password: ********
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana
...
Enter password for the kibana keystore: ********
[2024-04-30T09:47:03.560-05:00][INFO ][root] Kibana is starting
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore has-passwd
Keystore is password-protected
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore show elasticsearch.username
Enter password for the kibana keystore: ********
kibana_system
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore remove elasticsearch.username
Enter password for the kibana keystore: ********
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore show elasticsearch.username
Enter password for the kibana keystore: ********
ERROR: Kibana keystore doesn't have requested key.
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% bin/kibana-keystore passwd
Enter password for the kibana keystore: ********
Enter new password for the kibana keystore (empty for no password):
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana-keystore has-passwd
Error: Keystore is not password protected
[jon@mbpkbn1]/tmp/kibana-8.15.0-SNAPSHOT% ./bin/kibana
...
[2024-04-30T09:49:03.220-05:00][INFO ][root] Kibana is starting
```
## Password input
Environment variable usage is not consistent across stack products. I
implemented `KBN_KEYSTORE_PASSWORD_FILE` and `KBN_KEYSTORE_PASSWORD` to
be used to avoid prompts. @elastic/kibana-security do you have any
thoughts?
- `LOGSTASH_KEYSTORE_PASS` -
https://www.elastic.co/guide/en/logstash/current/keystore.html#keystore-password
- `KEYSTORE_PASSWORD` -
https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html#docker-keystore-bind-mount
- `ES_KEYSTORE_PASSPHRASE_FILE` -
https://www.elastic.co/guide/en/elasticsearch/reference/current/rpm.html#rpm-running-systemd
- Beats discussion, unresolved:
https://github.com/elastic/beats/issues/5737
## Release note
Adds password support to the Kibana keystore.
## Summary
Fix https://github.com/elastic/kibana/issues/100854
### Release note
The Kibana configuration file now supports assigning default value for
environment variables, using the `${VAR_ENV:defaultValue}` syntax.
Update levels ordering
## Summary
The documentation is currently reporting a misleading information
https://www.elastic.co/guide/en/kibana/current/logging-configuration.html#log-level:
<img width="546" alt="image"
src="573f82c5-51f8-4e32-a85d-6895cc1b2041">
indeed the "maximum" should be off and the "minimum" should be all,
because:
>A log record will be logged by the logger if its level **(ed: its
refers to log)** is higher than or equal to the level of its logger.
Otherwise, the log record is ignored.
There is no value smaller than all that will result in all types of logs
being outputted.
### Checklist
Delete any items that are not applicable to this PR.
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
## Summary
1. Added `Content-Security-Policy-Report-Only` header.
2. Set `form-action` to `self` in reporting mode.
3. Created [visualization for report only CSP
violation](f6bb1300-0bb7-11ee-adde-d5df298171dd?_g=(filters:!(),refreshInterval:(pause:!t,value:60000),time:(from:'2024-04-03T22:00:00.000Z',to:'2024-04-05T21:30:00.000Z'))).
Generated a couple of reports for testing, here is [telemetry
data](https://stack-telemetry.elastic.dev/s/kibana-platform-security/app/discover#/?_g=(filters:!(),time:(from:now-24h%2Fh,to:now))&_a=(columns:!(timestamp),filters:!(('$state':(store:appState),meta:(alias:'Expected%20CSP%20violation',disabled:!f,index:'14413084-88e4-4fd4-82ba-a69c8b72ec95',negate:!t,params:!((meta:(alias:!n,disabled:!f,field:effectiveDirective,index:'14413084-88e4-4fd4-82ba-a69c8b72ec95',key:effectiveDirective,negate:!f,params:(query:script-src-elem),type:phrase),query:(match_phrase:(effectiveDirective:script-src-elem))),(meta:(alias:!n,disabled:!f,field:blockedURL,index:'14413084-88e4-4fd4-82ba-a69c8b72ec95',key:blockedURL,negate:!f,params:(query:inline),type:phrase),query:(match_phrase:(blockedURL:inline))),('$state':(store:appState),meta:(alias:!n,disabled:!f,field:lineNumber,index:'14413084-88e4-4fd4-82ba-a69c8b72ec95',key:lineNumber,negate:!f,params:(query:'286'),type:phrase),query:(match_phrase:(lineNumber:'286')))),relation:AND,type:combined),query:())),index:'14413084-88e4-4fd4-82ba-a69c8b72ec95',interval:auto,query:(language:kuery,query:'disposition%20:%20%22report%22%20'),sort:!(!(timestamp,desc)))).
4. Added `csp.report_only.form_action` field for additional csp policy
configuration.
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
__Fixes: https://github.com/elastic/kibana/issues/179220__
## Release note
Added `Content-Security-Policy-Report-Only` header support.
Closes https://github.com/elastic/kibana/issues/164104
## Summary
**Replace "Download CSV" with "Generate CSV report" to export a CSV file
from saved search panel, deprecate "Download CSV", use a config flag for
providing the deprecated feature.**
This PR uses the `xpack.reporting.csv.enablePanelActionDownload`
kibana.yml setting, which was previously unused, for choosing behavior
of CSV export in a Dashboard saved search panel, and sets the default
value to `false`. The options allow the user to download a CSV file
without creating a report (deprecated, support will be removed in the
future) or to generate a CSV report (default).
1. Use the config as a flag to switch between implementations:
- downloading a CSV file without a generated report
- generating a CSV report
2. Updated documentation
3. Refactored / cleaned up tests
4. Increased API test coverage in Serverless
5. Better error handling in
`packages/kbn-reporting/public/reporting_api_client.ts`
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
## Release Note
Kibana CSV Reporting offered a feature allowing users to download a CSV
file from a saved search panel in a dashboard, without having a report
generated. This feature is now deprecated. Now, when users need to
access saved search data from a dashboard panel as CSV, a normal report
will be generated. To access the deprecated functionality, you can add
`xpack.reporting.csv.enablePanelActionDownload: true` to kibana.yml, but
this ability will be removed in a future version of Kibana.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/177138
- Add a `http.payloadTimeout` configuration option, to control the
payload timeout
- Set the default value for this option to `20s` (was `10s` previously)
## Summary
Just a small Doc Update. In the first example a POST was used and
towards a non existing handle (`_security` instead of `security`)
In the basic license example posted below this one, this is already
correct.
### Checklist
All checked - none applied.
(Though first PR in this repository, I am sorry if any mistakes were
made. If so - please point them out, will do better next time 😅 )
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
In this PR we:
* Allow using JWT credentials to grant API keys
* Extend default value of `elasticsearch.requestHeadersWhitelist` to
include both `authorization` and `es-client-authentication` to support
JWT with required client authentication _by default_. See
https://www.elastic.co/guide/en/elasticsearch/reference/8.11/jwt-auth-realm.html#jwt-realm-configuration
* Add API integration tests for both JWTs with client authentication and
without it
__NOTE:__ We're not gating this functionality with the config flag
(`xpack.security.authc.http.jwt.taggedRoutesOnly`) as we did for the
Serverless offering. It'd be a breaking change as we already implicitly
support JWT authentication without client authentication, and to be
honest, it's not really necessary anyway.
## Testing
Refer to the `Testing` section in this PR description:
https://github.com/elastic/kibana/pull/159117.
Or run already pre-configured Kibana functional test server:
1. `node scripts/functional_tests_server.js --config
x-pack/test/security_api_integration/api_keys.config.ts`
2. Create a role mapping for JWT user:
```bash
curl -X POST --location "http://localhost:9220/_security/role_mapping/jwt" \
-H "Authorization: Basic ZWxhc3RpYzpjaGFuZ2VtZQ==" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d "{
\"roles\": [ \"superuser\" ],
\"enabled\": true,
\"rules\": { \"all\": [{\"field\" : { \"realm.name\" : \"jwt_with_secret\" }}] }
}"
```
3. Send any Kibana API request with the following credentials:
```bash
curl -X POST --location "xxxx"
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2tpYmFuYS5lbGFzdGljLmNvL2p3dC8iLCJzdWIiOiJlbGFzdGljLWFnZW50IiwiYXVkIjoiZWxhc3RpY3NlYXJjaCIsIm5hbWUiOiJFbGFzdGljIEFnZW50IiwiaWF0Ijo5NDY2ODQ4MDAsImV4cCI6NDA3MDkwODgwMH0.P7RHKZlLskS5DfVRqoVO4ivoIq9rXl2-GW6hhC9NvTSkwphYivcjpTVcyENZvxTTvJJNqcyx6rF3T-7otTTIHBOZIMhZauc5dob-sqcN_mT2htqm3BpSdlJlz60TBq6diOtlNhV212gQCEJMPZj0MNj7kZRj_GsECrTaU7FU0A3HAzkbdx15vQJMKZiFbbQCVI7-X2J0bZzQKIWfMHD-VgHFwOe6nomT-jbYIXtCBDd6fNj1zTKRl-_uzjVqNK-h8YW1h6tE4xvZmXyHQ1-9yNKZIWC7iEaPkBLaBKQulLU5MvW3AtVDUhzm6--5H1J85JH5QhRrnKYRon7ZW5q1AQ'
-H 'ES-Client-Authentication: SharedSecret my_super_secret'
....for example....
curl -X GET --location "http://localhost:5620/internal/security/me" \
-H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2tpYmFuYS5lbGFzdGljLmNvL2p3dC8iLCJzdWIiOiJlbGFzdGljLWFnZW50IiwiYXVkIjoiZWxhc3RpY3NlYXJjaCIsIm5hbWUiOiJFbGFzdGljIEFnZW50IiwiaWF0Ijo5NDY2ODQ4MDAsImV4cCI6NDA3MDkwODgwMH0.P7RHKZlLskS5DfVRqoVO4ivoIq9rXl2-GW6hhC9NvTSkwphYivcjpTVcyENZvxTTvJJNqcyx6rF3T-7otTTIHBOZIMhZauc5dob-sqcN_mT2htqm3BpSdlJlz60TBq6diOtlNhV212gQCEJMPZj0MNj7kZRj_GsECrTaU7FU0A3HAzkbdx15vQJMKZiFbbQCVI7-X2J0bZzQKIWfMHD-VgHFwOe6nomT-jbYIXtCBDd6fNj1zTKRl-_uzjVqNK-h8YW1h6tE4xvZmXyHQ1-9yNKZIWC7iEaPkBLaBKQulLU5MvW3AtVDUhzm6--5H1J85JH5QhRrnKYRon7ZW5q1AQ' \
-H 'ES-Client-Authentication: SharedSecret my_super_secret' \
-H "Accept: application/json"
----
{
"username": "elastic-agent",
"roles": [
"superuser"
],
"full_name": null,
"email": null,
"metadata": {
"jwt_claim_sub": "elastic-agent",
"jwt_token_type": "access_token",
"jwt_claim_iss": "https://kibana.elastic.co/jwt/",
"jwt_claim_name": "Elastic Agent",
"jwt_claim_aud": [
"elasticsearch"
]
},
"enabled": true,
"authentication_realm": {
"name": "jwt_with_secret",
"type": "jwt"
},
"lookup_realm": {
"name": "jwt_with_secret",
"type": "jwt"
},
"authentication_type": "realm",
"authentication_provider": {
"type": "http",
"name": "__http__"
},
"elastic_cloud_user": false
}
```
__Fixes:__ https://github.com/elastic/kibana/issues/171522
----
Release note: The default value of the
`elasticsearch.requestHeadersWhitelist` configuration option has been
expanded to include the `es-client-authentication` HTTP header, in
addition to `authorization`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
The PR tackles a couple of improvements for the new `'notifications'`
plugin documentation:
- Add a link to the plugin API description in the kibana-dev-docs nav
bar.
- Convert the README to `mdx`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
If a CSV export is performed on an index alias, it also requires read
access to underlying indices.
This PR adds a note in Kibana docs to make users aware of this
requirement.
👋🏼 howdy, team! When Kibana can't connect to Elasticsearch (past finding master /
network issue, just unhealthy cluster ballpark), its code logic cascades
into first tripping warn/error log `license is not available`.
This is a red-herring in that the license can not be determined and user
should investigate the network connection / Elasticsearch health rather
than investigating for lapsed licenses.
Adding this into the "Kibana not ready" docs since it raises at this
point in the flow to hopefully allow users to search-find it in our
official docs rather than e.g. top-goggle-results: [Elastic
Discuss](https://discuss.elastic.co/t/license-not-available/265931),
[external Github](https://github.com/spujadas/elk-docker/issues/349).
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>
Not sure if the original text was intentional.
If APM needs to be more prominent here, you could say *Elastic
Observability and APM* , but it's misleading to say that you can use
Elastic APM for all of the use cases listed here.
Note that I didn't search the Kibana Guide for other instances of this
problem; I just noticed this while doing something else and wanted to
make sure it's fixed.
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
## Summary
Updates `Troubleshoot Kibana UI error` with the following fixes:
- {kib} in error code should Kibana
- code shouldn’t have “`” tick marks wrapping commands
- the bullet list under Step#5 didn’t format
This adds steps to the [Install Kibana with
Docker](https://www.elastic.co/guide/en/kibana/current/docker.html) page
for verifying the downloaded Docker images. I split apart the original
version which had all the commands in one block. Having them separate
allows us to add in the optional "verify images" step with a link to the
Elasticsearch docs for additional info.
Rel: https://github.com/elastic/dev/issues/2002
**Preview**
---
---
---------
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
## Summary
Relates to: #113217
- Add extra documentation to highlight behaviour of the kibana keystore
(for #113217)
- Fix/Tidy-up commands (`create`, `list`) where the extra unused
arguments were preventing the `options` from being passed to the
functions. Also remove unnecessary `async` keyword from the `remove`
command.
- Added new `show` command
```
Usage: bin/kibana-keystore show [options] <key>
Displays the value of a single setting in the keystore. Pass the -o (or --output) parameter to write the setting to a file.
Options:
-s, --silent prevent all logging
-o, --output <file> output value to a file
-h, --help output usage information
```
### Checklist
Delete any items that are not applicable to this PR.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Kaarina Tungseth <kaarina.tungseth@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
