Merge branch 'master' into add-lists-permissions

docs/dev-tools/grokdebugger/index.asciidoc

@@ -32,7 +32,7 @@ in ingest node and Logstash.
 This example walks you through using the *Grok Debugger*. This tool
 is automatically enabled in {kib}. 
 
-NOTE: If you're using {security}, you must have the `manage_pipeline`
+NOTE: If you're using {stack-security-features}, you must have the `manage_pipeline`
 permission to use the Grok Debugger.
 
 . Open the menu, go to *Dev Tools*, then click *Grok Debugger*.

docs/settings/monitoring-settings.asciidoc

@@ -7,7 +7,7 @@
 
 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 {security}, you must be
+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.

docs/setup/install.asciidoc

@@ -53,8 +53,8 @@ Formulae are available from the Elastic Homebrew tap for installing {kib} on mac
 <<brew>>
 
 IMPORTANT: If your Elasticsearch installation is protected by
-{ref}/elasticsearch-security.html[{security}] see
-{kibana-ref}/using-kibana-with-security.html[Configuring security in Kibana] for
+{ref}/elasticsearch-security.html[{stack-security-features}] see
+{kibana-ref}/using-kibana-with-security.html[Configuring security in {kib}] for
 additional setup instructions.
 
 include::install/targz.asciidoc[]

docs/user/monitoring/monitoring-kibana.asciidoc

@@ -20,9 +20,10 @@ node in the production cluster. By default, it is is disabled (`false`).
 +
 --
 NOTE: You can specify this setting in either the `elasticsearch.yml` on each
-node or across the cluster as a dynamic cluster setting. If {es}
-{security-features} are enabled, you must have `monitor` cluster privileges to
-view the cluster settings and `manage` cluster privileges to change them.
+node or across the cluster as a dynamic cluster setting. If
+{stack-security-features} are enabled, you must have `monitor` cluster
+privileges to view the cluster settings and `manage` cluster privileges to
+change them.
 
 --
 
@@ -33,7 +34,7 @@ view the cluster settings and `manage` cluster privileges to change them.
 --
 By default, if you are running {kib} locally, go to `http://localhost:5601/`.
 
-If {es} {security-features} are enabled, log in.
+If {security-features} are enabled, log in.
 --
 
 ... Open the menu, then go to *Stack Monitoring*. If data collection is
@@ -80,13 +81,13 @@ monitoring cluster prevents production cluster outages from impacting your
 ability to access your monitoring data. It also prevents monitoring activities
 from impacting the performance of your production cluster.
 
-If {security} is enabled on the production cluster, use an HTTPS URL such
-as `https://<your_production_cluster>:9200` in this setting.
+If {security-features} are enabled on the production cluster, use an HTTPS
+URL such as `https://<your_production_cluster>:9200` in this setting.
 ===============================
 
 --
 
-. If the Elastic {security-features} are enabled on the production cluster:
+. If {security-features} are enabled on the production cluster:
 
 .. Verify that there is a
 valid user ID and password in the `elasticsearch.username` and

docs/user/reporting/chromium-sandbox.asciidoc

@@ -2,14 +2,16 @@
 [[reporting-chromium-sandbox]]
 === Chromium sandbox
 
-When {reporting} uses the Chromium browser for generating PDF reports, it's recommended to use the sandbox for
-an additional layer of security. The Chromium sandbox uses operating system provided mechanisms to ensure that
-code execution cannot make persistent changes to the computer or access confidential information. The specific
-sandboxing techniques differ for each operating system.
+When {report-features} uses the Chromium browser for generating PDF reports,
+it's recommended to use the sandbox for an additional layer of security. The
+Chromium sandbox uses operating system provided mechanisms to ensure that
+code execution cannot make persistent changes to the computer or access
+confidential information. The specific sandboxing techniques differ for each
+operating system.
 
 ==== Linux sandbox
 The Linux sandbox depends on user namespaces, which were introduced with the 3.8 Linux kernel. However, many
