Merge branch 'master' into add-version-improve-types

Author: FrankHassanabad

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.