Merge branch '7.9' into backport/7.9/pr-72605

.backportrc.json

@@ -1,5 +1,33 @@
 {
   "upstream": "elastic/kibana",
-  "branches": [{ "name": "7.x", "checked": true }, "7.4", "7.3", "7.2", "7.1", "7.0", "6.8", "6.7", "6.6", "6.5", "6.4", "6.3", "6.2", "6.1", "6.0", "5.6"],
-  "labels": ["backport"]
+  "targetBranchChoices": [
+    { "name": "master", "checked": true },
+    { "name": "7.x", "checked": true },
+    "7.9",
+    "7.8",
+    "7.7",
+    "7.6",
+    "7.5",
+    "7.4",
+    "7.3",
+    "7.2",
+    "7.1",
+    "7.0",
+    "6.8",
+    "6.7",
+    "6.6",
+    "6.5",
+    "6.4",
+    "6.3",
+    "6.2",
+    "6.1",
+    "6.0",
+    "5.6"
+  ],
+  "targetPRLabels": ["backport"],
+  "branchLabelMapping": {
+    "^v8.0.0$": "master",
+    "^v7.10.0$": "7.x",
+    "^v(\\d+).(\\d+).\\d+$": "$1.$2"
+  }
 }

docs/api/using-api.asciidoc