-distributions don't have user namespaces enabled by default, or they require the CAP_SYS_ADMIN capability. {reporting}
+distributions don't have user namespaces enabled by default, or they require the CAP_SYS_ADMIN capability. The {report-features}
 will automatically disable the sandbox when it is running on Debian and CentOS as additional steps are required to enable
 unprivileged usernamespaces. In these situations, you'll see the following message in your {kib} startup logs:
 `Chromium sandbox provides an additional layer of protection, but is not supported for your OS.

docs/user/reporting/configuring-reporting.asciidoc

@@ -2,18 +2,18 @@
 [[configuring-reporting]]
 == Reporting configuration
 
-You can configure settings in `kibana.yml` to control how {reporting}
-communicates with the {kib} server, manages background jobs, and captures
+You can configure settings in `kibana.yml` to control how the {report-features}
+communicate with the {kib} server, manages background jobs, and captures
 screenshots. See <<reporting-settings-kb, Reporting Settings>> for the complete
 list of settings.
 
 [float]
 [[encryption-keys]]
 === Encryption keys for multiple {kib} instances
 
-By default, a new encryption key is generated for {reporting} each time
-you start {kib}. This means if a static encryption key is not persisted in the
-{kib} configuration, any pending reports will fail when you restart {kib}.
+By default, a new encryption key is generated for the {report-features} each
+time you start {kib}. This means if a static encryption key is not persisted in
+the {kib} configuration, any pending reports will fail when you restart {kib}.
 
 If you are load balancing across multiple {kib} instances, they need to have
 the same reporting encryption key. Otherwise, report generation will fail if a

docs/user/reporting/development/index.asciidoc

@@ -1,9 +1,11 @@
 [role="xpack"]
 [[reporting-integration]]
 == Reporting integration
-Integrating a {kib} application with {reporting} requires a minimum amount of code, and the goal is to not have to
-modify the Reporting code as we add additional applications. Instead, applications abide by a contract that Reporting
-uses to determine the information that is required to export CSVs and PDFs.
+Integrating a {kib} application with the {report-features} requires a minimum
+amount of code, and the goal is to not have to modify the reporting code as we
+add additional applications. Instead, applications abide by a contract that
+{report-features} use to determine the information that is required to export
+CSVs and PDFs.
 
 [IMPORTANT]
 ==============================================
@@ -18,7 +20,7 @@ X-Pack uses the `share` plugin of the Kibana platform to register actions in the
 
 [float]
 === Generate job URL
-To generate a new {reporting} job, different export types require different `jobParams` that are Rison encoded into a URL
+To generate a new reporting job, different export types require different `jobParams` that are Rison encoded into a URL
 that abide by the following convention: `/api/reporting/generate?jobParams=${rison.encode(jobParams)}`. If you use the
 aforementioned <<reporting-nav-bar-extensions, nav bar extensions>> then this detail will be abstracted away, but if you
 provide a custom UI for generating the report, you will have to generate the URL and create a POST request to the URL.

docs/user/reporting/gs-index.asciidoc

@@ -21,7 +21,7 @@ You can also <<automating-report-generation,generate reports automatically>>.
 IMPORTANT: Reports are stored in the `.reporting-*` indices. Any user with
 access to these indices has access to every report generated by all users.
 
-To use {reporting} in a production environment,
+To use {report-features} in a production environment,
 <<securing-reporting,secure the Reporting endpoints>>.
 --
 

docs/user/reporting/index.asciidoc

@@ -19,7 +19,7 @@ image::user/reporting/images/share-button.png["Share"]
 [float]
 == Setup
 
-{reporting} is automatically enabled in {kib}. It runs a custom build of the Chromium web browser, which
+The {report-features} are automatically enabled in {kib}. It runs a custom build of the Chromium web browser, which
 runs on the server in headless mode to load {kib} and capture the rendered {kib} charts as images.
 
 Chromium is an open-source project not related to Elastic, but the Chromium binary for {kib} has been custom-built by Elastic to ensure it

docs/user/reporting/script-example.asciidoc

@@ -19,7 +19,8 @@ curl \
 // CONSOLE
 
 <1> `POST` method is required.
-<2> Provide user credentials for a user with permission to access Kibana and X-Pack reporting.
+<2> Provide user credentials for a user with permission to access Kibana and
+{report-features}.
 <3> The `kbn-version` header is required for all `POST` requests to Kibana.
 **The value must match the dotted-numeral version of the Kibana instance.**
 <4> The POST URL. You can copy and paste the URL for any report from the Kibana UI.

docs/user/reporting/watch-example.asciidoc

@@ -52,7 +52,7 @@ report from the Kibana UI.
 <3> Optional, default is 40
 <4> Optional, default is 15s
 <5> Provide user credentials for a user with permission to access Kibana and
-{reporting}.
+the {report-features}.
 //For more information, see <<secure-reporting>>.
 //<<reporting-app-users, Setting up a Reporting Role>>.
 

docs/user/security/reporting.asciidoc

@@ -5,8 +5,8 @@
 Reporting operates by creating and updating documents in {es} in response to
 user actions in {kib}.
 
-To use {reporting} with {security} enabled, you need to
-<<using-kibana-with-security,set up {kib} to work with {security}>>.
+To use {report-features} with {security-features} enabled, you need to
+<<using-kibana-with-security,configure security in {kib}>>.
 If you are automatically generating reports with
 {ref}/xpack-alerting.html[{watcher}], you also need to configure {watcher}
 to trust the {kib} server's certificate.
@@ -118,10 +118,10 @@ reporting_user:
 === Secure the reporting endpoints
 
 In a production environment, you should restrict access to
-the {reporting} endpoints to authorized users. This requires that you:
+the reporting endpoints to authorized users. This requires that you:
 
-. Enable {security} on your {es} cluster. For more information,
-see {ref}/security-getting-started.html[Getting Started with Security].
+. Enable {stack-security-features} on your {es} cluster. For more information,
+see {ref}/security-getting-started.html[Getting started with security].
 . Configure TLS/SSL encryption for the {kib} server. For more information, see
 <<configuring-tls>>.
 . Specify the {kib} server's CA certificate chain in `elasticsearch.yml`:
@@ -150,13 +150,13 @@ For more information, see {ref}/notification-settings.html#ssl-notification-sett
 --
 
 . Add one or more users who have the permissions
-necessary to use {kib} and {reporting}. For more information, see
+necessary to use {kib} and {report-features}. For more information, see
 <<secure-reporting>>.
 
-Once you've enabled SSL for {kib}, all requests to the {reporting} endpoints
+Once you've enabled SSL for {kib}, all requests to the reporting endpoints
 must include valid credentials. For example, see the following page which
 includes a watch that submits requests as the built-in `elastic` user:
 <<automating-report-generation>>.
 
 For more information about configuring watches, see
-{ref}/how-watcher-works.html[How Watcher works].
+{ref}/how-watcher-works.html[How {watcher} works].

docs/user/security/securing-kibana.asciidoc

@@ -5,21 +5,21 @@
 <titleabbrev>Configure security</titleabbrev>
 ++++
 
-{kib} users have to log in when {security} is enabled on your cluster. You
-configure {security} roles for your {kib} users to control what data those users
-can access.
+{kib} users have to log in when {stack-security-features} are enabled on your
+cluster. You configure roles for your {kib} users to control what data those
+users can access.
 
 Most requests made through {kib} to {es} are authenticated by using the
 credentials of the logged-in user. There are, however, a few internal requests
 that the {kib} server needs to make to the {es} cluster. For this reason, you
 must configure credentials for the {kib} server to use for those requests.
 
-With {security} enabled, if you load a {kib} dashboard that accesses data in an
-index that you are not authorized to view, you get an error that indicates the
-index does not exist. {security} do not currently provide a way to control which
-users can load which dashboards.
+With {security-features} enabled, if you load a {kib} dashboard that accesses
+data in an index that you are not authorized to view, you get an error that
+indicates the index does not exist. The {security-features} do not currently
+provide a way to control which users can load which dashboards.
 
-To use {kib} with {security}:
+To use {kib} with {security-features}:
 
 . {ref}/configuring-security.html[Configure security in {es}].
 
@@ -38,8 +38,8 @@ elasticsearch.password: "kibanapassword"
 The {kib} server submits requests as this user to access the cluster monitoring
 APIs and the `.kibana` index. The server does _not_ need access to user indices.
 
-The password for the built-in `kibana_system` user is typically set as part of the
-{security} configuration process on {es}. For more information, see
+The password for the built-in `kibana_system` user is typically set as part of
+the security configuration process on {es}. For more information, see
 {ref}/built-in-users.html[Built-in users].
 --
 
@@ -53,7 +53,7 @@ as the encryption key.
 xpack.security.encryptionKey: "something_at_least_32_characters"
 --------------------------------------------------------------------------------
 
-For more information, see <<security-settings-kb,Security Settings in {kib}>>.
+For more information, see <<security-settings-kb,Security settings in {kib}>>.
 --
 
 . Optional: Set a timeout to expire idle sessions. By default, a session stays

packages/kbn-dev-utils/src/index.ts

@@ -33,9 +33,9 @@ export {
   KBN_P12_PATH,
   KBN_P12_PASSWORD,
 } from './certs';
-export { run, createFailError, createFlagError, combineErrors, isFailError, Flags } from './run';
 export { REPO_ROOT } from './repo_root';
 export { KbnClient } from './kbn_client';
+export * from './run';
 export * from './axios';
 export * from './stdio';
 export * from './ci_stats_reporter';

packages/kbn-dev-utils/src/run/cleanup.ts

@@ -0,0 +1,94 @@
+/*
+ * Licensed to Elasticsearch B.V. under one or more contributor
+ * license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright
+ * ownership. Elasticsearch B.V. licenses this file to you under
+ * the Apache License, Version 2.0 (the "License"); you may
+ * not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *    http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import { inspect } from 'util';
+
+import exitHook from 'exit-hook';
+
+import { ToolingLog } from '../tooling_log';
+import { isFailError } from './fail';
+
+export type CleanupTask = () => void;
+
+export class Cleanup {
+  static setup(log: ToolingLog, helpText: string) {
+    const onUnhandledRejection = (error: any) => {
+      log.error('UNHANDLED PROMISE REJECTION');
+      log.error(
+        error instanceof Error
+          ? error
+          : new Error(`non-Error type rejection value: ${inspect(error)}`)
+      );
+      process.exit(1);
+    };
+
+    process.on('unhandledRejection', onUnhandledRejection);
+
+    const cleanup = new Cleanup(log, helpText, [
+      () => process.removeListener('unhandledRejection', onUnhandledRejection),
+    ]);
+
+    cleanup.add(exitHook(() => cleanup.execute()));
+
+    return cleanup;
+  }
+
+  constructor(
+    private readonly log: ToolingLog,
+    public helpText: string,
+    private readonly tasks: CleanupTask[]
+  ) {}
+
+  add(task: CleanupTask) {
+    this.tasks.push(task);
+  }
+
+  execute(topLevelError?: any) {
+    const tasks = this.tasks.slice(0);
+    this.tasks.length = 0;
+
+    for (const task of tasks) {
+      try {
+        task();
+      } catch (error) {
+        this.onError(error);
+      }
+    }
+
+    if (topLevelError) {
+      this.onError(topLevelError);
+    }
+  }
+
+  private onError(error: any) {
+    if (isFailError(error)) {
+      this.log.error(error.message);
+
+      if (error.showHelp) {
+        this.log.write(this.helpText);
+      }
+
+      process.exitCode = error.exitCode;
+    } else {
+      this.log.error('UNHANDLED ERROR');
+      this.log.error(error);
+      process.exitCode = 1;
+    }
+  }
+}