mirror of
https://github.com/elastic/kibana.git
synced 2025-04-24 17:59:23 -04:00
# Backport This will backport the following commits from `main` to `8.x`: - [SKA: Update broken references and URLs (#206836)](https://github.com/elastic/kibana/pull/206836) <!--- Backport version: 9.6.4 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Gerard Soldevila","email":"gerard.soldevila@elastic.co"},"sourceCommit":{"committedDate":"2025-01-28T03:32:48Z","message":"SKA: Update broken references and URLs (#206836)\n\n## Summary\r\n\r\nUpdates a number of broken file references and broken links.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by: Alejandro Fernández Haro <afharo@gmail.com>","sha":"fb26c1c683453faa7f8218df094f90d9ad070a23","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Core","Feature:ExpressionLanguage","release_note:skip","Team:Fleet","v9.0.0","backport:prev-minor","ci:project-deploy-observability","Team:obs-ux-infra_services","Team:obs-ux-management"],"title":"SKA: Update broken references and URLs","number":206836,"url":"https://github.com/elastic/kibana/pull/206836","mergeCommit":{"message":"SKA: Update broken references and URLs (#206836)\n\n## Summary\r\n\r\nUpdates a number of broken file references and broken links.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by: Alejandro Fernández Haro <afharo@gmail.com>","sha":"fb26c1c683453faa7f8218df094f90d9ad070a23"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/206836","number":206836,"mergeCommit":{"message":"SKA: Update broken references and URLs (#206836)\n\n## Summary\r\n\r\nUpdates a number of broken file references and broken links.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by: Alejandro Fernández Haro <afharo@gmail.com>","sha":"fb26c1c683453faa7f8218df094f90d9ad070a23"}}]}] BACKPORT-->
This commit is contained in:
Gerard Soldevila
GitHub
parent
4ba1a0ae0d
commit
6a6d3d61ca
106 changed files with 336 additions and 302 deletions
|
|
@ -33,7 +33,7 @@ type RequestHandler = (
|
|||
```
|
||||
and accepts next Kibana specific parameters as arguments:
|
||||
- context: [Context](https://github.com/elastic/kibana/blob/main/rfcs/text/0003_handler_interface.md#handler-context). A handler context contains core service and plugin functionality already scoped to the incoming request.
|
||||
- request: [KibanaRequest](https://github.com/elastic/kibana/blob/main/src/core/server/http/router/request.ts). An immutable representation of the incoming request details, such as body, parameters, query, url and route information. Note: you **must** to specify route schema during route declaration to have access to `body, parameters, query` in the request object. You cannot extend KibanaRequest with arbitrary data nor remove any properties from it.
|
||||
- request: [KibanaRequest](https://github.com/elastic/kibana/blob/main/src/core/packages/http/server/src/router/request.ts). An immutable representation of the incoming request details, such as body, parameters, query, url and route information. Note: you **must** to specify route schema during route declaration to have access to `body, parameters, query` in the request object. You cannot extend KibanaRequest with arbitrary data nor remove any properties from it.
|
||||
```typescript
|
||||
interface KibanaRequest {
|
||||
url: url.Url;
|
||||
|
|
@ -50,7 +50,7 @@ interface KibanaRequest {
|
|||
}
|
||||
}
|
||||
```
|
||||
- t: [KibanaResponseToolkit](https://github.com/elastic/kibana/blob/main/src/core/server/http/router/response.ts#L27)
|
||||
- t: [KibanaResponseToolkit](https://github.com/elastic/kibana/blob/main/src/core/packages/http/server/src/router/response.ts)
|
||||
Provides a set of pre-configured methods to respond to an incoming request. It is expected that handler **always** returns a result of one of `KibanaResponseToolkit` methods as an output:
|
||||
```typescript
|
||||
interface KibanaResponseToolkit {
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ A Bazel [macro](https://docs.bazel.build/versions/master/skylark/macros.html) wi
|
|||
|
||||
A Bazel [macro](https://docs.bazel.build/versions/master/skylark/macros.html) will be created to centralize the usage of Webpack. The macro will, at minimum, accept a configuration file and supply a base `webpack.config.js` file. Currently, all plugins share the same Webpack configuration. Allowing a plugin to provide additional configuration will allow plugins the ability to add loaders without affecting the performance of others.
|
||||
|
||||
While running Kibana from source in development, the proxy server will ensure that client-side code for plugins is compiled and available. This is currently handled by the [basePathProxy](https://github.com/elastic/kibana/blob/main/src/core/server/http/base_path_proxy_server.ts), where server restarts and optimizer builds are observed and cause the proxy to pause requests. With Bazel, we will utilize [iBazel](https://github.com/bazelbuild/bazel-watche) to watch for file changes and re-build the plugin targets when necessary. The watcher will emit [events](https://github.com/bazelbuild/bazel-watcher#remote-events) that we will use to block requests and provide feedback to the logs.
|
||||
While running Kibana from source in development, the proxy server will ensure that client-side code for plugins is compiled and available. This is currently handled by the [basePathProxy](https://github.com/elastic/kibana/blob/main/packages/kbn-cli-dev-mode/src/base_path_proxy/http1.ts), where server restarts and optimizer builds are observed and cause the proxy to pause requests. With Bazel, we will utilize [iBazel](https://github.com/bazelbuild/bazel-watche) to watch for file changes and re-build the plugin targets when necessary. The watcher will emit [events](https://github.com/bazelbuild/bazel-watcher#remote-events) that we will use to block requests and provide feedback to the logs.
|
||||
|
||||
While there are a few proofs of concepts for a Webpack 5 Bazel rule, none currently exist which are deemed production-ready. In the meantime, we can use the Webpack CLI directly. One of the main advantages being explored in these rules will be the support for using the Bazel worker to provide incremental builds similar to what `@kbn/optimizer` is doing today.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,11 +6,45 @@
|
|||
- [1. Summary](#1-summary)
|
||||
- [2. Motivation](#2-motivation)
|
||||
- [3. Detailed design](#3-detailed-design)
|
||||
- [3.1 Saved Objects Service](#31-saved-objects-service)
|
||||
- [3.1.1 Type registry](#311-type-registry)
|
||||
- [3.1.2 Schema](#312-schema)
|
||||
- [3.1.3 Saved Objects Client: Security wrapper](#313-saved-objects-client-security-wrapper)
|
||||
- [Attaching Access Controls](#attaching-access-controls)
|
||||
- [Authorization changes](#authorization-changes)
|
||||
- [3.2 Saved Objects API](#32-saved-objects-api)
|
||||
- [`get` / `bulk_get`](#get--bulk_get)
|
||||
- [Performance considerations](#performance-considerations)
|
||||
- [`create` / `bulk_create`](#create--bulk_create)
|
||||
- [Performance considerations](#performance-considerations-1)
|
||||
- [`update` / `bulk_update`](#update--bulk_update)
|
||||
- [Performance considerations](#performance-considerations-2)
|
||||
- [`delete`](#delete)
|
||||
- [Performance considerations](#performance-considerations-3)
|
||||
- [`find`](#find)
|
||||
- [Performance considerations](#performance-considerations-4)
|
||||
- [`addToNamespaces` / `deleteFromNamespaces`](#addtonamespaces--deletefromnamespaces)
|
||||
- [Performance considerations](#performance-considerations-5)
|
||||
- [3.3 Behavior with various plugin configurations](#33-behavior-with-various-plugin-configurations)
|
||||
- [Alternative](#alternative)
|
||||
- [3.4 Impacts on telemetry](#34-impacts-on-telemetry)
|
||||
- [4. Drawbacks](#4-drawbacks)
|
||||
- [5. Alternatives](#5-alternatives)
|
||||
- [5.1 Document level security](#51-document-level-security)
|
||||
- [5.2 Re-using the repository's pre-flight checks](#52-re-using-the-repositorys-pre-flight-checks)
|
||||
- [5.2.1 Move audit logging code into the repository](#521-move-audit-logging-code-into-the-repository)
|
||||
- [5.2.2 Pluggable authorization](#522-pluggable-authorization)
|
||||
- [5.2.3 Repository callbacks](#523-repository-callbacks)
|
||||
- [5.2.4 Pass down preflight objects](#524-pass-down-preflight-objects)
|
||||
- [6. Adoption strategy](#6-adoption-strategy)
|
||||
- [7. How we teach this](#7-how-we-teach-this)
|
||||
- [8. Unresolved questions](#8-unresolved-questions)
|
||||
- [8.1 `accessControl.owner`](#81-accesscontrolowner)
|
||||
- [8.2 Authorization for private objects](#82-authorization-for-private-objects)
|
||||
- [8.3 Behavior when security is disabled](#83-behavior-when-security-is-disabled)
|
||||
- [9. Resolved Questions](#9-resolved-questions)
|
||||
- [9.2 Authorization for private objects](#92-authorization-for-private-objects)
|
||||
- [9.3 Behavior when security is disabled](#93-behavior-when-security-is-disabled)
|
||||
|
||||
# 1. Summary
|
||||
|
||||
|
|
@ -38,7 +72,7 @@ Public (non-private) saved object types are not impacted by this RFC. This propo
|
|||
## 3.1 Saved Objects Service
|
||||
|
||||
### 3.1.1 Type registry
|
||||
The [saved objects type registry](https://github.com/elastic/kibana/blob/701697cc4a34d07c0508c3bdf01dca6f9d40a636/src/core/server/saved_objects/saved_objects_type_registry.ts) will allow consumers to register "private" saved object types via a new `accessClassification` property:
|
||||
The [saved objects type registry](https://github.com/elastic/kibana/blob/main/src/core/packages/saved-objects/base-server-internal/src/saved_objects_type_registry.ts) will allow consumers to register "private" saved object types via a new `accessClassification` property:
|
||||
|
||||
```ts
|
||||
/**
|
||||
|
|
@ -103,7 +137,7 @@ export interface SavedObject<T = unknown> {
|
|||
|
||||
### 3.1.3 Saved Objects Client: Security wrapper
|
||||
|
||||
The [security wrapper](https://github.com/elastic/kibana/blob/701697cc4a34d07c0508c3bdf01dca6f9d40a636/x-pack/plugins/security/server/saved_objects/secure_saved_objects_client_wrapper.ts) authorizes and audits operations against saved objects.
|
||||
The [security wrapper](https://github.com/elastic/kibana/blob/8.6/x-pack/plugins/security/server/saved_objects/secure_saved_objects_client_wrapper.ts) authorizes and audits operations against saved objects.
|
||||
|
||||
There are two primary changes to this wrapper:
|
||||
|
||||
|
|
@ -170,7 +204,7 @@ This overhead does not impact deleting "public" objects. We only need to retriev
|
|||
|
||||
|
||||
### `find`
|
||||
The security wrapper will supply or augment a [KQL `filter`](https://github.com/elastic/kibana/blob/701697cc4a34d07c0508c3bdf01dca6f9d40a636/src/core/server/saved_objects/types.ts#L118) which describes the objects the current user is authorized to see.
|
||||
The security wrapper will supply or augment a [KQL `filter`](https://github.com/elastic/kibana/blob/main/src/core/packages/saved-objects/api-server/src/apis/find.ts#L117) which describes the objects the current user is authorized to see.
|
||||
|
||||
```ts
|
||||
// Sample KQL filter
|
||||
|
|
|
|||
|
|
@ -9,14 +9,57 @@
|
|||
- [2. Motivation](#2-motivation)
|
||||
- [3. Architecture](#3-architecture)
|
||||
- [4. Testing](#4-testing)
|
||||
- [4.1 Local testing](#41-local-testing)
|
||||
- [4.1.1 Raw results](#411-raw-results)
|
||||
- [Non-clustered mode](#non-clustered-mode)
|
||||
- [Clustered mode, 2 workers](#clustered-mode-2-workers)
|
||||
- [Clustered mode, 4 workers](#clustered-mode-4-workers)
|
||||
- [4.1.2 Analysis](#412-analysis)
|
||||
- [4.2 Testing against cloud](#42-testing-against-cloud)
|
||||
- [5. Detailed design](#5-detailed-design)
|
||||
- [5.1 Enabling clustering mode](#51-enabling-clustering-mode)
|
||||
- [5.2 Cross-worker communication](#52-cross-worker-communication)
|
||||
- [5.3 Executing code on a single worker](#53-executing-code-on-a-single-worker)
|
||||
- [5.4 The node service API](#54-the-node-service-api)
|
||||
- [5.4.1 Example: Saved Object Migrations](#541-example-saved-object-migrations)
|
||||
- [5.5 Sharing state between workers](#55-sharing-state-between-workers)
|
||||
- [6. Technical impact](#6-technical-impact)
|
||||
- [6.1 Technical impact on Core](#6.1-technical-impact-on-core)
|
||||
- [6.2 Technical impact on Plugins](#6.2-technical-impact-on-plugins)
|
||||
- [6.3 Summary of breaking changes](#6.3-summary-of-breaking-changes)
|
||||
- [6.1 Technical impact on Core](#61-technical-impact-on-core)
|
||||
- [6.1.1 Handling multi-process logs](#611-handling-multi-process-logs)
|
||||
- [Options we considered:](#options-we-considered)
|
||||
- [Our recommended approach:](#our-recommended-approach)
|
||||
- [6.1.2 The rolling-file appender](#612-the-rolling-file-appender)
|
||||
- [Options we considered:](#options-we-considered-1)
|
||||
- [Our recommended approach:](#our-recommended-approach-1)
|
||||
- [6.1.3 The status API](#613-the-status-api)
|
||||
- [6.1.4 The stats API \& metrics service](#614-the-stats-api--metrics-service)
|
||||
- [Options we considered:](#options-we-considered-2)
|
||||
- [Our recommended approach:](#our-recommended-approach-2)
|
||||
- [6.1.5 PID file](#615-pid-file)
|
||||
- [6.1.6 Saved Objects migration](#616-saved-objects-migration)
|
||||
- [6.1.7 Memory consumption](#617-memory-consumption)
|
||||
- [6.1.8 Workers error handling](#618-workers-error-handling)
|
||||
- [6.1.9 Data folder](#619-data-folder)
|
||||
- [6.1.10 instanceUUID](#6110-instanceuuid)
|
||||
- [6.2 Technical impact on Plugins](#62-technical-impact-on-plugins)
|
||||
- [6.2.1 What types of things could break?](#621-what-types-of-things-could-break)
|
||||
- [Concurrent access to the same resources](#concurrent-access-to-the-same-resources)
|
||||
- [Using instanceUUID as a unique Kibana process identifier](#using-instanceuuid-as-a-unique-kibana-process-identifier)
|
||||
- [Things needing to run only once per Kibana instance](#things-needing-to-run-only-once-per-kibana-instance)
|
||||
- [6.2.2 Identified required changes](#622-identified-required-changes)
|
||||
- [Reporting](#reporting)
|
||||
- [Telemetry](#telemetry)
|
||||
- [Task Manager](#task-manager)
|
||||
- [Alerting](#alerting)
|
||||
- [6.3 Summary of breaking changes](#63-summary-of-breaking-changes)
|
||||
- [6.3.1 `/stats` API \& metrics service](#631-stats-api--metrics-service)
|
||||
- [7. Drawbacks](#7-drawbacks)
|
||||
- [8. Alternatives](#8-alternatives)
|
||||
- [9. Adoption strategy](#9-adoption-strategy)
|
||||
- [Phase 0](#phase-0)
|
||||
- [Phase 1](#phase-1)
|
||||
- [Phase 2](#phase-2)
|
||||
- [Phase 3](#phase-3)
|
||||
- [10. How we teach this](#10-how-we-teach-this)
|
||||
- [11. Unresolved questions](#11-unresolved-questions)
|
||||
- [12. Resolved questions](#12-resolved-questions)
|
||||
|
|
@ -571,7 +614,7 @@ Kibana instance, only one worker should have polling enabled.
|
|||
#### Reporting
|
||||
|
||||
We will probably want to restrict to a single headless per Kibana instance. For that, we will have to change the logic
|
||||
in [createQueueFactory](https://github.com/elastic/kibana/blob/4584a8b570402aa07832cf3e5b520e5d2cfa7166/x-pack/platform/plugins/private/reporting/server/lib/create_queue.ts#L60-L64)
|
||||
in [createQueueFactory](https://github.com/elastic/kibana/blob/4584a8b570402aa07832cf3e5b520e5d2cfa7166/x-pack/plugins/reporting/server/lib/create_queue.ts#L60-L64)
|
||||
to only have the 'main' worker be polling for reporting tasks.
|
||||
|
||||
#### Telemetry
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue