forked from elastic/kibana
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[pull] main from elastic:main #531
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Summary Resolve #163328 When user was setting dark mode, the integration app was not corretcly handling it (it was already good for the Fleet APP) That PR fix that. ## Test/UI Changes Set dark mode for your user and observe the integration app is correctly rendered. <img width="1495" alt="Screenshot 2023-08-25 at 1 43 45 PM" src="https://github.com/elastic/kibana/assets/1336873/7681b788-72b2-470e-924b-2f43d7653267">
Automated by https://internal-ci.elastic.co/job/package_storage/job/sync-bundled-packages-job/job/main/6513/ Co-authored-by: apmmachine <[email protected]>
Co-authored-by: Kibana Machine <[email protected]>
Enhanced Discover performance for scenarios with numerous unmapped fields. While investigating an edge case involving 4k unmapped fields, an issue was identified in our nested field detection code, resulting in significant processing time. This commit optimizes the code by addressing redundant RegEx execution, resulting in a performance boost for the specific scenario.
## Summary We recently got problems because some index creation settings are rejected by stateless ES, causing the whole system to fail and Kibana to terminate. We can't really use feature flags for this, given: 1. it doesn't really make sense to use manual flags for something that strictly depend on one of our dependency's capabilities 2. we're mixing the concept of "serverless" offering and "serverless" build. Atm we sometimes run "serverless" Kibana against traditional ES, meaning that the "serverless" info **cannot** be used to determine if we're connected against a default or serverless version of ES. This was something that was agreed a few weeks back, but never acted upon. ## Introducing ES capabilities This PR introduces the concept of elasticsearch "capabilities". Those capabilities are built exclusively from info coming from the ES cluster (and not by some config flag). This first implementation simply exposes a `serverless` flag, that is populated depending on the `build_flavor` field of the `info` API (`/` endpoint). The end goal would be to expose a real capabilities (e.g "what is supported") list instead. But ideally this would be provided by some ES API and not by us guessing what is supported depending on the build flavor, so for now, just exposing whether we're connected to a default of serverless ES will suffice. ### Using it to adapt some API calls during SO migration This PR also adapts the `createIndex` and `cloneIndex` migration action to use this information and change their request against ES accordingly (removing some index creation parameters that are not supported). --------- Co-authored-by: kibanamachine <[email protected]>
…aracters (#163767) **Fixes: #163692 ## Summary This PR fixes rules table filtering for tags with special characters like colon `category:tag`. We didn't have this bug in `8.9` it was introduced by #160480 in `8.10` scope. ## Details Coverage Overview Dashboard required very similar rule filtering functionality as rule table has so #160480 moved the common logic to `common` folder and started using `escapeKuery` from `@kbn/es-query` instead of custom `escapeKuery` defined in Security Solution in `x-pack/plugins/security_solution/public/common/lib/kuery/index.ts`. The difference is the first function escapes all the special characters `\():<>"*` but the second escapes only quotes but the value must be enclosed in quotes to be passed on. Both ways are correct according to [docs](https://www.elastic.co/guide/en/kibana/current/kuery-query.html). So escaping all the special characters and enclosing the value in quotes breaks rules search. ### How was it fixed? Escaping related code in `x-pack/plugins/security_solution/common/utils/kql.ts` (`convertRulesFilterToKQL` in particular) was moved to `x-pack/plugins/security_solution/common/detection_engine/rule_management/rule_filtering.ts` as Coverage Overview Dashboard API endpoint and rules table UI share the same KQL helpers and refactored along the way to be much more transparent. ### Checklist - [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
This is the first step in a series of tasks introducing Artifact rollout UI. We are eager to merge this quickly to unblock other teams from e2e testing the feature. These changes introduce new tab "Protection Updates" under endpoint policy detail. Access privileges are based on already present `canWritePolicyManagement` setting that is being used on `Policy settings` tab. There are 3 states of the tab: 1. Edit when `canWritePolicyManagement` endpoint privilege is set to true. 2. View when `canWritePolicyManagement` is set to false 3. Hidden when `protectionUpdatesEnabled` feature flag is set to false. This also excludes `/{policy.id}/protectionUpdates` route. Successful user journey results in the addition of `manifest_version` key in the policy with default of `latest`: ``` policy: meta: ... linux: ... global_manifest_version: '2023-08-24' windows:.. ``` **Stored date format is `YYYY-MM-DD`.** Edit flow and behaviour: https://github.com/elastic/kibana/assets/29123534/02c82768-0201-471c-8258-f01831106ad1 Read only priveleges: ![Screenshot 2023-08-24 at 10 58 24](https://github.com/elastic/kibana/assets/29123534/bda4b096-48b4-4faf-80bf-9dbf36ab4aca) Feature Flag off: ![Screenshot 2023-08-24 at 11 41 06](https://github.com/elastic/kibana/assets/29123534/d873cb8a-0f93-42fd-84d8-fef98a602a25)
…s` - Deletes and recovers more than one rule (#164694) Relates to: #161507 ## Summary - Solves flakiness in following test: - Filename: `x-pack/test/security_solution_cypress/cypress/e2e/detection_response/prebuilt_rules/prebuilt_rules_management.cy.ts` - Test name: **Prebuilt rules Actions with prebuilt rules Rules table Deletes and recovers more than one rule** - Test was failing because of already observed issue of `autoRefresh` taking place while the rule selection is happening, causing Cypress to lose focus and preventing the checkbox from being checked. This PR disables autorefresh from the table to prevent that from happening. ## Flaky test runner 350 iters: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/2976 🟢
Automated by https://internal-ci.elastic.co/job/package_storage/job/sync-bundled-packages-job/job/main/6537/ Co-authored-by: apmmachine <[email protected]>
…d field (#163936) ## Summary Part of - elastic/security-team#7146 As we are aiming to remove the filtering logic for vulnerabilities with missing fields I suggest removing the `resource.id` part of the filter. Having this filter doesn't seem to bring any value, just limiting the capabilities for users. Vulnerabilities without `resource.id` will show up in the grid and on the dashboard, they just won't appear in the grouping. In my opinion, this is fine and we always can improve it if we see that having documents without `resource.id` is a valid case for our users ## Screenshots <img width="1712" alt="Screenshot 2023-08-25 at 15 05 38" src="https://github.com/elastic/kibana/assets/478762/e7577e0b-7b6b-484e-883f-aa0dabc05d55"> <img width="1728" alt="Screenshot 2023-08-25 at 15 05 51" src="https://github.com/elastic/kibana/assets/478762/e02ef85a-9b41-4d05-8e05-be3e238e71f1">
## Remove legacy risk score dashboards when install risk engine ### How to test - Start kibana - Create a filebeat index (to have access to host/user pages) ``` PUT filebeat-8.10.0 { "mappings": { "properties": { "@timestamp": { "type": "date" }, "host": { "properties": { "name": { "type":"keyword" } } } } } } ``` - Go to Security -> Dashboard -> Entity Analytics - Enable Host risk score an User risk score - Go to Security -> Dashboards. Scroll down, and be sure that tags about Host risk score and User risk score are enabled. Observe dashboards related to Host/User risk scores. <img width="804" alt="Screenshot 2023-08-25 at 17 49 08" src="https://github.com/elastic/kibana/assets/7609147/e3cabaa5-8fed-4646-89f9-957c004bc459"> - Then enable this FF `xpack.securitySolution.enableExperimental: ['riskScoringPersistence','riskScoringRoutesEnabled']` - Restart Kibana, and go to Security -> Manage -> Entity Risk Score - Click Start update and then confirm it - Go back to dashboards and observe that there are no related to Host/User risk score <img width="993" alt="Screenshot 2023-08-25 at 17 55 40" src="https://github.com/elastic/kibana/assets/7609147/0ced8167-6f39-46fd-8a5a-2dc977712226"> --------- Co-authored-by: Kibana Machine <[email protected]>
Co-authored-by: Coen Warmer <[email protected]> Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Clint Andrew Hall <[email protected]> Co-authored-by: Carlos Crespo <[email protected]> Co-authored-by: Alejandro Fernández Haro <[email protected]>
Fixes #162587 ## Summary Fixes the `from` date which previously would point to current day for a restored project monitor (i.e. when monitor `created_at` is refreshed due to a re-push of a deleted project monitor).
## Summary This PR updates tooltips of user risk score and host risk score based on docs team's [suggestions](#164786). ![image](https://github.com/elastic/kibana/assets/18648970/2c6d4bd0-6ad7-4f84-aaae-d663c63b518b) ![image](https://github.com/elastic/kibana/assets/18648970/8ba4086b-1a13-4803-90f2-858d53879da3) ### Checklist - [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 Addresses #164546 Follow up to #163521 and #163955 This PR re-implements index actions in the context menu on the index details page. The actions are implemented without redux which is used in the old index details flyout (to be removed when this work is complete) and in the indices list. The PR introduces a declaration file to list all props of the component `IndexActionsContextMenu` written in JS. There is also a new component `ManageIndexButton` that implements index actions specifically to be executed on the new index details page. In the future most of the code in the component `ManageIndexButton` can be re-used when more refactorings will be made (switching to TS and not using redux in the indices list). All index actions are async and I added a loading indicator to the context menu button to indicate that requests are in flight updating the index. ### Screen recordings https://github.com/elastic/kibana/assets/6585477/c39f1450-b495-4c50-b4ca-8989a2259ed5 Add/remove ILM policy actions with a confirmation modal https://github.com/elastic/kibana/assets/6585477/964931c9-b926-4ed4-aa5c-218f52881131 ### How to test 1. Add `xpack.index_management.dev.enableIndexDetailsPage: true` to your `/config/kibana.dev.yml` file 7. Start ES and Kibana with `yarn es snapshot` and `yarn start` 8. Add several indices to test with the command `PUT /test_index` in Dev Tools Console 9. Navigate to Index Management and click the name of any index 10. Check index actions: - [x] Close index - [x] Open index - [x] Force merge index - [x] Refresh index - [x] Clear index cache - [x] Flush index - [ ] Unfreeze index (not sure how to add a frozen index) - [x] Delete index - [x] ILM: add lifecycle policy - [x] ILM: remove lifecycle policy - [x] ILM: retry lifecycle policy (add any built-in policy and wait a couple of minutes until the rollover fails) ### Checklist - [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
…en opening Discover, Dashboard, or Visualize Library
The source map index is no longer used but should still be declared to avoid breaking existing cluster configurations
…siness logic refactor (#164825) Fixes: #147064 ## Summary - `rule_details_ui/pages/rule_details/index.test.tsx` was too heavy and can fail by timeout - The unit test was mounting the whole rule details component to test: - redirection logic - which tabs are visible This PR: - extracts that logic into two new hooks and one component: - `useLegacyUrlRedirect` (for redirection logic) - `useRuleDetailsTabs` (to calculate which tabs should be displayed) - `LegacyUrlConflictCallOut` - adds tests for the two hooks and the component, covering all the logic that was previously covered by the `rule_details_ui/pages/rule_details/index.test.tsx` file - deletes the `rule_details_ui/pages/rule_details/index.test.tsx` file --------- Co-authored-by: kibanamachine <[email protected]>
#164918) ## Summary This PR aims at fixing a weird bug where the new expandable flyout automatically reopens when changing tabs, or clicking on the refresh button in the KQL bar. It seems that there is a conflict or a raise condition between the code that manages the url sync of the old flyout with the code that manages the url sync of the new flyout. The PR disables the old flyout navigation on initialization. _Weird thing is, while this fixed the issue, when I toggled the advanced setting off and then back on again, the issue stopped appearing all together. Still needs a bit more investigation..._ Before the fix https://github.com/elastic/kibana/assets/17276605/db3fff85-564e-480b-af26-bf4e59992560 After the fix https://github.com/elastic/kibana/assets/17276605/4bdf27bb-f9da-48bf-80d1-e2e83014c40c ### Steps to reproduce - navigate to the alerts page - open the flyout - refresh the page (browser refresh) with the flyout open - close the flyout - try to navigate to a different page (like cases) or try to click on the refresh button in the KQL bar ### Checklist - [ ] [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
Closes [#162942](#162942) ## Summary This PR adds new metrics to the asset details page: - CPU usage (Broken down) - Load (Broken down) - Memory Usage (Broken down) - Disk Usage by Mount Point The hosts view flyout metrics remain the same as before. ## Testing⚠️ I would suggest running metricbeat in Docker as some of the metrics used in `CPU usage (Broken down)` are not available in MacOs (in discussion with beats team currently) - Go to hosts page - Open the flyout for a host - Click open as page link - Check the new metrics on different screen size (the labels should be visible as shown: ![Image](https://github.com/elastic/kibana/assets/14139027/6d98996b-2eb1-414b-92a2-870932ad4284) ![Image](https://github.com/elastic/kibana/assets/14139027/e612c7b4-8d93-4c42-883b-fc5e620ab2a0)
## Summary Updated the search-api-panels docLinks types to not use `any` Fixed prop in serverless search, I _think_ this was a merge conflict between PRs
## Summary The FTR serverless pipeline's output can be confusing, because in case any of the configs fail, the error log is always attached to the last collapsing block (thus making devs think it was the last block that was erroneous). This PR adds an output message after the configs are ran, and separates the log from the last run's logs. - chore: Add result logging for serverless_ftr.sh with a new collapsing block to avoid confusion Was: <img width="1086" alt="Screenshot 2023-08-28 at 16 08 43" src="https://github.com/elastic/kibana/assets/4738868/46721879-8add-49a2-8448-b9ed40ac8bc0"> Would be: <img width="1079" alt="Screenshot 2023-08-28 at 16 08 20" src="https://github.com/elastic/kibana/assets/4738868/3eaf7f2b-7fc8-4777-81e3-1c21ec57faaa">
**Resolves: #164828 **Related UX writing issue: elastic/ux-writing#46 ## Summary In rule details page, when a rule has a data view selected, two labels show up as "Data View". This appears to be a bug, as one of those labels should be "Data view ID" and another should be "Data view index pattern". Thanks to @MadameSheema @nikitaindik for finding this. ### Before ![image](https://github.com/elastic/kibana/assets/10927944/8ac8b6d4-1005-4c03-a71a-31216a1287c5) ### After <img width="808" alt="Screenshot 2023-08-26 at 19 30 54" src="https://github.com/elastic/kibana/assets/15949146/b511bf92-0e90-4455-834c-36b8e75b2a58"> ### Checklist - [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) --------- Co-authored-by: Nikita Indik <[email protected]>
…erimental) (#164908) ## [Security Solution] [Elastic AI Assistant] LangChain integration (experimental) This PR integrates [LangChain](https://www.langchain.com/) with the [Elastic AI Assistant](https://www.elastic.co/blog/introducing-elastic-ai-assistant) as an experimental, alternative execution path. ### How it works - There are virtually no client side changes to the assistant, apart from a new branch in `x-pack/packages/kbn-elastic-assistant/impl/assistant/api.tsx` that chooses a path based on the value of the `assistantLangChain` flag: ```typescript const path = assistantLangChain ? `/internal/elastic_assistant/actions/connector/${apiConfig?.connectorId}/_execute` : `/api/actions/connector/${apiConfig?.connectorId}/_execute`; ``` Execution of the LangChain chain happens server-side. The new route still executes the request via the `connectorId` in the route, but the connector won't execute the request exactly as it was sent by the client. Instead, the connector will execute one (or more) prompts that are generated by LangChain. Requests routed to `/internal/elastic_assistant/actions/connector/${apiConfig?.connectorId}/_execute` will be processed by a new Kibana plugin located in: ``` x-pack/plugins/elastic_assistant ``` - Requests are processed in the `postActionsConnectorExecuteRoute` handler in `x-pack/plugins/elastic_assistant/server/routes/post_actions_connector_execute.ts`. The `postActionsConnectorExecuteRoute` route handler: 1. Extracts the chat messages sent by the assistant 2. Converts the extracted messages to the format expected by LangChain 3. Passes the converted messages to `executeCustomLlmChain` - The `executeCustomLlmChain` function in `x-pack/plugins/elastic_assistant/server/lib/langchain/execute_custom_llm_chain/index.ts`: 1. Splits the messages into `pastMessages` and `latestMessage`, where the latter contains only the last message sent by the user 2. Wraps the conversation history in the `BufferMemory` LangChain abstraction 3. Executes the chain, kicking it off with `latestMessage` ```typescript const llm = new ActionsClientLlm({ actions, connectorId, request }); const pastMessages = langchainMessages.slice(0, -1); // all but the last message const latestMessage = langchainMessages.slice(-1); // the last message const memory = new BufferMemory({ chatHistory: new ChatMessageHistory(pastMessages), }); const chain = new ConversationChain({ llm, memory }); await chain.call({ input: latestMessage[0].content }); // kick off the chain with the last message }; ``` - When LangChain executes the chain, it will invoke `ActionsClientLlm`'s `_call` function in `x-pack/plugins/elastic_assistant/server/lib/langchain/llm/actions_client_llm.ts` one or more times. The `_call` function's signature is defined by LangChain: ``` async _call(prompt: string): Promise<string> ``` - The contents of `prompt` are completely determined by LangChain. - The string returned by the promise is the "answer" from the LLM The `ActionsClientLlm` extends LangChain's LLM interface: ```typescript export class ActionsClientLlm extends LLM ``` This let's us do additional "work" in the `_call` function: 1. Create a new assistant message using the contents of the `prompt` (`string`) argument to `_call` 2. Create a request body in the format expected by the connector 3. Create an actions client from the authenticated request context 4. Execute the actions client with the request body 5. Save the raw response from the connector, because that's what the assistant expects 6. Return the result as a plain string, as per the contact of `_call` ## Desk testing This experimental LangChain integration may NOT be enabled via a feature flag (yet). Set ```typescript assistantLangChain={true} ``` in `x-pack/plugins/security_solution/public/app/app.tsx` to enable this experimental feature in development environments.
…nts instead of Detection Alerts + add missing interaction in cell actions (#164923)
…ide the share alert button (#164990)
## Summary Initially, the failed tests occurred for `products.base_price` field in the latest transform, however, the error could happen to all other numeric fields that could appear as an integer or a float. This PR adds explicit mappings for all numeric fields. [Flaky test suite runner for functional/apps/transform/creation/index_pattern](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/2994)... sucessful after 100 runs ✅ [Flaky test suite runner for functional_basic/apps/transform/creation/index_pattern](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/3000)... ### Checklist Delete any items that are not applicable to this PR. - [ ] 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) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [ ] [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 - [ ] Any UI touched in this PR is usable by keyboard only (learn more about [keyboard accessibility](https://webaim.org/techniques/keyboard/)) - [ ] Any UI touched in this PR does not create any new axe failures (run axe in browser: [FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/), [Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US)) - [ ] 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) - [ ] This renders correctly on smaller devices using a responsive layout. (You can test this [in your browser](https://www.browserstack.com/guide/responsive-testing-on-local-server)) - [ ] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers) ### Risk Matrix Delete this section if it is not applicable to this PR. Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release. When forming the risk matrix, consider some of the following examples and how they may potentially impact the change: | Risk | Probability | Severity | Mitigation/Notes | |---------------------------|-------------|----------|-------------------------| | Multiple Spaces—unexpected behavior in non-default Kibana Space. | Low | High | Integration tests will verify that all features are still supported in non-default Kibana Space and when user switches between spaces. | | Multiple nodes—Elasticsearch polling might have race conditions when multiple Kibana nodes are polling for the same tasks. | High | Low | Tasks are idempotent, so executing them multiple times will not result in logical error, but will degrade performance. To test for this case we add plenty of unit tests around this logic and document manual testing procedure. | | Code should gracefully handle cases when feature X or plugin Y are disabled. | Medium | High | Unit tests will verify that any feature flag or plugin combination still results in our service operational. | | [See more potential risk examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) | ### 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: kibanamachine <[email protected]>
## Summary [Summarize your PR. If it involves visual changes include a screenshot or gif.](elastic/enhancements#17998) ### Checklist - [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: lcawl <[email protected]>
## Summary Change the Network Drive connector to require a platinum license.
`data.search` uses [poll_search](https://github.com/elastic/kibana/blob/main/src/plugins/data/common/search/poll_search.ts) to fetch data. `poll_search` checks for `isErrorResponse` and throws when`isErrorResponse` is true. **Note** `searchSource.search` uses `data.search` to perform searches. ```javascript return from(search()).pipe( expand(() => { const elapsedTime = Date.now() - startTime; return timer(getPollInterval(elapsedTime)).pipe(switchMap(search)); }), tap((response) => { if (isErrorResponse(response)) { throw response ? new Error('Received partial response') : new AbortError(); } }), takeWhile<Response>(isPartialResponse, true), takeUntil<Response>(aborted$) ); ``` Subscribers to `data.search` and `searchSource.search` do not need to check for `isErrorResponse` in `next`. `poll_search` has already thrown then the response is `isErrorResponse` so these checks are dead code blocks that are never executed. This PR removes these dead code blocks. Breaking this change out of #164506 so that it can be reviewed in isolated. --------- Co-authored-by: kibanamachine <[email protected]>
Resolves #163891. In this PR, I'm making the event log skip converting existing assets to hidden if it is in a serverless deployment. Given assets that need to be converted to hidden would exist prior to 8.0, there isn't such a case in serverless and we do not have the necessary legacy APIs to retrieve them. ## To verify on Serverless - Ensure on serverless there are no more warnings as indicated in #163891. ## To verify on non-Serverless 1. Create a 7.15 deployment (and persisting the ES data so you can upgrade later) 2. Create an alerting rule (with short interval, say 10s) 3. Let the alerting rule run a few times so it generates event logs 4. Upgrade ES to 7.17 (it will fail otherwise) 5. Upgrade your deployment to this PR 6. Check the event log index template, indices and alias for 7.15 to ensure they got converted to hidden - `curl -XGET http://elastic:changeme@localhost:9200/_template/.kibana-event-log-7.15.3-template` - `curl -XGET http://elastic:changeme@localhost:9200/.kibana-event-log-7.15.3-000001` - `curl -XGET http://elastic:changeme@localhost:9200/_alias/.kibana-event-log-7.15.3` --------- Co-authored-by: Kibana Machine <[email protected]>
#164988) ## Summary Needed for #160572 (comment)
…rsion model in API READ methods" (#164991)
Problem: The [Configure security in Kibana](https://www.elastic.co/guide/en/kibana/current/using-kibana-with-security.html) docs page only covers the `xpack.security.encryptionKey` setting for session encryption. Users may not know that encryption for Kibana's reporting and saved objects features also require encryption keys. Solution: Add a cross-link to the respective encryption key settings for reporting and saved objects
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )