[DOCS] Replaces X-Pack security terminology (#187)

Author: lcawl

docs/en/install-upgrade/upgrading-stack.asciidoc

@@ -202,7 +202,7 @@ You can also call the Elasticsearch migration APIs directly:
 nodes, and indices and returns a list of issues that need to be
 fixed before you can upgrade to {version}.
 +
-`/_xpack/migration/upgrade`:: Upgrades the Watcher and Security indices to a
+`/_xpack/migration/upgrade`:: Upgrades the indices for the {watcher} and {security-features} to a
 single-type format compatible with Elasticsearch 6.x.
 
 . Once you've resolved all of the migration issues, perform

docs/en/stack/security/authentication/built-in-users.asciidoc

@@ -2,10 +2,10 @@
 [[built-in-users]]
 === Built-in users
 
-{security} provides built-in user credentials to help you get up and running.
-These users have a fixed set of privileges and cannot be authenticated until their
-passwords have been set. The `elastic` user can be used to
-<<set-built-in-user-passwords,set all of the built-in user passwords>>.
+The {stack-security-features} provide built-in user credentials to help you get
+up and running. These users have a fixed set of privileges and cannot be
+authenticated until their passwords have been set. The `elastic` user can be
+used to <<set-built-in-user-passwords,set all of the built-in user passwords>>.
 
 `elastic`:: A built-in _superuser_. See <<built-in-roles>>.
 `kibana`:: The user Kibana uses to connect and communicate with Elasticsearch.
@@ -20,12 +20,11 @@ storing monitoring information in {es}. It has the `remote_monitoring_agent` and
 [float]
 [[built-in-user-explanation]]
 ==== How the built-in users work
-These built-in users are stored within a special `.security` index managed by
-{security}.
-This means that, if the password is changed, or a user is disabled, then that
-change is automatically reflected on each node in the cluster. It also means
-that if your `.security` index is deleted, or restored from a snapshot, then
-any changes you have applied will be lost.
+These built-in users are stored in a special `.security` index, which is managed
+by {es}. If a built-in user is disabled or its password
+changes, the change is automatically reflected on each node in the cluster. If
+your `.security` index is deleted or restored from a snapshot, however, any
+changes you have applied are lost.
 
 Although they share the same API, the built-in users are separate and distinct
 from users managed by the <<native-realm, native realm>>. Disabling the native

docs/en/stack/security/authentication/internal-users.asciidoc

@@ -2,8 +2,9 @@
 [[internal-users]]
 === Internal users
 
-{security} has three _internal_ users (`_system`, `_xpack`, and `_xpack_security`)
-that are responsible for the operations that take place inside an {es} cluster.
+The {stack-security-features} use three _internal_ users (`_system`, `_xpack`,
+and `_xpack_security`), which are responsible for the operations that take place
+inside an {es} cluster.
 
 These users are only used by requests that originate from within the cluster.
 For this reason, they cannot be used to authenticate against the API and there

docs/en/stack/security/authentication/overview.asciidoc

@@ -15,9 +15,10 @@ You can use the native support for managing and authenticating users, or
 integrate with external user management systems such as LDAP and Active
 Directory. 
 
-{security} provides built-in realms such as `native`,`ldap`, `active_directory`, 
-`pki`, `file`, and `saml`. If none of the built-in realms meet your needs, you 
-can also build your own custom realm and plug it into the {stack}. 
+The {stack-security-features} provide built-in realms such as `native`,`ldap`,
+`active_directory`, `pki`, `file`, and `saml`. If none of the built-in realms
+meet your needs, you can also build your own custom realm and plug it into the
+{stack}. 
 
 When {security-features} are enabled, depending on the realms you've configured,
 you must attach your user credentials to the requests sent to {es}. For example,

docs/en/stack/security/authorization/built-in-roles.asciidoc

@@ -2,13 +2,13 @@
 [[built-in-roles]]
 === Built-in roles
 
-{security} applies a default role to all users, including
+The {stack-security-features} apply a default role to all users, including
 <<anonymous-access, anonymous users>>. The default role enables users to access
 the authenticate endpoint, change their own passwords, and get information about
 themselves.
 
-{security} also provides a set of built-in roles you can explicitly assign
-to users. These roles have a fixed set of privileges and cannot be updated.
+There is also a set of built-in roles you can explicitly assign to users. These
+roles have a fixed set of privileges and cannot be updated.
 
 [[built-in-roles-apm-system]] `apm_system` ::
 Grants access necessary for the APM system user to send system-level data

docs/en/stack/security/authorization/overview.asciidoc

@@ -2,9 +2,8 @@
 [[authorization]]
 == User authorization
 
-{security} introduces the concept of _authorization_ to the {stack}.
-Authorization is the process of determining whether the user behind an incoming
-request is allowed to execute the request. 
+The {stack-security-features} add _authorization_, which is the process of determining whether the user behind an incoming request is allowed to execute
+the request. 
 
 This process takes place after the user is successfully identified and 
 <<setting-up-authentication,authenticated>>. 
@@ -13,9 +12,9 @@ This process takes place after the user is successfully identified and
 [float]
 === Role-based access control
 
-{security} provides a role-based access control (RBAC) mechanism, which enables 
-you to authorize users by assigning privileges to roles and assigning roles to 
-users or groups. 
+The {security-features} provide a role-based access control (RBAC) mechanism,
+which enables you to authorize users by assigning privileges to roles and
+assigning roles to users or groups. 
 
 image::security/authorization/images/authorization.png[This image illustrates role-based access control]
 
@@ -65,13 +64,12 @@ to authenticate users. For more information, see <<mapping-roles>>.
 [float]
 === Attribute-based access control
 
-{security} also provides an attribute-based access control (ABAC) mechanism, 
-which enables you to use attributes to restrict access to documents in search 
-queries and aggregations. For example, you can assign attributes to users and 
-documents, then implement an access policy in a role definition. Users with that 
-role can read a specific document only if they have all the required attributes. 
+The {security-features} also provide an attribute-based access control (ABAC)
+mechanism, which enables you to use attributes to restrict access to documents
+in search queries and aggregations. For example, you can assign attributes to
+users and documents, then implement an access policy in a role definition. Users
+with that role can read a specific document only if they have all the required
+attributes. 
 
 For more information, see 
 https://www.elastic.co/blog/attribute-based-access-control-with-xpack[Document-level attribute-based access control with X-Pack 6.1].
-
-//TO-DO: Add task related to configuring ABAC.

docs/en/stack/security/how-security-works.asciidoc

@@ -8,7 +8,8 @@ Kibana instances, Beats agents an clients, all communicating with the it.
 It should not come as a surprise that securing such clusters has many facets and
 layers.
 
-{security} provides the means to secure the Elastic cluster on several levels:
+The {stack-security-features} provide the means to secure the Elastic cluster
+on several levels:
 
   * <<setting-up-authentication,User authentication>>
   * <<authorization,User authorization and access control>>
@@ -18,20 +19,20 @@ layers.
 [float]
 === Node/client authentication and channel encryption
 
-{security} supports configuring SSL/TLS for securing the communication channels
-to, from and within the cluster. This support accounts for:
+The {security-features} support configuring SSL/TLS for securing the
+communication channels to, from and within the cluster. This support accounts for:
 
   * Encryption of data transmitted over the wires
   * Certificate based node authentication - preventing unauthorized nodes/clients
     from establishing a connection with the cluster.
 
 For more information, see <<encrypting-communications, Encrypting Communications>>.
 
-{security} also enables you to <<ip-filtering, configure IP Filters>> which can
-be seen as a light mechanism for node/client authentication. With IP Filtering
-you can restrict the nodes and clients that can connect to the cluster based
-on their IP addresses. The IP filters configuration provides whitelisting
-and blacklisting of IPs, subnets and DNS domains.
+The {security-features} also enable you to <<ip-filtering, configure IP Filters>>
+which can be seen as a light mechanism for node/client authentication. With IP
+filtering, you can restrict the nodes and clients that can connect to the
+cluster based on their IP addresses. The IP filters configuration provides
+whitelisting and blacklisting of IPs, subnets and DNS domains.
 
 
 [float]
@@ -41,9 +42,9 @@ mechanism set in place. Audit trails log various activities/events that occur in
 the system, enabling you to analyze and back track past events when things go
 wrong (e.g. security breach).
 
-{security} provides such audit trail functionality for all nodes in the cluster.
-You can configure the audit level which accounts for the type of events that are
-logged. These events include failed authentication attempts, user access denied,
-node connection denied, and more.
+The {security-features} provide such audit trail functionality for all nodes in
+the cluster. You can configure the audit level which accounts for the type of
+events that are logged. These events include failed authentication attempts,
+user access denied, node connection denied, and more.
 
 For more information on auditing see <<auditing>>.

docs/en/stack/security/index.asciidoc

@@ -4,8 +4,8 @@
 
 [partintro]
 --
-{security} enables you to easily secure a cluster. With {security},
-you can password-protect your data as well as implement more advanced security
+The {stack-security-features} enable you to easily secure a cluster. You can
+password-protect your data as well as implement more advanced security
 measures such as encrypting communications, role-based access control,
 IP filtering, and auditing. This guide describes how to configure the security
 features you need, and interact with your secured cluster.
@@ -21,53 +21,53 @@ Security protects Elasticsearch clusters by:
 
 [float]
 [[preventing-unauthorized-access]]
-=== Preventing Unauthorized Access
+=== Preventing unauthorized access
 
 To prevent unauthorized access to your Elasticsearch cluster, you must have a
 way to _authenticate_ users. This simply means that you need a way to validate
 that a user is who they claim to be. For example, you have to make sure only
-the person named _Kelsey Andorra_ can sign in as the user `kandorra`. {security} 
-provides a standalone authentication mechanism that enables you to
-quickly password-protect your cluster. If you're already using <<ldap-realm, LDAP>>,
-<<active-directory-realm, Active Directory>>, or <<pki-realm, PKI>> to manage
-users in your organization, {security} is able to integrate with those
-systems to perform user authentication.
+the person named _Kelsey Andorra_ can sign in as the user `kandorra`. The
+{es-security-features} provide a standalone authentication mechanism that enables
+you to quickly password-protect your cluster. If you're already using
+<<ldap-realm, LDAP>>, <<active-directory-realm, Active Directory>>, or
+<<pki-realm, PKI>> to manage users in your organization, the {security-features}
+are able to integrate with those systems to perform user authentication.
 
 In many cases, simply authenticating users isn't enough. You also need a way to
-control what data users have access to and what tasks they can perform. {security}
-enables you to _authorize_ users by assigning access _privileges_ to _roles_,
-and assigning those roles to users. For example, this
+control what data users have access to and what tasks they can perform. The
+{es-security-features} enable you to _authorize_ users by assigning access
+_privileges_ to _roles_ and assigning those roles to users. For example, this
 <<authorization,role-based access control>> mechanism (a.k.a RBAC) enables
 you to specify that the user `kandorra` can only perform read operations on the
 `events` index and can't do anything at all with other indices.
 
-{security} also supports <<ip-filtering, IP-based authorization>>. You can
-whitelist and blacklist specific IP addresses or subnets to control network-level
-access to a server.
+The {security-features} also support <<ip-filtering, IP-based authorization>>.
+You can whitelist and blacklist specific IP addresses or subnets to control
+network-level access to a server.
 
 [float]
 [[preserving-data-integrity]]
-=== Preserving Data Integrity
+=== Preserving data integrity
 
 A critical part of security is keeping confidential data confidential.
 Elasticsearch has built-in protections against accidental data loss and
 corruption. However, there's nothing to stop deliberate tampering or data
-interception. {security} preserves the integrity of your data by
-<<ssl-tls, encrypting communications>> to and from nodes.
-For even greater protection, you can increase the <<ciphers, encryption strength>> and
+interception. The {stack-security-features} preserve the integrity of your
+data by <<ssl-tls, encrypting communications>> to and from nodes. For even
+greater protection, you can increase the <<ciphers, encryption strength>> and
 <<separating-node-client-traffic, separate client traffic from node-to-node communications>>.
 
 
 [float]
 [[maintaining-audit-trail]]
-=== Maintaining an Audit Trail
+=== Maintaining an audit trail
 
-Keeping a system secure takes vigilance. By using {security} to maintain
-an audit trail, you can easily see who is accessing your cluster and what they're
-doing. By analyzing access patterns and failed attempts to access your cluster,
-you can gain insights into attempted attacks and data breaches. Keeping an
-auditable log of the activity in your cluster can also help diagnose operational
-issues.
+Keeping a system secure takes vigilance. By using {stack-security-features} to
+maintain an audit trail, you can easily see who is accessing your cluster and
+what they're doing. By analyzing access patterns and failed attempts to access
+your cluster, you can gain insights into attempted attacks and data breaches.
+Keeping an auditable log of the activity in your cluster can also help diagnose
+operational issues.
 
 [float]
 === Where to Go Next
@@ -80,8 +80,8 @@ issues.
   authorization, and encryption.
 
 * <<ccs-tribe-clients-integrations>>
-  shows you how to interact with an Elasticsearch cluster protected by
-  {security}.
+  shows you how to interact with an Elasticsearch cluster protected by the 
+  {stack-security-features}.
 
 [float]
 === Have Comments, Questions, or Feedback?

docs/en/stack/security/limitations.asciidoc

@@ -9,9 +9,9 @@ Elasticsearch's plugin infrastructure is extremely flexible in terms of what can
 be extended. While it opens up Elasticsearch to a wide variety of (often custom)
 additional functionality, when it comes to security, this high extensibility level
 comes at a cost. We have no control over the third-party plugins' code (open
-source or not) and therefore we cannot guarantee their compliance with {security}.
-For this reason, third-party plugins are not officially supported on clusters
-with {security-features} enabled.
+source or not) and therefore we cannot guarantee their compliance with
+{stack-security-features}. For this reason, third-party plugins are not
+officially supported on clusters with {security-features} enabled.
 
 [float]
 === Changes in index wildcard behavior
@@ -34,8 +34,10 @@ authorized to know anything about those indices.
 === Filtered index aliases
 
 Aliases containing filters are not a secure way to restrict access to individual
-documents, due to the limitations described in <<alias-limitations, Index and Field Names Can Be Leaked When Using Aliases>>.
-{security} provides a secure way to restrict access to documents through the
+documents, due to the limitations described in
+<<alias-limitations, Index and field names can be leaked when using aliases>>.
+The {stack-security-features} provide a secure way to restrict access to
+documents through the 
 <<field-and-document-access-control, document-level security>> feature.
 
 [float]