@@ -45,10 +45,8 @@ For all APIs, you must use a request header. The {kib} APIs support the `kbn-xsr
   By default, you must use `kbn-xsrf` for all API calls, except in the following scenarios:
 
 * The API endpoint uses the `GET` or `HEAD` operations
-
-* The path is whitelisted using the <<settings, `server.xsrf.whitelist`>> setting
-
-* XSRF protections are disabled using the `server.xsrf.disableProtection` setting
+* The path is whitelisted using the <<settings-xsrf-whitelist, `server.xsrf.whitelist`>> setting
+* XSRF protections are disabled using the <<settings-xsrf-disableProtection, `server.xsrf.disableProtection`>> setting
 
 `Content-Type: application/json`::
   Applicable only when you send a payload in the API request. {kib} API requests and responses use JSON. Typically, if you include the `kbn-xsrf` header, you must also include the `Content-Type` header.

docs/apm/api.asciidoc

@@ -40,8 +40,8 @@ users interacting with APM APIs must have <<apm-app-api-user,sufficient privileg
   By default, you must use `kbn-xsrf` for all API calls, except in the following scenarios:
 
 * The API endpoint uses the `GET` or `HEAD` operations
-* The path is whitelisted using the <<settings, `server.xsrf.whitelist`>> setting
-* XSRF protections are disabled using the `server.xsrf.disableProtection` setting
+* The path is whitelisted using the <<settings-xsrf-whitelist, `server.xsrf.whitelist`>> setting
+* XSRF protections are disabled using the <<settings-xsrf-disableProtection, `server.xsrf.disableProtection`>> setting
 
 `Content-Type: application/json`::
   Applicable only when you send a payload in the API request.

docs/canvas/canvas-function-reference.asciidoc

@@ -13,7 +13,7 @@ A *** denotes a required argument.
 
 A † denotes an argument can be passed multiple times.
 
-<<a_fns>> | B | <<c_fns>> | <<d_fns>> | <<e_fns>> | <<f_fns>> | <<g_fns>> | <<h_fns>> | <<i_fns>> | <<j_fns>> | K | <<l_fns>> | <<m_fns>> | <<n_fns>> | O | <<p_fns>> | Q | <<r_fns>> | <<s_fns>> | <<t_fns>> | <<u_fns>> | V | W | X | Y | Z
+<<a_fns>> | B | <<c_fns>> | <<d_fns>> | <<e_fns>> | <<f_fns>> | <<g_fns>> | <<h_fns>> | <<i_fns>> | <<j_fns>> | K | <<l_fns>> | <<m_fns>> | <<n_fns>> | O | <<p_fns>> | Q | <<r_fns>> | <<s_fns>> | <<t_fns>> | <<u_fns>> | <<v_fns>> | W | X | Y | Z
 
 [float]
 [[a_fns]]
@@ -2871,3 +2871,56 @@ Default: `""`
 |===
 
 *Returns:* `string`
+
+[float]
+[[v_fns]]
+== V
+
+[float]
+[[var_fn]]
+=== `var`
+
+Updates the Kibana global context.
+
+*Accepts:* `any`
+
+[cols="3*^<"]
+|===
+|Argument |Type |Description
+
+|_Unnamed_ ***
+
+Alias: `name`
+|`string`
+|Specify the name of the variable.
+|===
+
+*Returns:* Depends on your input and arguments
+
+
+[float]
+[[var_set_fn]]
+=== `var_set`
+
+Updates the Kibana global context.
+
+*Accepts:* `any`
+
+[cols="3*^<"]
+|===
+|Argument |Type |Description
+
+|_Unnamed_ ***
+
+Alias: `name`
+|`string`
+|Specify the name of the variable.
+
+|`value`
+
+Alias: `val`
+|`any`
+|Specify the value for the variable. When unspecified, the input context is used.
+|===
+
+*Returns:* Depends on your input and arguments

docs/developer/architecture/security/index.asciidoc

@@ -1,7 +1,7 @@
 [[development-security]]
 === Security
 
-{kib} has generally been able to implement security transparently to core and plugin developers, and this largely remains the case. {kib} on two methods that the elasticsearch `Cluster` provides: `callWithRequest` and `callWithInternalUser`. 
+{kib} has generally been able to implement security transparently to core and plugin developers, and this largely remains the case. {kib} on two methods that the elasticsearch `Cluster` provides: `callWithRequest` and `callWithInternalUser`.
 
 `callWithRequest` executes requests against Elasticsearch using the authentication credentials of the {kib} end-user. So, if you log into {kib} with the user of `foo` when `callWithRequest` is used, {kib} execute the request against Elasticsearch as the user `foo`. Historically, `callWithRequest` has been used extensively to perform actions that are initiated at the request of {kib} end-users.
 

docs/developer/architecture/security/rbac.asciidoc

@@ -1,4 +1,5 @@
-[[development-security-rbac]]
+[discrete]
+[[development-rbac]]
 ==== Role-based access control
 
 Role-based access control (RBAC) in {kib} relies upon the
@@ -7,9 +8,10 @@ that Elasticsearch exposes. This allows {kib} to define the privileges that
 {kib} wishes to grant to users, assign them to the relevant users using roles,
 and then authorize the user to perform a specific action. This is handled within
 a secured instance of the `SavedObjectsClient` and available transparently to
-consumers when using `request.getSavedObjectsClient()` or 
+consumers when using `request.getSavedObjectsClient()` or
 `savedObjects.getScopedSavedObjectsClient()`.
 
+[discrete]
 [[development-rbac-privileges]]
 ===== {kib} Privileges
 
@@ -55,6 +57,7 @@ The application is created by concatenating the prefix of `kibana-` with the val
 
 ==============================================
 
+[discrete]
 [[development-rbac-assigning-privileges]]
 ===== Assigning {kib} Privileges
 
@@ -77,9 +80,10 @@ The application is created by concatenating the prefix of `kibana-` with the val
  }
 ----------------------------------
 
-Roles that grant <<kibana-privileges>> should be managed using the <<role-management-api>> or the *Management -> Security -> Roles* page, not directly using the {es} {ref}/security-api.html#security-role-apis[role management API]. This role can then be assigned to users using the {es} 
+Roles that grant <<kibana-privileges>> should be managed using the <<role-management-api>> or the *Management -> Security -> Roles* page, not directly using the {es} {ref}/security-api.html#security-role-apis[role management API]. This role can then be assigned to users using the {es}
 {ref}/security-api.html#security-user-apis[user management APIs].
 
+[discrete]
 [[development-rbac-authorization]]
 ===== Authorization
 

docs/developer/getting-started/index.asciidoc

@@ -30,7 +30,7 @@ you can switch to the correct version when using nvm by running:
 nvm use
 ----
 
-Install the latest version of https://yarnpkg.com[yarn].
+Install the latest version of https://classic.yarnpkg.com/en/docs/install[yarn v1].
 
 Bootstrap {kib} and install all the dependencies:
 

docs/development/core/server/kibana-plugin-core-server.savedobjectsbulkcreateobject.md

@@ -20,5 +20,4 @@ export interface SavedObjectsBulkCreateObject<T = unknown>
 |  [migrationVersion](./kibana-plugin-core-server.savedobjectsbulkcreateobject.migrationversion.md) | <code>SavedObjectsMigrationVersion</code> | Information about the migrations that have been applied to this SavedObject. When Kibana starts up, KibanaMigrator detects outdated documents and migrates them based on this value. For each migration that has been applied, the plugin's name is used as a key and the latest migration version as the value. |
 |  [references](./kibana-plugin-core-server.savedobjectsbulkcreateobject.references.md) | <code>SavedObjectReference[]</code> |  |
 |  [type](./kibana-plugin-core-server.savedobjectsbulkcreateobject.type.md) | <code>string</code> |  |
-|  [version](./kibana-plugin-core-server.savedobjectsbulkcreateobject.version.md) | <code>string</code> |  |
 

docs/development/core/server/kibana-plugin-core-server.savedobjectscreateoptions.md

@@ -20,5 +20,4 @@ export interface SavedObjectsCreateOptions extends SavedObjectsBaseOptions
 |  [overwrite](./kibana-plugin-core-server.savedobjectscreateoptions.overwrite.md) | <code>boolean</code> | Overwrite existing documents (defaults to false) |
 |  [references](./kibana-plugin-core-server.savedobjectscreateoptions.references.md) | <code>SavedObjectReference[]</code> |  |
 |  [refresh](./kibana-plugin-core-server.savedobjectscreateoptions.refresh.md) | <code>MutatingOperationRefreshSetting</code> | The Elasticsearch Refresh setting for this operation |
-|  [version](./kibana-plugin-core-server.savedobjectscreateoptions.version.md) | <code>string</code> | An opaque version number which changes on each successful write operation. Can be used in conjunction with <code>overwrite</code> for implementing optimistic concurrency control. |
 

docs/redirects.asciidoc

@@ -106,3 +106,8 @@ Watcher error reports have been removed and replaced with Kibana's <<apm-alerts,
 To create error alerts with new tool, select **Alerts** - **Create threshold alert** - **Error rate**.
 
 More information on this new feature is available in <<apm-alerts>>.
+
+[role="exclude",id="development-security-rbac"]
+== Role-based access control
+
+This content has moved to the <<development-rbac, Security>> page.

docs/settings/monitoring-settings.asciidoc

@@ -5,12 +5,12 @@
 <titleabbrev>Monitoring settings</titleabbrev>
 ++++
 
-By default, the Monitoring application is enabled, but data collection
-is disabled.  When you first start {kib} monitoring, you are prompted to
-enable data collection. If you are using {stack-security-features}, you must be
-signed in as a user with the `cluster:manage` privilege to enable
-data collection. The built-in `superuser` role has this privilege and the
-built-in `elastic` user has this role.
+By default, *{stack-monitor-app}* is enabled, but data collection is disabled.
+When you first start {kib} monitoring, you are prompted to enable data
+collection. If you are using {stack-security-features}, you must be signed in as
+a user with the `cluster:manage` privilege to enable data collection. The
+built-in `superuser` role has this privilege and the built-in `elastic` user has
+this role.
 
 You can adjust how monitoring data is
 collected from {kib} and displayed in {kib} by configuring settings in the
@@ -49,7 +49,7 @@ For more information, see
   in {kib}  to the {es} monitoring cluster and to verify licensing status on the {es}
   monitoring cluster. +
   +
-  Every other request performed by the Stack Monitoring UI to the monitoring {es}
+  Every other request performed by *{stack-monitor-app}* to the monitoring {es}
   cluster uses the authenticated user's credentials, which must be the same on
   both the {es} monitoring cluster and the {es} production cluster. +
   +
@@ -60,7 +60,7 @@ For more information, see
   in {kib}  to the {es} monitoring cluster and to verify licensing status on the {es}
   monitoring cluster. +
   +
-  Every other request performed by the Stack Monitoring UI to the monitoring {es}
+  Every other request performed by *{stack-monitor-app}* to the monitoring {es}
   cluster uses the authenticated user's credentials, which must be the same on
   both the {es} monitoring cluster and the {es} production cluster. +
   +
@@ -83,7 +83,7 @@ These settings control how data is collected from {kib}.
 |===
 | `monitoring.kibana.collection.enabled`
   | Set to `true` (default) to enable data collection from the {kib} NodeJS server
-  for {kib} Dashboards to be featured in the Monitoring.
+  for {kib} dashboards to be featured in *{stack-monitor-app}*.
 
 | `monitoring.kibana.collection.interval`
   | Specifies the number of milliseconds to wait in between data sampling on the
@@ -96,16 +96,26 @@ These settings control how data is collected from {kib}.
 [[monitoring-ui-settings]]
 ==== Monitoring UI settings
 
-These settings adjust how the {kib} Monitoring page displays monitoring data.
+These settings adjust how *{stack-monitor-app}* displays monitoring data.
 However, the defaults work best in most circumstances. For more information
 about configuring {kib}, see
-{kibana-ref}/settings.html[Setting Kibana Server Properties].
+{kibana-ref}/settings.html[Setting {kib} server properties].
 
 [cols="2*<"]
 |===
 | `monitoring.ui.elasticsearch.logFetchCount`
-  | Specifies the number of log entries to display in the Monitoring UI. Defaults to
-  `10`. The maximum value is `50`.
+  | Specifies the number of log entries to display in *{stack-monitor-app}*.
+  Defaults to `10`. The maximum value is `50`.
+
+| `monitoring.ui.enabled`
+  | Set to `false` to hide *{stack-monitor-app}*. The monitoring back-end
+    continues to run as an agent for sending {kib} stats to the monitoring
+    cluster. Defaults to `true`.
+
+| `monitoring.ui.logs.index`
+  | Specifies the name of the indices that are shown on the
+  <<logs-monitor-page,*Logs*>> page in *{stack-monitor-app}*. The default value
+  is `filebeat-*`.
 
 | `monitoring.ui.max_bucket_size`
   | Specifies the number of term buckets to return out of the overall terms list when
@@ -120,18 +130,13 @@ about configuring {kib}, see
   `monitoring.ui.collection.interval` in `elasticsearch.yml`, use the same
   value in this setting.
 
-| `monitoring.ui.enabled`
-  | Set to `false` to hide the Monitoring UI in {kib}. The monitoring back-end
-  continues to run as an agent for sending {kib} stats to the monitoring
-  cluster. Defaults to `true`.
-
 |===
 
 [float]
 [[monitoring-ui-cgroup-settings]]
 ===== Monitoring UI container settings
 
-The Monitoring UI exposes the Cgroup statistics that we collect for you to make
+*{stack-monitor-app}* exposes the Cgroup statistics that we collect for you to make
 better decisions about your container performance, rather than guessing based on
 the overall machine performance. If you are not running your applications in a
 container, then Cgroup statistics are not useful.

docs/setup/settings.asciidoc

@@ -571,7 +571,7 @@ all http requests to https over the port configured as `server.port`.
  | An array of supported protocols with versions.
 Valid protocols: `TLSv1`, `TLSv1.1`, `TLSv1.2`. *Default: TLSv1.1, TLSv1.2*
 
-| `server.xsrf.whitelist:`
+| [[settings-xsrf-whitelist]] `server.xsrf.whitelist:`
  | It is not recommended to disable protections for
 arbitrary API endpoints. Instead, supply the `kbn-xsrf` header.
 The `server.xsrf.whitelist` setting requires the following format:
@@ -586,6 +586,9 @@ The `server.xsrf.whitelist` setting requires the following format:
 [cols="2*<"]
 |===
 
+| [[settings-xsrf-disableProtection]] `server.xsrf.disableProtection:`
+ | Setting this to `true` will completely disable Cross-site request forgery protection in Kibana. This is not recommended. *Default: `false`*
+
 | `status.allowAnonymous:`
  | If authentication is enabled,
 setting this to `true` enables unauthenticated users to access the {kib}

packages/kbn-es/package.json

@@ -16,7 +16,7 @@
     "glob": "^7.1.2",
     "node-fetch": "^2.6.0",
     "simple-git": "^1.91.0",
-    "tar-fs": "^1.16.3",
+    "tar-fs": "^2.1.0",
     "tree-kill": "^1.2.2",
     "yauzl": "^2.10.0"
   }

packages/kbn-test/package.json

@@ -34,7 +34,7 @@
     "puppeteer": "^3.3.0",
     "rxjs": "^6.5.5",
     "strip-ansi": "^5.2.0",
-    "tar-fs": "^1.16.3",
+    "tar-fs": "^2.1.0",
     "tmp": "^0.1.0",
     "xml2js": "^0.4.22",
     "zlib": "^1.0.5"