This PR adds Fleet audit logging memory leak to 8.8.0-8.8.1 known issues.
Ref: https://github.com/elastic/kibana/pull/159807
Co-authored-by: James Rodewig <james.rodewig@elastic.co>
Co-authored-by: David Kilfoyle <41695641+kilfoyle@users.noreply.github.com>
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/2655
This PR introduces a customized log consumption experience in the
Discover plugin. By leveraging the new `discover_log_explorer` plugin
and utilizing the `discover.customize` functionality, we have curated a
more tailored user experience.
The key feature of this implementation is the `DatasetSelector`
component, which replaces the original Discover `DataViewPicker`. It
handles the retrieval, rendering, and navigation of integrations and
data streams related to logs, providing an improved user interface.
This PR involves significant development efforts, including the creation
of the `discover_log_explorer` plugin, implementation of services, state
machines, custom hooks, and enhancements to presentational components.
The following overview will help reviewers understand the
responsibilities of each component in this implementation.
d725b699-452e-4718-8189-8dc1fab4d044
## DatasetsService & DatasetsClient
The DatasetsService is introduced, a crucial component that mediates
access to the newly implemented DatasetsClient. During the plugin's
lifecycle, the DatasetsService exposes a client property through its
start() method, providing convenient access to a DatasetsClient
instance.
The DatasetsClient is responsible for abstracting the data fetching
process for two endpoints: the integrations endpoint and the data
streams listing endpoint. These endpoints are utilized to populate the
selector options in the user interface. To facilitate this, the
DatasetsClient exposes the findIntegrations and findDatasets methods,
which handle the respective data fetching.
## Discover Customization
The critical part of this work consists of where the customization is
applied.
Inside the `public/plugin.tsx`, we lazy load and create, injecting the
required dependencies, the `CustomDatasetSelector`, which already
encapsulates all the logic required to make the selector work with the
external APIs.
We kept separating the data fetching logic from how the selector works,
and all the data and events are passed into the UI component with
properties.
```ts
discover.customize(
DISCOVER_LOG_EXPLORER_PROFILE_ID,
({ customizations, stateContainer }) => {
customizations.set({
id: 'search_bar',
CustomDataViewPicker: createLazyCustomDatasetSelector({
datasetsClient: datasetsService.client,
stateContainer,
}),
});
...
```
## Data fetching state machines & custom hooks
To handle the data fetching of integrations and unmanaged data streams,
we created two different state machines to separately handle the related
action for each dataset, such as remote search, in-memory search, error
handling etc.
### Integration machine and useIntegrations
The integrations state machine handles automatic data fetching of the
resources and additionally provides transitions for loading more
integrations, searching integrations by HTTP request, searching locally
into integration streams, and all the related loading and error handling
states.
It is then interpreted inside the `useIntegrations` custom hook, which
exposes the fetched data and handlers for all the above-mentioned
actions.
<img width="1975" alt="Screenshot 2023-05-30 at 09 44 42"
src="6daeca9f-826d-4a0f-bd90-eb4826ed1bde">
### Datasets machine and useDatasets
Similar to the integrations state machine, but simplified since the data
streams search can only happen with HTTP requests and there is no
pagination that requires to handle the load of more entries.
It is interpreted inside the `useDatasets` custom hook, which also
exposes the fetched data and handlers for the available actions.
<img width="1692" alt="Screenshot 2023-05-30 at 09 45 11"
src="5f9690e2-4e8f-439e-9ffd-f3b34cf3eaf5">
## DatasetSelector
The `DatasetSelector` component contains all the logic that manages the
navigation and searches across the different panels that render
integrations, integrations' streams or unmanaged streams.
As the datasets come from different APIs or are performed in-memory, the
search work follow this logic:
- When listing the integrations list (first level of the
`EuiContextMenu`), the search is done with an HTTP request.
- When listing the data streams list for a specific integration (second
level of the `EuiContextMenu`), the search is done in-memory, filtering
and sorting directly in the client.
- When listing the unmanaged data streams list (second level of the
`EuiContextMenu`), the search is done again with an HTTP request.
To handle these possible user journeys correctly without side effects,
we created another state machine and exposed its actions with an
internal `useDatasetSelector` custom hook.
<img width="1978" alt="Screenshot 2023-05-30 at 09 46 04"
src="84aa4247-c65d-40de-9eb6-6117bee731f8">
## Next steps
This component will change quite a lot until we won't get to a final
design. As soon as a first solid mvp is defined for production, a
complete test for the component will be implemented, among with a more
generic functional test for the core customization features.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
## Summary
The pattern analysis feature is a Platinum subscription feature in
technical preview, which is now called out in the warning at the top of
the page. Otherwise users cannot follow the instructions on the page as
the options are not visible.
<img width="827" alt="Screenshot 2023-06-27 at 15 12 16"
src="9d9fc713-6640-4e41-9003-dd080f5fe746">
### Checklist
Relates to and closes: #159170
- Closes https://github.com/elastic/kibana/issues/149336
## Summary
This PR converts `unifiedFieldList` plugin into a new
`@kbn/unified-field-list` package.
Had to also move some deps:
- from `uiActions` plugin to the existing `@kbn/ui-actions-browser`
package
- from `data` plugin to a new `@kbn/data-service` package
Please test that Field Stats from the package are still working on your
pages.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR updates the security audit logs with some cases values. We added
a new operation for retrieving the `categories` of a case and the users
associated with a case.
## Summary
This PR limits the number of categories by which we can filter calls to
the find cases API.
The limit is now 100.
---------
Co-authored-by: lcawl <lcawley@elastic.co>
This PR does:
- checks Kibana.spec file
- Checks server feature.ts
- Adds correct route access to APIs
- Removes unnecessary logs
- Removes collector and symbolized `secret_token` from config schema as
it won't be used
- Add README file
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Partially address https://github.com/elastic/kibana/issues/158835, add
cloud chat (drift) to more places: all management pages and
home/getting_started page
I hit an issue that both management and home couldn't depend directly on
`cloudChat` plugin. Here is the issue with more details
https://github.com/elastic/kibana/issues/159008. I worked around with
creating an intermediate `cloudChatProvider` plugin.
How do I run drift locally?
Add this to kibana.yml
```
xpack.cloud.id: "some-id"
xpack.cloud.trial_end_date: "2023-06-21T00:00:00.000Z"
xpack.cloud_integrations.chat.enabled: true
xpack.cloud_integrations.chat.chatURL: "https://elasticcloud-production-chat-us-east-1.s3.amazonaws.com/drift-iframe.html"
xpack.cloud_integrations.chat.chatIdentitySecret: "some-secret" (get it from drift console)
```
You need to have access to our drift account. But I tested with a custom
account. To change account id I had to point
`xpack.cloud_integrations.chat.chatURL` to a script with custom drift
id.
## Summary
Fix https://github.com/elastic/kibana/issues/150079
Add support for the `*` wildcard for by-type export, allowing to more
easily export all the exportable SO types
```
POST /api/saved_objects/_export
{
types: '*',
}
```
## Release Note
The savedObjects export API now supports exporting all types using the
`*` wildcard. Please refer to the documentation
for more details and examples.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Adds the release notes for the 8.8.1 release.
Co-authored-by: Brandon Morelli <bmorelli25@gmail.com>
Co-authored-by: amyjtechwriter <61687663+amyjtechwriter@users.noreply.github.com>
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
This PR fixes the documentation for the "update data view fields" API which used an incorrect route in the provided examples (data-view instead of data_view)
## 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
[Documentation](https://docs.google.com/document/d/1Ms8d8d_fbTTRHlBroEAKGNMNk3jFFgOAkVDRhqLxAPQ/edit?pli=1#)
issue: https://github.com/elastic/kibana/issues/158810
## Summary
This PR is a cleanup to make [this
POC](https://github.com/elastic/kibana/pull/155420) production ready
- Serverless PLI features splitting in Security Solution, to allow/deny
access to configured functionalities, using the current Kibana RBAC
service.
- Create the Upselling service to display Serveless-specific prompts in
the application when features are not available
- Create a `SecurityRoutePageWrapper` component that wraps Pages and
displays the upsell when necessary.
- We will refactor the code base to use `SecurityRoutePageWrapper`
everywhere on another PR.
- Create an Upsell page and section for entity analytics
bd8db822-2f4b-4545-9da7-bedc07d93f90
### test:
Serverless: `yarn serverless-security`.
* To change the product line you have to update
`xpack.serverless.security.productLineIds` on
`config/serverless.security.yml`.
ESS: `yarn start`
### Glossary
* PLI - Product Line Item (`Alert Triage`, `Osquery`, `Cases` , ... )
* Product Line - The product that the user is subscribed to (Security
Essentials, Security Complete, ...)
* essSecurity - New plugin with code that only runs for ESS offer
(non-serverless).
* App Feature - A security solution feature or group of features that
can be disabled for a product line. It can be mapped to PLIs (`Alert
Triage`, `Osquery`, `Cases` , ... ).
* Capability - A string that when present represents that the user can
access a given feature. A capability could be of the type UI or API
(`read_cases`, `crud_cases`, ...).
### Current architecture
### New architecture
### How does it work?
Every serverless product line (endpointEssentials, cloud essentials) can
define which features are enabled:
69d0fc15f4/x-pack/plugins/serverless_security/common/pli/pli_config.ts (L12-L19)
For ESS (non-serverless) offer we enable all features by default.
69d0fc15f4/x-pack/plugins/ess_security/server/constants.ts (L10-L13)
A feature can define privileges:
69d0fc15f4/x-pack/plugins/security_solution/server/lib/app_features/security_kibana_features.ts (L177-L185)
When the feature is enabled the privileges get merged into the base
config and injected into kibana features.
69d0fc15f4/x-pack/plugins/security_solution/server/lib/app_features/app_features.ts (L61-L70)
### TODO
- [x] lazy load these components
- [x] Add unit test to:
- ~SecurityRoutePageWrapper
x-pack/plugins/security_solution/public/common/components/security_route_page_wrapper/index.tsx~
-
~x-pack/plugins/security_solution/public/common/hooks/use_upselling.ts~
-
~x-pack/plugins/security_solution/public/common/lib/capabilities/has_capabilities.ts~
-
~x-pack/plugins/security_solution/public/common/lib/upsellings/upselling_service.ts~
- ~x-pack/plugins/serverless_security/common/pli/pli_features.ts~
-
~x-pack/plugins/serverless_security/public/components/upselling/register_upsellings.tsx~
-
~x-pack/plugins/security_solution/server/lib/app_features/app_features.ts~
### Checklist
Delete any items that are not applicable to this PR.
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes#127289
## Summary
Updates the asset tracking tutorial docs with considerations for running
in production.
For a better demo experience the tutorial uses a 5 second interval for
rule checking, but a very low interval can be problematic for running in
production.
I'm suggesting backporting these doc changes to 8.3 which the first
release to have a **Circuit breakers** section in
https://www.elastic.co/guide/en/kibana/8.3/alerting-production-considerations.html
that is most relevant to the added note in this PR.
---------
Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com>
