diff --git a/docs/reference/commands/certgen.asciidoc b/docs/reference/commands/certgen.asciidoc index 956a4637ed3..2ca489b3a60 100644 --- a/docs/reference/commands/certgen.asciidoc +++ b/docs/reference/commands/certgen.asciidoc @@ -51,7 +51,8 @@ keys for each instance. If you chose to generate a CA, which is the default behavior, the certificate and private key are included in the output file. If you chose to generate CSRs, you should provide them to your commercial or organization-specific certificate authority to obtain signed certificates. The -signed certificates must be in PEM format to work with {security}. +signed certificates must be in PEM format to work with the {stack} +{security-features}. [float] === Parameters diff --git a/docs/reference/commands/certutil.asciidoc b/docs/reference/commands/certutil.asciidoc index 4b04f95445e..06e9dc53bd9 100644 --- a/docs/reference/commands/certutil.asciidoc +++ b/docs/reference/commands/certutil.asciidoc @@ -93,7 +93,8 @@ the command produces a zip file containing the generated certificates and keys. The `csr` mode generates certificate signing requests (CSRs) that you can send to a trusted certificate authority to obtain signed certificates. The signed -certificates must be in PEM or PKCS#12 format to work with {security}. +certificates must be in PEM or PKCS#12 format to work with {es} +{security-features}. By default, the command produces a single CSR for a single instance. diff --git a/docs/reference/commands/setup-passwords.asciidoc b/docs/reference/commands/setup-passwords.asciidoc index e2d4dfdc13d..6e6d3dd75ed 100644 --- a/docs/reference/commands/setup-passwords.asciidoc +++ b/docs/reference/commands/setup-passwords.asciidoc @@ -19,8 +19,8 @@ bin/elasticsearch-setup-passwords auto|interactive [float] === Description -This command is intended for use only during the initial configuration of -{xpack}. It uses the +This command is intended for use only during the initial configuration of the +{es} {security-features}. It uses the {stack-ov}/built-in-users.html#bootstrap-elastic-passwords[`elastic` bootstrap password] to run user management API requests. After you set a password for the `elastic` user, the bootstrap password is no longer active and you cannot use this command. @@ -36,7 +36,7 @@ location, ensure that the *ES_PATH_CONF* environment variable returns the correct path before you run the `elasticsearch-setup-passwords` command. You can override settings in your `elasticsearch.yml` file by using the `-E` command option. For more information about debugging connection failures, see -{xpack-ref}/trb-security-setup.html[`elasticsearch-setup-passwords` command fails due to connection failure]. +{stack-ov}/trb-security-setup.html[`elasticsearch-setup-passwords` command fails due to connection failure]. [float] === Parameters diff --git a/docs/reference/licensing/update-license.asciidoc b/docs/reference/licensing/update-license.asciidoc index 56ef7acfd28..4dbe1eed655 100644 --- a/docs/reference/licensing/update-license.asciidoc +++ b/docs/reference/licensing/update-license.asciidoc @@ -40,12 +40,12 @@ https://www.elastic.co/subscriptions. [float] ==== Authorization -If {security} is enabled, you need `manage` cluster privileges to install the -license. +If {es} {security-features} are enabled, you need `manage` cluster privileges to +install the license. -If {security} is enabled and you are installing a gold or platinum license, you -must enable TLS on the transport networking layer before you install the license. -See <>. +If {es} {security-features} are enabled and you are installing a gold or platinum +license, you must enable TLS on the transport networking layer before you +install the license. See <>. [float] ==== Examples diff --git a/docs/reference/migration/migrate_7_0/api.asciidoc b/docs/reference/migration/migrate_7_0/api.asciidoc index 83370a93d55..3972be43685 100644 --- a/docs/reference/migration/migrate_7_0/api.asciidoc +++ b/docs/reference/migration/migrate_7_0/api.asciidoc @@ -88,10 +88,10 @@ When putting stored scripts, support for storing them with the deprecated `templ now removed. Scripts must be stored using the `script` context as mentioned in the documentation. [float] -==== Get Aliases API limitations when {security} is enabled removed +==== Removed Get Aliases API limitations when {security-features} are enabled The behavior and response codes of the get aliases API no longer vary -depending on whether {security} is enabled. Previously a +depending on whether {security-features} are enabled. Previously a 404 - NOT FOUND (IndexNotFoundException) could be returned in case the current user was not authorized for any alias. An empty response with status 200 - OK is now returned instead at all times. diff --git a/docs/reference/ml/apis/delete-job.asciidoc b/docs/reference/ml/apis/delete-job.asciidoc index b275ffafca7..753314dfd12 100644 --- a/docs/reference/ml/apis/delete-job.asciidoc +++ b/docs/reference/ml/apis/delete-job.asciidoc @@ -19,9 +19,9 @@ Deletes an existing anomaly detection job. All job configuration, model state and results are deleted. IMPORTANT: Deleting a job must be done via this API only. Do not delete the - job directly from the `.ml-*` indices using the Elasticsearch - DELETE Document API. When {security} is enabled, make sure no `write` - privileges are granted to anyone over the `.ml-*` indices. +job directly from the `.ml-*` indices using the Elasticsearch delete document +API. When {es} {security-features} are enabled, make sure no `write` privileges +are granted to anyone over the `.ml-*` indices. Before you can delete a job, you must delete the {dfeeds} that are associated with it. See <>. Unless the `force` parameter @@ -47,8 +47,9 @@ separated list. ==== Authorization -You must have `manage_ml`, or `manage` cluster privileges to use this API. -For more information, see {xpack-ref}/security-privileges.html[Security Privileges]. +If {es} {security-features} are enabled, you must have `manage_ml`, or `manage` +cluster privileges to use this API. +For more information, see {stack-ov}/security-privileges.html[Security Privileges]. ==== Examples diff --git a/docs/reference/ml/apis/preview-datafeed.asciidoc b/docs/reference/ml/apis/preview-datafeed.asciidoc index 4b903ddb8af..5116ba8e888 100644 --- a/docs/reference/ml/apis/preview-datafeed.asciidoc +++ b/docs/reference/ml/apis/preview-datafeed.asciidoc @@ -29,16 +29,17 @@ structure of the data that will be passed to the anomaly detection engine. ==== Authorization -You must have `monitor_ml`, `monitor`, `manage_ml`, or `manage` cluster -privileges to use this API. For more information, see -{xpack-ref}/security-privileges.html[Security Privileges]. +If {es} {security-features} are enabled, you must have `monitor_ml`, `monitor`, +`manage_ml`, or `manage` cluster privileges to use this API. For more +information, see +{stack-ov}/security-privileges.html[Security Privileges]. ==== Security Integration -When {security} is enabled, the {dfeed} query will be previewed using the -credentials of the user calling the preview {dfeed} API. When the {dfeed} -is started it will run the query using the roles of the last user to +When {es} {security-features} are enabled, the {dfeed} query is previewed using +the credentials of the user calling the preview {dfeed} API. When the {dfeed} +is started it runs the query using the roles of the last user to create or update it. If the two sets of roles differ then the preview may not accurately reflect what the {dfeed} will return when started. To avoid such problems, the same user that creates/updates the {dfeed} should preview diff --git a/docs/reference/ml/apis/put-datafeed.asciidoc b/docs/reference/ml/apis/put-datafeed.asciidoc index 5803cc03876..19998abec73 100644 --- a/docs/reference/ml/apis/put-datafeed.asciidoc +++ b/docs/reference/ml/apis/put-datafeed.asciidoc @@ -88,15 +88,16 @@ see <>. ==== Authorization -You must have `manage_ml`, or `manage` cluster privileges to use this API. -For more information, see -{xpack-ref}/security-privileges.html[Security Privileges]. +If {es} {security-features} are enabled, you must have `manage_ml`, or `manage` +cluster privileges to use this API. For more information, see +{stack-ov}/security-privileges.html[Security Privileges]. -==== Security Integration +==== Security integration -When {security} is enabled, your {dfeed} will remember which roles the user who -created it had at the time of creation, and run the query using those same roles. +When {es} {security-features} are enabled, your {dfeed} remembers which roles the +user who created it had at the time of creation and runs the query using those +same roles. ==== Examples diff --git a/docs/reference/ml/apis/start-datafeed.asciidoc b/docs/reference/ml/apis/start-datafeed.asciidoc index 790e4027b38..eb66660a695 100644 --- a/docs/reference/ml/apis/start-datafeed.asciidoc +++ b/docs/reference/ml/apis/start-datafeed.asciidoc @@ -77,16 +77,16 @@ of the latest processed record. ==== Authorization -You must have `manage_ml`, or `manage` cluster privileges to use this API. -For more information, see -{xpack-ref}/security-privileges.html[Security Privileges]. +If {es} {security-features} are enabled, you must have `manage_ml`, or `manage` +cluster privileges to use this API. For more information, see +{stack-ov}/security-privileges.html[Security Privileges]. -==== Security Integration +==== Security integration -When {security} is enabled, your {dfeed} will remember which roles the last -user to create or update it had at the time of creation/update, and run the query -using those same roles. +When {es} {security-features} are enabled, your {dfeed} remembers which roles the +last user to create or update it had at the time of creation/update and runs the +query using those same roles. ==== Examples diff --git a/docs/reference/ml/apis/update-datafeed.asciidoc b/docs/reference/ml/apis/update-datafeed.asciidoc index e8e0a94f596..9532679e5fc 100644 --- a/docs/reference/ml/apis/update-datafeed.asciidoc +++ b/docs/reference/ml/apis/update-datafeed.asciidoc @@ -79,15 +79,16 @@ see <>. ==== Authorization -You must have `manage_ml`, or `manage` cluster privileges to use this API. -For more information, see -{xpack-ref}/security-privileges.html[Security Privileges]. +If {es} {security-features} are enabled, you must have `manage_ml`, or `manage` +cluster privileges to use this API. For more information, see +{stack-ov}/security-privileges.html[Security Privileges]. ==== Security Integration -When {security} is enabled, your {dfeed} will remember which roles the user who -updated it had at the time of update, and run the query using those same roles. +When {es} {security-features} are enabled, your {dfeed} remembers which roles the +user who updated it had at the time of update and runs the query using those +same roles. ==== Examples diff --git a/docs/reference/monitoring/http-export.asciidoc b/docs/reference/monitoring/http-export.asciidoc index 4ba93f32637..fce22bd5d78 100644 --- a/docs/reference/monitoring/http-export.asciidoc +++ b/docs/reference/monitoring/http-export.asciidoc @@ -47,7 +47,7 @@ xpack.monitoring.exporters: uniquely defines the exporter but is otherwise unused. <3> `host` is a required setting for `http` exporters. It must specify the HTTP port rather than the transport port. The default port value is `9200`. -<4> User authentication for those using {security} or some other +<4> User authentication for those using {stack} {security-features} or some other form of user authentication protecting the cluster. <5> See <> for all TLS/SSL settings. If not supplied, the default node-level TLS/SSL settings are used. diff --git a/docs/reference/monitoring/local-export.asciidoc b/docs/reference/monitoring/local-export.asciidoc index 2bc757f07ec..821a6b1fc0e 100644 --- a/docs/reference/monitoring/local-export.asciidoc +++ b/docs/reference/monitoring/local-export.asciidoc @@ -47,10 +47,10 @@ a message indicating that they are waiting for the resources to be set up. One benefit of the `local` exporter is that it lives within the cluster and therefore no extra configuration is required when the cluster is secured with -{security}. All operations, including indexing operations, that occur from a -`local` exporter make use of the internal transport mechanisms within {es}. This -behavior enables the exporter to be used without providing any user credentials -when {security} is enabled. +{stack} {security-features}. All operations, including indexing operations, that +occur from a `local` exporter make use of the internal transport mechanisms +within {es}. This behavior enables the exporter to be used without providing any +user credentials when {security-features} are enabled. For more information about the configuration options for the `local` exporter, see <>. diff --git a/docs/reference/rest-api/defs.asciidoc b/docs/reference/rest-api/defs.asciidoc index 4eeedc55399..823b63cbe57 100644 --- a/docs/reference/rest-api/defs.asciidoc +++ b/docs/reference/rest-api/defs.asciidoc @@ -2,8 +2,8 @@ [[api-definitions]] == Definitions -These resource definitions are used in {ml} and {security} APIs and in {kib} -advanced {ml} job configuration options. +These resource definitions are used in APIs related to {ml-features} and +{security-features} and in {kib} advanced {ml} job configuration options. * <> * <> diff --git a/docs/reference/security/securing-communications/configuring-tls-docker.asciidoc b/docs/reference/security/securing-communications/configuring-tls-docker.asciidoc index e7e1a00208a..074ad03a968 100644 --- a/docs/reference/security/securing-communications/configuring-tls-docker.asciidoc +++ b/docs/reference/security/securing-communications/configuring-tls-docker.asciidoc @@ -1,8 +1,10 @@ [role="xpack"] [[configuring-tls-docker]] -=== Encrypting Communications in an {es} Docker Container +=== Encrypting communications in an {es} Docker Container -Starting with version 6.0.0, {security} (Gold, Platinum or Enterprise subscriptions) https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking-6.0.0-xes.html[requires SSL/TLS] +Starting with version 6.0.0, {stack} {security-features} +(Gold, Platinum or Enterprise subscriptions) +https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking-6.0.0-xes.html[require SSL/TLS] encryption for the transport networking layer. This section demonstrates an easy path to get started with SSL/TLS for both @@ -10,7 +12,7 @@ HTTPS and transport using the {es} Docker image. The example uses Docker Compose to manage the containers. For further details, please refer to -{xpack-ref}/encrypting-communications.html[Encrypting Communications] and +{stack-ov}/encrypting-communications.html[Encrypting communications] and https://www.elastic.co/subscriptions[available subscriptions]. [float] @@ -156,7 +158,7 @@ volumes: {"esdata_01": {"driver": "local"}, "esdata_02": {"driver": "local"}} <1> Bootstrap `elastic` with the password defined in `.env`. See {stack-ov}/built-in-users.html#bootstrap-elastic-passwords[the Elastic Bootstrap Password]. <2> Automatically generate and apply a trial subscription, in order to enable -{security}. +{security-features}. <3> Disable verification of authenticity for inter-node communication. Allows creating self-signed certificates without having to pin specific internal IP addresses. endif::[] diff --git a/docs/reference/security/securing-communications/enabling-cipher-suites.asciidoc b/docs/reference/security/securing-communications/enabling-cipher-suites.asciidoc index 38db8765427..51d5e5f6de6 100644 --- a/docs/reference/security/securing-communications/enabling-cipher-suites.asciidoc +++ b/docs/reference/security/securing-communications/enabling-cipher-suites.asciidoc @@ -16,8 +16,8 @@ The _JCE Unlimited Strength Jurisdiction Policy Files`_ are required for encryption with key lengths greater than 128 bits, such as 256-bit AES encryption. After installation, all cipher suites in the JCE are available for use but requires -configuration in order to use them. To enable the use of stronger cipher suites with -{security}, configure the `cipher_suites` parameter. See the +configuration in order to use them. To enable the use of stronger cipher suites +with {es} {security-features}, configure the `cipher_suites` parameter. See the {ref}/security-settings.html#ssl-tls-settings[Configuration Parameters for TLS/SSL] section of this document for specific parameter information. diff --git a/docs/reference/security/securing-communications/node-certificates.asciidoc b/docs/reference/security/securing-communications/node-certificates.asciidoc index 44ef8278fb9..b2f5e95b099 100644 --- a/docs/reference/security/securing-communications/node-certificates.asciidoc +++ b/docs/reference/security/securing-communications/node-certificates.asciidoc @@ -12,14 +12,12 @@ Additionally, it is recommended that the certificates contain subject alternativ names (SAN) that correspond to the node's IP address and DNS name so that hostname verification can be performed. -In order to simplify the process of generating certificates for the Elastic -Stack, a command line tool, {ref}/certutil.html[`elasticsearch-certutil`] has been -included with {xpack}. This tool takes care of generating a CA and signing -certificates with the CA. `elasticsearch-certutil` can be used interactively or -in a silent mode through the use of an input file. The `elasticsearch-certutil` -tool also supports generation of certificate signing requests (CSR), so that a -commercial- or organization-specific CA can be used to sign the certificates. -For example: +The {ref}/certutil.html[`elasticsearch-certutil`] command simplifies the process +of generating certificates for the {stack}. It takes care of generating a CA and +signing certificates with the CA. It can be used interactively or in a silent +mode through the use of an input file. It also supports generation of +certificate signing requests (CSR), so that a commercial- or +organization-specific CA can be used to sign the certificates. For example: . Optional: Create a certificate authority for your {es} cluster. + diff --git a/docs/reference/security/securing-communications/securing-elasticsearch.asciidoc b/docs/reference/security/securing-communications/securing-elasticsearch.asciidoc index 6b919e065c6..9d207f26a96 100644 --- a/docs/reference/security/securing-communications/securing-elasticsearch.asciidoc +++ b/docs/reference/security/securing-communications/securing-elasticsearch.asciidoc @@ -2,11 +2,13 @@ [[configuring-tls]] === Encrypting communications in {es} -{security} enables you to encrypt traffic to, from, and within your {es} cluster. -Connections are secured using Transport Layer Security (TLS/SSL). +{stack} {security-features} enable you to encrypt traffic to, from, and within +your {es} cluster. Connections are secured using Transport Layer Security +(TLS/SSL). WARNING: Clusters that do not have encryption enabled send all data in plain text -including passwords and will not be able to install a license that enables {security}. +including passwords and will not be able to install a license that enables +{security-features}. To enable encryption, you need to perform the following steps on each node in the cluster: @@ -27,7 +29,7 @@ information, see <>. <>. For more information about encrypting communications across the Elastic Stack, -see {xpack-ref}/encrypting-communications.html[Encrypting Communications]. +see {stack-ov}/encrypting-communications.html[Encrypting Communications]. :edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/docs/reference/security/securing-communications/node-certificates.asciidoc include::node-certificates.asciidoc[] diff --git a/docs/reference/security/securing-communications/separating-node-client-traffic.asciidoc b/docs/reference/security/securing-communications/separating-node-client-traffic.asciidoc index 5dd1620c0e4..e680c04cccd 100644 --- a/docs/reference/security/securing-communications/separating-node-client-traffic.asciidoc +++ b/docs/reference/security/securing-communications/separating-node-client-traffic.asciidoc @@ -3,7 +3,7 @@ === Separating node-to-node and client traffic Elasticsearch has the feature of so called {ref}/modules-transport.html[TCP transport profiles] -that allows it to bind to several ports and addresses. {security} extends on this +that allows it to bind to several ports and addresses. {es} {security-features} extends on this functionality to enhance the security of the cluster by enabling the separation of node-to-node transport traffic from client transport traffic. This is important if the client transport traffic is not trusted and could potentially be malicious. diff --git a/docs/reference/security/securing-communications/setting-up-ssl.asciidoc b/docs/reference/security/securing-communications/setting-up-ssl.asciidoc index ad2548f73f4..90f9b040d9d 100644 --- a/docs/reference/security/securing-communications/setting-up-ssl.asciidoc +++ b/docs/reference/security/securing-communications/setting-up-ssl.asciidoc @@ -1,12 +1,13 @@ [[ssl-tls]] -=== Setting Up TLS on a Cluster +=== Setting Up TLS on a cluster -{security} enables you to encrypt traffic to, from, and within your {es} -cluster. Connections are secured using Transport Layer Security (TLS), which is -commonly referred to as "SSL". +The {stack} {security-features} enables you to encrypt traffic to, from, and +within your {es} cluster. Connections are secured using Transport Layer Security +(TLS), which is commonly referred to as "SSL". WARNING: Clusters that do not have encryption enabled send all data in plain text -including passwords and will not be able to install a license that enables {security}. +including passwords and will not be able to install a license that enables +{security-features}. The following steps describe how to enable encryption across the various components of the Elastic Stack. You must perform each of the steps that are diff --git a/docs/reference/security/securing-communications/tls-ad.asciidoc b/docs/reference/security/securing-communications/tls-ad.asciidoc index cd0395b6725..48278f83365 100644 --- a/docs/reference/security/securing-communications/tls-ad.asciidoc +++ b/docs/reference/security/securing-communications/tls-ad.asciidoc @@ -5,7 +5,7 @@ To protect the user credentials that are sent for authentication, it's highly recommended to encrypt communications between {es} and your Active Directory server. Connecting via SSL/TLS ensures that the identity of the Active Directory -server is authenticated before {security} transmits the user credentials and the +server is authenticated before {es} transmits the user credentials and the usernames and passwords are encrypted in transit. Clients and nodes that connect via SSL/TLS to the Active Directory server need @@ -47,11 +47,11 @@ For more information about these settings, see <>. . Restart {es}. -NOTE: By default, when you configure {security} to connect to Active Directory - using SSL/TLS, {security} attempts to verify the hostname or IP address +NOTE: By default, when you configure {es} to connect to Active Directory + using SSL/TLS, it attempts to verify the hostname or IP address specified with the `url` attribute in the realm configuration with the values in the certificate. If the values in the certificate and realm - configuration do not match, {security} does not allow a connection to the + configuration do not match, {es} does not allow a connection to the Active Directory server. This is done to protect against man-in-the-middle attacks. If necessary, you can disable this behavior by setting the `ssl.verification_mode` property to `certificate`. diff --git a/docs/reference/security/securing-communications/tls-http.asciidoc b/docs/reference/security/securing-communications/tls-http.asciidoc index 06e70b03673..45129db0096 100644 --- a/docs/reference/security/securing-communications/tls-http.asciidoc +++ b/docs/reference/security/securing-communications/tls-http.asciidoc @@ -1,8 +1,8 @@ [role="xpack"] [[tls-http]] -==== Encrypting HTTP Client Communications +==== Encrypting HTTP Client communications -When {security} is enabled, you can optionally use TLS to ensure that +When {security-features} are enabled, you can optionally use TLS to ensure that communication between HTTP clients and the cluster is encrypted. NOTE: Enabling TLS on the HTTP layer is strongly recommended but is not required. diff --git a/docs/reference/security/securing-communications/tls-ldap.asciidoc b/docs/reference/security/securing-communications/tls-ldap.asciidoc index 2d7b2546bec..30b786b8e4c 100644 --- a/docs/reference/security/securing-communications/tls-ldap.asciidoc +++ b/docs/reference/security/securing-communications/tls-ldap.asciidoc @@ -5,7 +5,7 @@ To protect the user credentials that are sent for authentication in an LDAP realm, it's highly recommended to encrypt communications between {es} and your LDAP server. Connecting via SSL/TLS ensures that the identity of the LDAP server -is authenticated before {security} transmits the user credentials and the +is authenticated before {es} transmits the user credentials and the contents of the connection are encrypted. Clients and nodes that connect via TLS to the LDAP server need to have the LDAP server's certificate or the server's root CA certificate installed in their keystore or truststore. @@ -15,7 +15,7 @@ For more information, see <>. . Configure the realm's TLS settings on each node to trust certificates signed by the CA that signed your LDAP server certificates. The following example demonstrates how to trust a CA certificate, `cacert.pem`, located within the -{xpack} configuration directory: +{es} configuration directory (ES_PATH_CONF): + -- [source,shell] @@ -45,11 +45,11 @@ protocol and the secure port number. For example, `url: ldaps://ldap.example.com . Restart {es}. -NOTE: By default, when you configure {security} to connect to an LDAP server - using SSL/TLS, {security} attempts to verify the hostname or IP address +NOTE: By default, when you configure {es} to connect to an LDAP server + using SSL/TLS, it attempts to verify the hostname or IP address specified with the `url` attribute in the realm configuration with the values in the certificate. If the values in the certificate and realm - configuration do not match, {security} does not allow a connection to the + configuration do not match, {es} does not allow a connection to the LDAP server. This is done to protect against man-in-the-middle attacks. If necessary, you can disable this behavior by setting the `ssl.verification_mode` property to `certificate`. diff --git a/docs/reference/security/securing-communications/tls-transport.asciidoc b/docs/reference/security/securing-communications/tls-transport.asciidoc index c2306545536..fee775078d6 100644 --- a/docs/reference/security/securing-communications/tls-transport.asciidoc +++ b/docs/reference/security/securing-communications/tls-transport.asciidoc @@ -1,10 +1,10 @@ [role="xpack"] [[tls-transport]] -==== Encrypting Communications Between Nodes in a Cluster +==== Encrypting communications between nodes in a cluster The transport networking layer is used for internal communication between nodes -in a cluster. When {security} is enabled, you must use TLS to ensure that -communication between the nodes is encrypted. +in a cluster. When {security-features} are enabled, you must use TLS to ensure +that communication between the nodes is encrypted. . <>. diff --git a/docs/reference/settings/audit-settings.asciidoc b/docs/reference/settings/audit-settings.asciidoc index b7a3446ae96..d5515169840 100644 --- a/docs/reference/settings/audit-settings.asciidoc +++ b/docs/reference/settings/audit-settings.asciidoc @@ -161,9 +161,9 @@ xpack.security.audit.index.settings: -- NOTE: These settings apply to the local audit indices, as well as to the <>, but only if the remote cluster -does *not* have {security} installed, or the {es} versions are different. -If the remote cluster has {security} installed, and the versions coincide, the -settings for the audit indices there will take precedence, +does *not* have {security-features} enabled or the {es} versions are different. +If the remote cluster has {security-features} enabled and the versions coincide, +the settings for the audit indices there will take precedence, even if they are unspecified (i.e. left to defaults). -- diff --git a/docs/reference/settings/security-settings.asciidoc b/docs/reference/settings/security-settings.asciidoc index e97ad2edc77..28c30bf665c 100644 --- a/docs/reference/settings/security-settings.asciidoc +++ b/docs/reference/settings/security-settings.asciidoc @@ -90,9 +90,10 @@ access. Defaults to `true`. [float] [[security-automata-settings]] ==== Automata Settings -In places where {security} accepts wildcard patterns (e.g. index patterns in -roles, group matches in the role mapping API), each pattern is compiled into -an Automaton. The follow settings are available to control this behaviour. +In places where the {security-features} accept wildcard patterns (e.g. index +patterns in roles, group matches in the role mapping API), each pattern is +compiled into an Automaton. The follow settings are available to control this +behaviour. `xpack.security.automata.max_determinized_states`:: The upper limit on how many automaton states may be created by a single pattern. @@ -357,7 +358,7 @@ Defaults to `60s`. `group_search.base_dn`:: The container DN to search for groups in which the user has membership. When -this element is absent, {security} searches for the attribute specified by +this element is absent, {es} searches for the attribute specified by `user_group_attribute` set on the user in order to determine group membership. `group_search.scope`:: @@ -391,7 +392,7 @@ YAML role mapping configuration file]. Defaults to `ES_PATH_CONF/role_mapping.yml`. `follow_referrals`:: -Specifies whether {security} should follow referrals returned +Specifies whether {es} should follow referrals returned by the LDAP server. Referrals are URLs returned by the server that are to be used to continue the LDAP operation (for example, search). Defaults to `true`. @@ -517,7 +518,7 @@ The `type` setting must be set to `active_directory`. In addition to the the following settings: `url`:: -An LDAP URL of the form `ldap[s]://:`. {security} attempts to +An LDAP URL of the form `ldap[s]://:`. {es} attempts to authenticate against this URL. If the URL is not specified, it is derived from the `domain_name` setting and assumes an unencrypted connection to port 389. Defaults to `ldap://:389`. This setting is required when connecting @@ -756,7 +757,7 @@ this realm, so that it only supports user lookups. Defaults to `true`. `follow_referrals`:: -If set to `true` {security} follows referrals returned by the LDAP server. +If set to `true`, {es} follows referrals returned by the LDAP server. Referrals are URLs returned by the server that are to be used to continue the LDAP operation (such as `search`). Defaults to `true`. @@ -832,7 +833,7 @@ capabilities and configuration of the Identity Provider. If a path is provided, then it is resolved relative to the {es} config directory. If a URL is provided, then it must be either a `file` URL or a `https` URL. -{security} automatically polls this metadata resource and reloads +{es} automatically polls this metadata resource and reloads the IdP configuration when changes are detected. File based resources are polled at a frequency determined by the global {es} `resource.reload.interval.high` setting, which defaults to 5 seconds. @@ -864,24 +865,20 @@ The URL of the Single Logout service within {kib}. Typically this is the `https://kibana.example.com/logout`. `attributes.principal`:: -The Name of the SAML attribute that should be used as the {security} user's -principal (username). +The Name of the SAML attribute that contains the user's principal (username). `attributes.groups`:: -The Name of the SAML attribute that should be used to populate {security} -user's groups. +The Name of the SAML attribute that contains the user's groups. `attributes.name`:: -The Name of the SAML attribute that should be used to populate {security} -user's full name. +The Name of the SAML attribute that contains the user's full name. `attributes.mail`:: -The Name of the SAML attribute that should be used to populate {security} -user's email address. +The Name of the SAML attribute that contains the user's email address. `attributes.dn`:: -The Name of the SAML attribute that should be used to populate {security} -user's X.500 _Distinguished Name_. +The Name of the SAML attribute that contains the user's X.50 +_Distinguished Name_. `attribute_patterns.principal`:: A Java regular expression that is matched against the SAML attribute specified @@ -950,7 +947,7 @@ For more information, see ===== SAML realm signing settings If a signing key is configured (that is, either `signing.key` or -`signing.keystore.path` is set), then {security} signs outgoing SAML messages. +`signing.keystore.path` is set), then {es} signs outgoing SAML messages. Signing can be configured using the following settings: `signing.saml_messages`:: @@ -1001,7 +998,7 @@ Defaults to the keystore password. ===== SAML realm encryption settings If an encryption key is configured (that is, either `encryption.key` or -`encryption.keystore.path` is set), then {security} publishes an encryption +`encryption.keystore.path` is set), then {es} publishes an encryption certificate when generating metadata and attempts to decrypt incoming SAML content. Encryption can be configured using the following settings: @@ -1210,8 +1207,8 @@ through the list of URLs will continue until a successful connection is made. ==== Default TLS/SSL settings You can configure the following TLS/SSL settings in `elasticsearch.yml`. For more information, see -{stack-ov}/encrypting-communications.html[Encrypting communications]. These settings will be used -for all of {xpack} unless they have been overridden by more specific +{stack-ov}/encrypting-communications.html[Encrypting communications]. These +settings are used unless they have been overridden by more specific settings such as those for HTTP or Transport. `xpack.ssl.supported_protocols`:: @@ -1262,8 +1259,8 @@ Jurisdiction Policy Files_ has been installed, the default value also includes ` The following settings are used to specify a private key, certificate, and the trusted certificates that should be used when communicating over an SSL/TLS connection. -If none of the settings below are specified, this will default to the <>. If no trusted certificates are configured, the default certificates that are trusted by the JVM will be +If none of the settings below are specified, the +<> are used. If no trusted certificates are configured, the default certificates that are trusted by the JVM will be trusted along with the certificate(s) from the <>. The key and certificate must be in place for connections that require client authentication or when acting as a SSL enabled server. diff --git a/docs/reference/settings/ssl-settings.asciidoc b/docs/reference/settings/ssl-settings.asciidoc index 2d513c74237..1757cc481c3 100644 --- a/docs/reference/settings/ssl-settings.asciidoc +++ b/docs/reference/settings/ssl-settings.asciidoc @@ -110,7 +110,7 @@ Password to the truststore. ===== PKCS#12 Files -{security} can be configured to use PKCS#12 container files (`.p12` or `.pfx` files) +{es} can be configured to use PKCS#12 container files (`.p12` or `.pfx` files) that contain the private key, certificate and certificates that should be trusted. PKCS#12 files are configured in the same way as Java Keystore Files: @@ -148,7 +148,7 @@ Password to the PKCS#12 file. ===== PKCS#11 Tokens -{security} can be configured to use a PKCS#11 token that contains the private key, +{es} can be configured to use a PKCS#11 token that contains the private key, certificate and certificates that should be trusted. PKCS#11 token require additional configuration on the JVM level and can be enabled diff --git a/docs/reference/setup/bootstrap-checks-xes.asciidoc b/docs/reference/setup/bootstrap-checks-xes.asciidoc index eef6a30c94b..df020bbd962 100644 --- a/docs/reference/setup/bootstrap-checks-xes.asciidoc +++ b/docs/reference/setup/bootstrap-checks-xes.asciidoc @@ -21,11 +21,11 @@ on each node in the cluster. For more information, see === PKI realm check //See PkiRealmBootstrapCheckTests.java -If you use {security} and a Public Key Infrastructure (PKI) realm, you must -configure Transport Layer Security (TLS) on your cluster and enable client -authentication on the network layers (either transport or http). For more -information, see {xpack-ref}/pki-realm.html[PKI User Authentication] and -{xpack-ref}/ssl-tls.html[Setting Up TLS on a Cluster]. +If you use {es} {security-features} and a Public Key Infrastructure (PKI) realm, +you must configure Transport Layer Security (TLS) on your cluster and enable +client authentication on the network layers (either transport or http). For more +information, see {stack-ov}/pki-realm.html[PKI user authentication] and +{stack-ov}/ssl-tls.html[Setting up TLS on a cluster]. To pass this bootstrap check, if a PKI realm is enabled, you must configure TLS and enable client authentication on at least one network communication layer. @@ -42,7 +42,7 @@ and copy it to each node in the cluster. By default, role mappings are stored in `ES_PATH_CONF/role_mapping.yml`. Alternatively, you can specify a different role mapping file for each type of realm and specify its location in the `elasticsearch.yml` file. For more information, see -{xpack-ref}/mapping-roles.html#mapping-roles-file[Using Role Mapping Files]. +{stack-ov}/mapping-roles.html#mapping-roles-file[Using role mapping files]. To pass this bootstrap check, the role mapping files must exist and must be valid. The Distinguished Names (DNs) that are listed in the role mappings files @@ -54,24 +54,24 @@ must also be valid. //See TLSLicenseBootstrapCheck.java In 6.0 and later releases, if you have a gold, platinum, or enterprise license -and {security} is enabled, you must configure SSL/TLS for +and {es} {security-features} are enabled, you must configure SSL/TLS for internode-communication. NOTE: Single-node clusters that use a loopback interface do not have this requirement. For more information, see -{xpack-ref}/encrypting-communications.html[Encrypting Communications]. +{stack-ov}/encrypting-communications.html[Encrypting communications]. To pass this bootstrap check, you must -{xpack-ref}/ssl-tls.html[set up SSL/TLS in your cluster]. +{stack-ov}/ssl-tls.html[set up SSL/TLS in your cluster]. [float] === Token SSL check //See TokenSSLBootstrapCheckTests.java -If you use {security} and the built-in token service is enabled, you must -configure your cluster to use SSL/TLS for the HTTP interface. HTTPS is required -in order to use the token service. +If you use {es} {security-features} and the built-in token service is enabled, +you must configure your cluster to use SSL/TLS for the HTTP interface. HTTPS is +required in order to use the token service. In particular, if `xpack.security.authc.token.enabled` is set to `true` in the `elasticsearch.yml` file, you must also set @@ -79,4 +79,4 @@ set to `true` in the `elasticsearch.yml` file, you must also set settings, see <> and <>. To pass this bootstrap check, you must enable HTTPS or disable the built-in -token service by using the {security} settings. +token service. diff --git a/docs/reference/setup/install/windows.asciidoc b/docs/reference/setup/install/windows.asciidoc index 3f64698f334..46aadbc34a9 100644 --- a/docs/reference/setup/install/windows.asciidoc +++ b/docs/reference/setup/install/windows.asciidoc @@ -76,12 +76,18 @@ TIP: Ensure the installation machine has access to the internet and that any cor [[msi-installer-selected-plugins]] image::images/msi_installer/msi_installer_selected_plugins.png[] -As of version 6.3.0, X-Pack is now https://www.elastic.co/products/x-pack/open[bundled by default]. The final step allows a choice of the type of X-Pack license to install, in addition to security configuration and built-in user configuration: +As of version 6.3.0, {xpack} is now https://www.elastic.co/products/x-pack/open[bundled by default]. +The final step allows a choice of the type of license to install, in addition to +security configuration and built-in user configuration: [[msi-installer-xpack]] image::images/msi_installer/msi_installer_xpack.png[] -NOTE: X-Pack includes a choice of a Trial or Basic license. A Trial license is valid for 30 days, after which you can obtain one of the available subscriptions. The Basic license is free and perpetual. Consult the https://www.elastic.co/subscriptions[available subscriptions] for further details on which features are available under which license. +NOTE: {xpack} includes a choice of a Trial or Basic license. A Trial license is +valid for 30 days, after which you can obtain one of the available subscriptions. +The Basic license is free and perpetual. Consult the +https://www.elastic.co/subscriptions[available subscriptions] for further +details on which features are available under which license. After clicking the install button, the installation will begin: @@ -260,7 +266,8 @@ as _properties_ within Windows Installer documentation) that can be passed to `m `PLUGINS`:: - A comma separated list of the plugins to download and install as part of the installation. Defaults to `""` + A comma separated list of the plugins to download and install as part of the + installation. Defaults to `""` `HTTPSPROXYHOST`:: @@ -280,47 +287,47 @@ as _properties_ within Windows Installer documentation) that can be passed to `m `XPACKLICENSE`:: - The type of X-Pack license to install, either `Basic` or `Trial`. Defaults to `Basic` + The type of license to install, either `Basic` or `Trial`. Defaults to `Basic` `XPACKSECURITYENABLED`:: - When installing with a `Trial` license, whether X-Pack Security should be enabled. - Defaults to `true` + When installing with a `Trial` license, whether {security-features} are + enabled. Defaults to `true` `BOOTSTRAPPASSWORD`:: - When installing with a `Trial` license and X-Pack Security enabled, the password to - used to bootstrap the cluster and persisted as the `bootstrap.password` setting in the keystore. - Defaults to a randomized value. + When installing with a `Trial` license and {security-features} are enabled, + the password to used to bootstrap the cluster and persisted as the + `bootstrap.password` setting in the keystore. Defaults to a randomized value. `SKIPSETTINGPASSWORDS`:: - When installing with a `Trial` license and {security} enabled, whether the - installation should skip setting up the built-in users `elastic`, `kibana`, - `logstash_system`, `apm_system`, and `beats_system`. + When installing with a `Trial` license and {security-features} enabled, + whether the installation should skip setting up the built-in users. Defaults to `false` `ELASTICUSERPASSWORD`:: - When installing with a `Trial` license and X-Pack Security enabled, the password - to use for the built-in user `elastic`. Defaults to `""` + When installing with a `Trial` license and {security-features} are enabled, + the password to use for the built-in user `elastic`. Defaults to `""` `KIBANAUSERPASSWORD`:: - When installing with a `Trial` license and X-Pack Security enabled, the password - to use for the built-in user `kibana`. Defaults to `""` + When installing with a `Trial` license and {security-features} are enabled, + the password to use for the built-in user `kibana`. Defaults to `""` `LOGSTASHSYSTEMUSERPASSWORD`:: - When installing with a `Trial` license and X-Pack Security enabled, the password - to use for the built-in user `logstash_system`. Defaults to `""` + When installing with a `Trial` license and {security-features} are enabled, + the password to use for the built-in user `logstash_system`. Defaults to `""` -To pass a value, simply append the property name and value using the format `=""` to -the installation command. For example, to use a different installation directory to the default one and to install https://www.elastic.co/products/x-pack[X-Pack]: +To pass a value, simply append the property name and value using the format +`=""` to the installation command. For example, to use a +different installation directory to the default one: ["source","sh",subs="attributes,callouts"] -------------------------------------------- -start /wait msiexec.exe /i elasticsearch-{version}.msi /qn INSTALLDIR="C:\Custom Install Directory\{version}" PLUGINS="x-pack" +start /wait msiexec.exe /i elasticsearch-{version}.msi /qn INSTALLDIR="C:\Custom Install Directory\{version}" -------------------------------------------- Consult the https://msdn.microsoft.com/en-us/library/windows/desktop/aa367988(v=vs.85).aspx[Windows Installer SDK Command-Line Options] @@ -328,10 +335,10 @@ for additional rules related to values containing quotation marks. ifdef::include-xpack[] [[msi-installer-enable-indices]] -==== Enable automatic creation of X-Pack indices +==== Enable automatic creation of {xpack} indices -X-Pack will try to automatically create a number of indices within Elasticsearch. +The {stack} features try to automatically create a number of indices within {es}. include::xpack-indices.asciidoc[] endif::include-xpack[] diff --git a/docs/reference/setup/setup-xclient.asciidoc b/docs/reference/setup/setup-xclient.asciidoc index 4282264e395..819e3de98f4 100644 --- a/docs/reference/setup/setup-xclient.asciidoc +++ b/docs/reference/setup/setup-xclient.asciidoc @@ -111,5 +111,5 @@ Then in your project's `pom.xml` if using maven, add the following repositories -------------------------------------------------------------- -- -. If you are using {security}, there are more configuration steps. See -{xpack-ref}/java-clients.html[Java Client and Security]. +. If you are using {stack} {security-features}, there are more configuration +steps. See {stack-ov}/java-clients.html[Java Client and Security]. diff --git a/x-pack/docs/en/rest-api/security.asciidoc b/x-pack/docs/en/rest-api/security.asciidoc index ffc6c0baa3d..47fdcd34fde 100644 --- a/x-pack/docs/en/rest-api/security.asciidoc +++ b/x-pack/docs/en/rest-api/security.asciidoc @@ -2,7 +2,7 @@ [[security-api]] == Security APIs -You can use the following APIs to perform {security} activities. +You can use the following APIs to perform security activities. * <> * <> diff --git a/x-pack/docs/en/rest-api/security/role-mapping-resources.asciidoc b/x-pack/docs/en/rest-api/security/role-mapping-resources.asciidoc index be4afc57a1a..54581d4c721 100644 --- a/x-pack/docs/en/rest-api/security/role-mapping-resources.asciidoc +++ b/x-pack/docs/en/rest-api/security/role-mapping-resources.asciidoc @@ -63,7 +63,8 @@ The value specified in the field rule can be one of the following types: The _user object_ against which rules are evaluated has the following fields: `username`:: -(string) The username by which {security} knows this user. For example, `"username": "jsmith"`. +(string) The username by which the {es} {security-features} knows this user. For +example, `"username": "jsmith"`. `dn`:: (string) The _Distinguished Name_ of the user. For example, `"dn": "cn=jsmith,ou=users,dc=example,dc=com",`. `groups`:: diff --git a/x-pack/docs/en/rest-api/security/ssl.asciidoc b/x-pack/docs/en/rest-api/security/ssl.asciidoc index 69541af52b8..adc6c1b21b0 100644 --- a/x-pack/docs/en/rest-api/security/ssl.asciidoc +++ b/x-pack/docs/en/rest-api/security/ssl.asciidoc @@ -14,12 +14,12 @@ certificates that are used to encrypt communications in your {es} cluster. For more information about how certificates are configured in conjunction with Transport Layer Security (TLS), see -{xpack-ref}/ssl-tls.html[Setting up SSL/TLS on a cluster]. +{stack-ov}/ssl-tls.html[Setting up SSL/TLS on a cluster]. The API returns a list that includes certificates from all TLS contexts including: -* {xpack} default TLS settings +* Default {es} TLS settings * Settings for transport and HTTP interfaces * TLS settings that are used within authentication realms * TLS settings for remote monitoring exporters @@ -32,13 +32,13 @@ that are used for configuring server identity, such as `xpack.ssl.keystore` and The list does not include certificates that are sourced from the default SSL context of the Java Runtime Environment (JRE), even if those certificates are in -use within {xpack}. +use within {es}. NOTE: When a PKCS#11 token is configured as the truststore of the JRE, the API will return all the certificates that are included in the PKCS#11 token irrespectively to whether these are used in the {es} TLS configuration or not. -If {xpack} is configured to use a keystore or truststore, the API output +If {es} is configured to use a keystore or truststore, the API output includes all certificates in that store, even though some of the certificates might not be in active use within the cluster. @@ -56,16 +56,16 @@ single certificate. The fields in each object are: `subject_dn`:: (string) The Distinguished Name of the certificate's subject. `serial_number`:: (string) The hexadecimal representation of the certificate's serial number. -`has_private_key`:: (boolean) If {xpack} has access to the private key for this +`has_private_key`:: (boolean) If {es} has access to the private key for this certificate, this field has a value of `true`. `expiry`:: (string) The ISO formatted date of the certificate's expiry (not-after) date. ==== Authorization -If {security} is enabled, you must have `monitor` cluster privileges to use this -API. For more information, see -{xpack-ref}/security-privileges.html[Security Privileges]. +If the {security-features} are enabled, you must have `monitor` cluster +privileges to use this API. For more information, see +{stack-ov}/security-privileges.html[Security Privileges]. ==== Examples diff --git a/x-pack/docs/en/rest-api/watcher/delete-watch.asciidoc b/x-pack/docs/en/rest-api/watcher/delete-watch.asciidoc index 8a2fbd5a577..c009776645d 100644 --- a/x-pack/docs/en/rest-api/watcher/delete-watch.asciidoc +++ b/x-pack/docs/en/rest-api/watcher/delete-watch.asciidoc @@ -20,8 +20,9 @@ related to this watch from the watch history. IMPORTANT: Deleting a watch must be done via this API only. Do not delete the watch directly from the `.watches` index using the Elasticsearch - DELETE Document API. When {security} is enabled, make sure no `write` - privileges are granted to anyone over the `.watches` index. + DELETE Document API. When {es} {security-features} are enabled, make + sure no `write` privileges are granted to anyone over the `.watches` + index. [float] ==== Path Parameters diff --git a/x-pack/docs/en/rest-api/watcher/execute-watch.asciidoc b/x-pack/docs/en/rest-api/watcher/execute-watch.asciidoc index 926c1b87883..7fc2fe48051 100644 --- a/x-pack/docs/en/rest-api/watcher/execute-watch.asciidoc +++ b/x-pack/docs/en/rest-api/watcher/execute-watch.asciidoc @@ -56,7 +56,7 @@ This API supports the following fields: that will be used during the watch execution | `ignore_condition` | no | false | When set to `true`, the watch execution uses the - {xpack-ref}/condition-always.html[Always Condition]. + {stack-ov}/condition-always.html[Always Condition]. This can also be specified as an HTTP parameter. | `alternative_input` | no | null | When present, the watch uses this object as a payload @@ -73,7 +73,7 @@ This API supports the following fields: This can also be specified as an HTTP parameter. | `watch` | no | null | When present, this - {xpack-ref}/how-watcher-works.html#watch-definition[watch] is used + {stack-ov}/how-watcher-works.html#watch-definition[watch] is used instead of the one specified in the request. This watch is not persisted to the index and record_execution cannot be set. |====== @@ -91,7 +91,7 @@ are five possible modes an action can be associated with: | `simulate` | The action execution is simulated. Each action type define its own simulation operation mode. For example, the - {xpack-ref}/actions-email.html[email] action creates + {stack-ov}/actions-email.html[email] action creates the email that would have been sent but does not actually send it. In this mode, the action might be throttled if the current state of the watch indicates it should be. @@ -116,14 +116,14 @@ are five possible modes an action can be associated with: [float] ==== Authorization You must have `manage_watcher` cluster privileges to use this API. For more -information, see {xpack-ref}/security-privileges.html[Security Privileges]. +information, see {stack-ov}/security-privileges.html[Security Privileges]. [float] ==== Security Integration -When {security} is enabled on your Elasticsearch cluster, then watches will be -executed with the privileges of the user that stored the watches. If your user -is allowed to read index `a`, but not index `b`, then the exact same set of +When {es} {security-features} are enabled on your cluster, watches +are executed with the privileges of the user that stored the watches. If your +user is allowed to read index `a`, but not index `b`, then the exact same set of rules will apply during execution of a watch. When using the execute watch API, the authorization data of the user that diff --git a/x-pack/docs/en/rest-api/watcher/put-watch.asciidoc b/x-pack/docs/en/rest-api/watcher/put-watch.asciidoc index 8026d2e565d..61f53ea9edb 100644 --- a/x-pack/docs/en/rest-api/watcher/put-watch.asciidoc +++ b/x-pack/docs/en/rest-api/watcher/put-watch.asciidoc @@ -20,8 +20,8 @@ trigger engine. IMPORTANT: Putting a watch must be done via this API only. Do not put a watch directly to the `.watches` index using the Elasticsearch Index API. - If {security} is enabled, make sure no `write` privileges are - granted to anyone over the `.watches` index. + If {es} {security-features} are enabled, make sure no `write` + privileges are granted to anyone over the `.watches` index. When adding a watch you can also define its initial {xpack-ref}/how-watcher-works.html#watch-active-state[active state]. You do that @@ -77,9 +77,9 @@ information, see {xpack-ref}/security-privileges.html[Security Privileges]. [float] ==== Security Integration -When {security} is enabled, your watch will only be able to index or search on -indices for which the user that stored the watch, has privileges. If the user is -able to read index `a`, but not index `b`, the same will apply, when the watch +When {es} {security-features} are enabled, your watch can index or search only +on indices for which the user that stored the watch has privileges. If the user +is able to read index `a`, but not index `b`, the same will apply, when the watch is executed. [float] diff --git a/x-pack/docs/en/security/auditing/event-types.asciidoc b/x-pack/docs/en/security/auditing/event-types.asciidoc index e2d71912ba9..442877f31b5 100644 --- a/x-pack/docs/en/security/auditing/event-types.asciidoc +++ b/x-pack/docs/en/security/auditing/event-types.asciidoc @@ -29,7 +29,7 @@ The following is a list of the events that can be generated: | `run_as_denied` | | | Logged when an authenticated user attempts to <> another user action they do not have the necessary <> to do so. -| `tampered_request` | | | Logged when {security} detects that the request has +| `tampered_request` | | | Logged when the {security-features} detect that the request has been tampered with. Typically relates to `search/scroll` requests when the scroll ID is believed to have been tampered with. diff --git a/x-pack/docs/en/security/auditing/output-index.asciidoc b/x-pack/docs/en/security/auditing/output-index.asciidoc index 1c59762ea2a..0d4ea3cc6fc 100644 --- a/x-pack/docs/en/security/auditing/output-index.asciidoc +++ b/x-pack/docs/en/security/auditing/output-index.asciidoc @@ -38,9 +38,9 @@ xpack.security.audit.index.settings: These settings apply to the local audit indices, as well as to the <>, but only if the remote cluster -does *not* have {security} installed, or the {es} versions are different. -If the remote cluster has {security} installed, and the versions coincide, the -settings for the audit indices there will take precedence, +does *not* have {security-features} enabled or the {es} versions are different. +If the remote cluster has {security-features} enabled and the versions coincide, +the settings for the audit indices there will take precedence, even if they are unspecified (i.e. left to defaults). NOTE: Audit events are batched for indexing so there is a lag before diff --git a/x-pack/docs/en/security/auditing/overview.asciidoc b/x-pack/docs/en/security/auditing/overview.asciidoc index 6f04e17d831..8248bcb0824 100644 --- a/x-pack/docs/en/security/auditing/overview.asciidoc +++ b/x-pack/docs/en/security/auditing/overview.asciidoc @@ -13,7 +13,7 @@ Audit logs are **disabled** by default. To enable this functionality, you must set `xpack.security.audit.enabled` to `true` in `elasticsearch.yml`. ============================================================================ -{Security} provides two ways to persist audit logs: +The {es} {security-features} provide two ways to persist audit logs: * The <> output, which persists events to a dedicated `_audit.log` file on the host's file system. diff --git a/x-pack/docs/en/security/authentication/configuring-active-directory-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-active-directory-realm.asciidoc index dd2412c7e2d..ab08bb4aaae 100644 --- a/x-pack/docs/en/security/authentication/configuring-active-directory-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-active-directory-realm.asciidoc @@ -2,13 +2,12 @@ [[configuring-ad-realm]] === Configuring an Active Directory realm -You can configure {security} to communicate with Active Directory to authenticate +You can configure {es} to communicate with Active Directory to authenticate users. To integrate with Active Directory, you configure an `active_directory` -realm and map Active Directory users and groups to {security} roles in the role -mapping file. +realm and map Active Directory users and groups to roles in the role mapping file. For more information about Active Directory realms, see -{xpack-ref}/active-directory-realm.html[Active Directory User Authentication]. +{stack-ov}/active-directory-realm.html[Active Directory User Authentication]. . Add a realm configuration of type `active_directory` to `elasticsearch.yml` under the `xpack.security.authc.realms.active_directory` namespace. @@ -25,7 +24,7 @@ NOTE: Binding to Active Directory fails if the domain name is not mapped in DNS. If DNS is not being provided by a Windows DNS server, add a mapping for the domain in the local `/etc/hosts` file. -For example, the following realm configuration configures {security} to connect +For example, the following realm configuration configures {es} to connect to `ldaps://example.com:636` to authenticate users through Active Directory: [source, yaml] @@ -60,7 +59,7 @@ You must also set the `url` setting, since you must authenticate against the Global Catalog, which uses a different port and might not be running on every Domain Controller. -For example, the following realm configuration configures {security} to connect +For example, the following realm configuration configures {es} to connect to specific Domain Controllers on the Global Catalog port with the domain name set to the forest root: @@ -96,7 +95,7 @@ ports (389 or 636) in order to query the configuration container to retrieve the domain name from the NetBIOS name. -- -. (Optional) Configure how {security} should interact with multiple Active +. (Optional) Configure how {es} should interact with multiple Active Directory servers. + -- @@ -113,14 +112,14 @@ operation are supported: failover and load balancing. See <>. + -- The Active Directory realm authenticates users using an LDAP bind request. By -default, all of the LDAP operations are run by the user that {security} is +default, all of the LDAP operations are run by the user that {es} is authenticating. In some cases, regular users may not be able to access all of the necessary items within Active Directory and a _bind user_ is needed. A bind user can be configured and is used to perform all operations other than the LDAP bind request, which is required to authenticate the credentials provided by the user. The use of a bind user enables the -{xpack-ref}/run-as-privilege.html[run as feature] to be used with the Active +{stack-ov}/run-as-privilege.html[run as feature] to be used with the Active Directory realm and the ability to maintain a set of pooled connections to Active Directory. These pooled connection reduce the number of resources that must be created and destroyed with every user authentication. @@ -235,7 +234,7 @@ user: <4> The Active Directory distinguished name (DN) of the user `John Doe`. For more information, see -{xpack-ref}/mapping-roles.html[Mapping users and groups to roles]. +{stack-ov}/mapping-roles.html[Mapping users and groups to roles]. -- . (Optional) Configure the `metadata` setting in the Active Directory realm to diff --git a/x-pack/docs/en/security/authentication/configuring-file-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-file-realm.asciidoc index ac596c11e0e..df92442507f 100644 --- a/x-pack/docs/en/security/authentication/configuring-file-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-file-realm.asciidoc @@ -76,7 +76,8 @@ required changes. IMPORTANT: As the administrator of the cluster, it is your responsibility to ensure the same users are defined on every node in the cluster. - {security} does not deliver any mechanism to guarantee this. + The {es} {security-features} do not deliver any mechanisms to + guarantee this. -- @@ -103,7 +104,7 @@ the same changes are made on every node in the cluster. . (Optional) Change how often the `users` and `users_roles` files are checked. + -- -By default, {security} checks these files for changes every 5 seconds. You can +By default, {es} checks these files for changes every 5 seconds. You can change this default behavior by changing the `resource.reload.interval.high` setting in the `elasticsearch.yml` file (as this is a common setting in {es}, changing its value may effect other schedules in the system). diff --git a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc index 4f050cf937f..184fc762093 100644 --- a/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-pki-realm.asciidoc @@ -2,15 +2,14 @@ [[configuring-pki-realm]] === Configuring a PKI realm -You can configure {security} to use Public Key Infrastructure (PKI) certificates -to authenticate users in {es}. This requires clients to present X.509 -certificates. +You can configure {es} to use Public Key Infrastructure (PKI) certificates +to authenticate users. This requires clients to present X.509 certificates. NOTE: You cannot use PKI certificates to authenticate users in {kib}. To use PKI in {es}, you configure a PKI realm, enable client authentication on the desired network layers (transport or http), and map the Distinguished Names -(DNs) from the user certificates to {security} roles in the +(DNs) from the user certificates to roles in the <> or role-mapping file. You can also use a combination of PKI and username/password authentication. For @@ -22,7 +21,7 @@ allow clients without certificates to authenticate with other credentials. IMPORTANT: You must enable SSL/TLS and enable client authentication to use PKI. -For more information, see {xpack-ref}/pki-realm.html[PKI User Authentication]. +For more information, see {stack-ov}/pki-realm.html[PKI User Authentication]. . Add a realm configuration for a `pki` realm to `elasticsearch.yml` under the `xpack.security.authc.realms.pki` namespace. @@ -75,8 +74,7 @@ xpack: . Enable client authentication on the desired network layers (transport or http). + -- -//TBD: This step might need to be split into a separate topic with additional details -//about setting up client authentication. + The PKI realm relies on the TLS settings of the node's network interface. The realm can be configured to be more restrictive than the underlying network connection - that is, it is possible to configure the node such that some @@ -174,7 +172,7 @@ the result. The user's distinguished name will be populated under the `pki_dn` key. You can also use the authenticate API to validate your role mapping. For more information, see -{xpack-ref}/mapping-roles.html[Mapping Users and Groups to Roles]. +{stack-ov}/mapping-roles.html[Mapping Users and Groups to Roles]. NOTE: The PKI realm supports {stack-ov}/realm-chains.html#authorization_realms[authorization realms] as an diff --git a/x-pack/docs/en/security/authentication/configuring-saml-realm.asciidoc b/x-pack/docs/en/security/authentication/configuring-saml-realm.asciidoc index 81859c4fd04..35f79b16d45 100644 --- a/x-pack/docs/en/security/authentication/configuring-saml-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/configuring-saml-realm.asciidoc @@ -101,7 +101,7 @@ introduction to realms, see {stack-ov}/realms.html[Realms]. It is recommended that the SAML realm be at the bottom of your authentication chain (that is, it has the _highest_ order). <4> This is the path to the metadata file that you saved for your identity provider. -The path that you enter here is relative to your `config/` directory. {security} +The path that you enter here is relative to your `config/` directory. {es} automatically monitors this file for changes and reloads the configuration whenever it is updated. <5> This is the identifier (SAML EntityID) that your IdP uses. It should match @@ -218,8 +218,8 @@ When a user authenticates using SAML, they are identified to the {stack}, but this does not automatically grant them access to perform any actions or access any data. -Your SAML users cannot do anything until they are mapped to {security} -roles. See {stack-ov}/saml-role-mapping.html[Configuring role mappings]. +Your SAML users cannot do anything until they are mapped to roles. See +{stack-ov}/saml-role-mapping.html[Configuring role mappings]. NOTE: The SAML realm supports {stack-ov}/realm-chains.html#authorization_realms[authorization realms] as an diff --git a/x-pack/docs/en/security/authentication/custom-realm.asciidoc b/x-pack/docs/en/security/authentication/custom-realm.asciidoc index 43a61953855..3985e745704 100644 --- a/x-pack/docs/en/security/authentication/custom-realm.asciidoc +++ b/x-pack/docs/en/security/authentication/custom-realm.asciidoc @@ -3,9 +3,9 @@ === Integrating with other authentication systems If you are using an authentication system that is not supported out-of-the-box -by {security}, you can create a custom realm to interact with it to authenticate -users. You implement a custom realm as an SPI loaded security extension -as part of an ordinary elasticsearch plugin. +by the {es} {security-features}, you can create a custom realm to interact with +it to authenticate users. You implement a custom realm as an SPI loaded security +extension as part of an ordinary elasticsearch plugin. [[implementing-custom-realm]] ==== Implementing a custom realm @@ -50,8 +50,8 @@ public AuthenticationFailureHandler getAuthenticationFailureHandler() { ---------------------------------------------------- + The `getAuthenticationFailureHandler` method is used to optionally provide a -custom `AuthenticationFailureHandler`, which will control how {security} responds -in certain authentication failure events. +custom `AuthenticationFailureHandler`, which will control how the +{es} {security-features} respond in certain authentication failure events. + [source,java] ---------------------------------------------------- diff --git a/x-pack/docs/en/security/authentication/saml-guide.asciidoc b/x-pack/docs/en/security/authentication/saml-guide.asciidoc index fa214dc48b7..1cecb3fa96a 100644 --- a/x-pack/docs/en/security/authentication/saml-guide.asciidoc +++ b/x-pack/docs/en/security/authentication/saml-guide.asciidoc @@ -151,7 +151,7 @@ order:: idp.metadata.path:: This is the path to the metadata file that you saved for your Identity Provider. The path that you enter here is relative to your `config/` directory. - {security} will automatically monitor this file for changes and will + {es} will automatically monitor this file for changes and will reload the configuration whenever it is updated. idp.entity_id:: @@ -207,14 +207,14 @@ Attributes in SAML are named using a URI such as more values associated with them. These attribute identifiers vary between IdPs, and most IdPs offer ways to -customise the URIs and their associated value. +customize the URIs and their associated value. {es} uses these attributes to infer information about the user who has logged in, and they can be used for role mapping (below). In order for these attributes to be useful, {es} and the IdP need to have a common value for the names of the attributes. This is done manually, by -configuring the IdP and the {security} SAML realm to use the same URI name for +configuring the IdP and the SAML realm to use the same URI name for each logical user attribute. The recommended steps for configuring these SAML attributes are as follows: @@ -469,7 +469,7 @@ or separate keys used for each of those. The Elastic Stack uses X.509 certificates with RSA private keys for SAML cryptography. These keys can be generated using any standard SSL tool, including -the `elasticsearch-certutil` tool that ships with {xpack}. +the `elasticsearch-certutil` tool. Your IdP may require that the Elastic Stack have a cryptographic key for signing SAML messages, and that you provide the corresponding signing certificate within @@ -518,7 +518,7 @@ Encryption certificates can be generated with the same process. ===== Configuring {es} for signing -By default, {security} will sign _all_ outgoing SAML messages if a signing +By default, {es} will sign _all_ outgoing SAML messages if a signing key has been configured. If you wish to use *PEM formatted* keys and certificates for signing, then @@ -559,17 +559,17 @@ are: `AuthnRequest`, `LogoutRequest` and `LogoutResponse`. ===== Configuring {es} for encrypted messages -{security} supports a single key for message decryption. If a key is -configured, then {security} will attempt to use it to decrypt +The {es} {security-features} support a single key for message decryption. If a +key is configured, then {es} attempts to use it to decrypt `EncryptedAssertion` and `EncryptedAttribute` elements in Authentication responses, and `EncryptedID` elements in Logout requests. -{security} will reject any SAML message that contains an `EncryptedAssertion` +{es} rejects any SAML message that contains an `EncryptedAssertion` that cannot be decrypted. If an `Assertion` contains both encrypted and plain-text attributes, then failure to decrypt the encrypted attributes will not cause an automatic -rejection. Rather, {security} will process the available plain-text attributes +rejection. Rather, {es} processes the available plain-text attributes (and any `EncryptedAttributes` that could be decrypted). If you wish to use *PEM formatted* keys and certificates for SAML encryption, @@ -620,8 +620,8 @@ When a user authenticates using SAML, they are identified to the Elastic Stack, but this does not automatically grant them access to perform any actions or access any data. -Your SAML users cannot do anything until they are assigned {security} -roles. This is done through either the +Your SAML users cannot do anything until they are assigned roles. This is done +through either the {ref}/security-api-put-role-mapping.html[add role mapping API], or with <>. @@ -680,7 +680,7 @@ PUT /_security/role_mapping/saml-finance // CONSOLE // TEST -If your users also exist in a repository that can be directly accessed by {security} +If your users also exist in a repository that can be directly accessed by {es} (such as an LDAP directory) then you can use <> instead of role mappings. diff --git a/x-pack/docs/en/security/authentication/user-cache.asciidoc b/x-pack/docs/en/security/authentication/user-cache.asciidoc index 99cc6c7d6cd..aa5cd1dc903 100644 --- a/x-pack/docs/en/security/authentication/user-cache.asciidoc +++ b/x-pack/docs/en/security/authentication/user-cache.asciidoc @@ -10,18 +10,17 @@ You can configure characteristics of the user cache with the `cache.ttl`, NOTE: PKI realms do not cache user credentials but do cache the resolved user object to avoid unnecessarily needing to perform role mapping on each request. -The cached user credentials are hashed in memory. By default, {security} uses a -salted `sha-256` hash algorithm. You can use a different hashing algorithm by -setting the `cache.hash_algo` realm settings. See +The cached user credentials are hashed in memory. By default, the {es} +{security-features} use a salted `sha-256` hash algorithm. You can use a +different hashing algorithm by setting the `cache.hash_algo` realm settings. See {ref}/security-settings.html#hashing-settings[User cache and password hash algorithms]. [[cache-eviction-api]] ==== Evicting users from the cache -{security} exposes a -{ref}/security-api-clear-cache.html[Clear Cache API] you can use -to force the eviction of cached users. For example, the following request evicts -all users from the `ad1` realm: +You can use the {ref}/security-api-clear-cache.html[clear cache API] to force +the eviction of cached users . For example, the following request evicts all +users from the `ad1` realm: [source, js] ------------------------------------------------------------ diff --git a/x-pack/docs/en/security/authorization/alias-privileges.asciidoc b/x-pack/docs/en/security/authorization/alias-privileges.asciidoc index 05c9359df5a..b9b6d44fd69 100644 --- a/x-pack/docs/en/security/authorization/alias-privileges.asciidoc +++ b/x-pack/docs/en/security/authorization/alias-privileges.asciidoc @@ -4,7 +4,8 @@ Elasticsearch allows to execute operations against {ref}/indices-aliases.html[index aliases], which are effectively virtual indices. An alias points to one or more indices, -holds metadata and potentially a filter. {security} treats aliases and indices +holds metadata and potentially a filter. The {es} {security-features} treat +aliases and indices the same. Privileges for indices actions are granted on specific indices or aliases. In order for an indices action to be authorized, the user that executes it needs to have permissions for that action on all the specific indices or diff --git a/x-pack/docs/en/security/authorization/custom-roles-provider.asciidoc b/x-pack/docs/en/security/authorization/custom-roles-provider.asciidoc index c218fa04f8e..bb8942985b7 100644 --- a/x-pack/docs/en/security/authorization/custom-roles-provider.asciidoc +++ b/x-pack/docs/en/security/authorization/custom-roles-provider.asciidoc @@ -3,7 +3,8 @@ === Custom roles provider extension If you need to retrieve user roles from a system not supported out-of-the-box -by {security}, you can create a custom roles provider to retrieve and resolve +by the {es} {security-features}, you can create a custom roles provider to +retrieve and resolve roles. You implement a custom roles provider as an SPI loaded security extension as part of an ordinary elasticsearch plugin. diff --git a/x-pack/docs/en/security/authorization/managing-roles.asciidoc b/x-pack/docs/en/security/authorization/managing-roles.asciidoc index 453e0809d30..cac4eaac1fb 100644 --- a/x-pack/docs/en/security/authorization/managing-roles.asciidoc +++ b/x-pack/docs/en/security/authorization/managing-roles.asciidoc @@ -130,7 +130,7 @@ The following describes the structure of an application privileges entry: <2> The list of the names of the application privileges to grant to this role. <3> The resources to which those privileges apply. These are handled in the same way as index name pattern in `indices` permissions. These resources do not - have any special meaning to {security}. + have any special meaning to the {es} {security-features}. For details about the validation rules for these fields, see the {ref}/security-api-put-privileges.html[add application privileges API]. @@ -176,7 +176,7 @@ Based on the above definition, users owning the `clicks_admin` role can: TIP: For a complete list of available <> There are two available mechanisms to define roles: using the _Role Management APIs_ -or in local files on the {es} nodes. {security} also supports implementing +or in local files on the {es} nodes. You can also implement custom roles providers. If you need to integrate with another system to retrieve user roles, you can build a custom roles provider plugin. For more information, see <>. @@ -185,7 +185,7 @@ see <>. [[roles-management-ui]] === Role management UI -{security} enables you to easily manage users and roles from within {kib}. To +You can manage users and roles easily in {kib}. To manage roles, log in to {kib} and go to *Management / Elasticsearch / Roles*. [float] @@ -242,5 +242,5 @@ click_admins: query: '{"match": {"category": "click"}}' ----------------------------------- -{security} continuously monitors the `roles.yml` file and automatically picks +{es} continuously monitors the `roles.yml` file and automatically picks up and applies any changes to it. diff --git a/x-pack/docs/en/security/authorization/mapping-roles.asciidoc b/x-pack/docs/en/security/authorization/mapping-roles.asciidoc index a20c194ef4e..a99e385bd8c 100644 --- a/x-pack/docs/en/security/authorization/mapping-roles.asciidoc +++ b/x-pack/docs/en/security/authorization/mapping-roles.asciidoc @@ -10,9 +10,10 @@ For other types of realms, you must create _role-mappings_ that define which roles should be assigned to each user based on their username, groups, or other metadata. -{security} allows role-mappings to be defined via an -<>, or managed through <>. -These two sources of role-mapping are combined inside of {security}, so it is +You can define role-mappings via an +<> or manage them through <>. +These two sources of role-mapping are combined inside of the {es} +{security-features}, so it is possible for a single user to have some roles that have been mapped through the API, and other roles that are mapped through files. @@ -54,7 +55,7 @@ are values. The mappings can have a many-to-many relationship. When you map role to groups, the roles of a user in that group are the combination of the roles assigned to that group and the roles assigned to that user. -By default, {security} checks role mapping files for changes every 5 seconds. +By default, {es} checks role mapping files for changes every 5 seconds. You can change this default behavior by changing the `resource.reload.interval.high` setting in the `elasticsearch.yml` file. Since this is a common setting in Elasticsearch, changing its value might effect other @@ -69,8 +70,8 @@ To specify users and groups in the role mappings, you use their _Distinguished Names_ (DNs). A DN is a string that uniquely identifies the user or group, for example `"cn=John Doe,cn=contractors,dc=example,dc=com"`. -NOTE: {security} only supports Active Directory security groups. You cannot map - distribution groups to roles. +NOTE: The {es} {security-features} support only Active Directory security groups. +You cannot map distribution groups to roles. For example, the following snippet uses the file-based method to map the `admins` group to the `monitoring` role and map the `John Doe` user, the @@ -85,7 +86,7 @@ user: - "cn=users,dc=example,dc=com" - "cn=admins,dc=example,dc=com" ------------------------------------------------------------ -<1> The name of a {security} role. +<1> The name of a role. <2> The distinguished name of an LDAP group or an Active Directory security group. <3> The distinguished name of an LDAP or Active Directory user. diff --git a/x-pack/docs/en/security/authorization/run-as-privilege.asciidoc b/x-pack/docs/en/security/authorization/run-as-privilege.asciidoc index 8dba764cc1c..dfc7a57939a 100644 --- a/x-pack/docs/en/security/authorization/run-as-privilege.asciidoc +++ b/x-pack/docs/en/security/authorization/run-as-privilege.asciidoc @@ -2,10 +2,11 @@ [[run-as-privilege]] === Submitting requests on behalf of other users -{security} supports a permission that enables an authenticated user to submit +The {es} {security-features} support a permission that enables an authenticated +user to submit requests on behalf of other users. If your application already authenticates users, you can use the _run as_ mechanism to restrict data access according to -{security} permissions without having to re-authenticate each user through. +{es} permissions without having to re-authenticate each user through. To "run as" (impersonate) another user, you must be able to retrieve the user from the realm you use to authenticate. Both the internal `native` and `file` realms diff --git a/x-pack/docs/en/security/ccs-clients-integrations.asciidoc b/x-pack/docs/en/security/ccs-clients-integrations.asciidoc index f744e6d7092..1a52a9dab7a 100644 --- a/x-pack/docs/en/security/ccs-clients-integrations.asciidoc +++ b/x-pack/docs/en/security/ccs-clients-integrations.asciidoc @@ -15,10 +15,10 @@ secured cluster: * <> -{security} enables you to secure your {es} cluster. But {es} itself is only one -product within the Elastic Stack. It is often the case that other products in -the stack are connected to the cluster and therefore need to be secured as well, -or at least communicate with the cluster in a secured way: +The {es} {security-features} enable you to secure your {es} cluster. But +{es} itself is only one product within the {stack}. It is often the case that +other products in the stack are connected to the cluster and therefore need to +be secured as well, or at least communicate with the cluster in a secured way: * <> * {auditbeat-ref}/securing-beats.html[Auditbeat] diff --git a/x-pack/docs/en/security/ccs-clients-integrations/beats.asciidoc b/x-pack/docs/en/security/ccs-clients-integrations/beats.asciidoc index 43c8be5409c..fefc103c509 100644 --- a/x-pack/docs/en/security/ccs-clients-integrations/beats.asciidoc +++ b/x-pack/docs/en/security/ccs-clients-integrations/beats.asciidoc @@ -3,9 +3,9 @@ See: -* {auditbeat-ref}/securing-beats.html[Auditbeat and {security}] -* {filebeat-ref}/securing-beats.html[Filebeat and {security}] -* {heartbeat-ref}/securing-beats.html[Heartbeat and {security}] -* {metricbeat-ref}/securing-beats.html[Metricbeat and {security}] -* {packetbeat-ref}/securing-beats.html[Packetbeat and {security}] -* {winlogbeat-ref}/securing-beats.html[Winlogbeat and {security}] +* {auditbeat-ref}/securing-beats.html[{auditbeat}] +* {filebeat-ref}/securing-beats.html[{filebeat}] +* {heartbeat-ref}/securing-beats.html[{heartbeat}] +* {metricbeat-ref}/securing-beats.html[{metricbeat}] +* {packetbeat-ref}/securing-beats.html[{packetbeat}] +* {winlogbeat-ref}/securing-beats.html[{winlogbeat}] diff --git a/x-pack/docs/en/security/ccs-clients-integrations/cross-cluster.asciidoc b/x-pack/docs/en/security/ccs-clients-integrations/cross-cluster.asciidoc index 235af4ea4eb..b72afcb9b01 100644 --- a/x-pack/docs/en/security/ccs-clients-integrations/cross-cluster.asciidoc +++ b/x-pack/docs/en/security/ccs-clients-integrations/cross-cluster.asciidoc @@ -1,9 +1,10 @@ [[cross-cluster-configuring]] -=== Cross Cluster Search and Security +=== Cross cluster search and security -{ref}/modules-cross-cluster-search.html[Cross Cluster Search] enables +{ref}/modules-cross-cluster-search.html[Cross cluster search] enables federated search across multiple clusters. When using cross cluster search -with secured clusters, all clusters must have {security} enabled. +with secured clusters, all clusters must have the {es} {security-features} +enabled. The local cluster (the cluster used to initiate cross cluster search) must be allowed to connect to the remote clusters, which means that the CA used to @@ -22,8 +23,8 @@ This feature was added as Beta in {es} `v5.3` with further improvements made in To use cross cluster search with secured clusters: -* Enable {security} on every node in each connected cluster. For more -information about the `xpack.security.enabled` setting, see +* Enable the {es} {security-features} on every node in each connected cluster. +For more information about the `xpack.security.enabled` setting, see {ref}/security-settings.html[Security Settings in {es}]. * Enable encryption globally. To encrypt communications, you must enable diff --git a/x-pack/docs/en/security/ccs-clients-integrations/http.asciidoc b/x-pack/docs/en/security/ccs-clients-integrations/http.asciidoc index d78c32bc361..6b7ff26cbf3 100644 --- a/x-pack/docs/en/security/ccs-clients-integrations/http.asciidoc +++ b/x-pack/docs/en/security/ccs-clients-integrations/http.asciidoc @@ -1,7 +1,8 @@ [[http-clients]] -=== HTTP/REST Clients and Security +=== HTTP/REST clients and security -{security} works with standard HTTP {wikipedia}/Basic_access_authentication[basic authentication] +The {es} {security-features} work with standard HTTP +{wikipedia}/Basic_access_authentication[basic authentication] headers to authenticate users. Since Elasticsearch is stateless, this header must be sent with every request: @@ -48,8 +49,8 @@ curl --user rdeniro:taxidriver -XPUT 'localhost:9200/idx' [float] ==== Client Libraries over HTTP -For more information about how to use {security} with the language specific clients -please refer to +For more information about using {security-features} with the language +specific clients, refer to https://github.com/elasticsearch/elasticsearch-ruby/tree/master/elasticsearch-transport#authentication[Ruby], http://elasticsearch-py.readthedocs.org/en/master/#ssl-and-authentication[Python], https://metacpan.org/pod/Search::Elasticsearch::Cxn::HTTPTiny#CONFIGURATION[Perl], diff --git a/x-pack/docs/en/security/ccs-clients-integrations/java.asciidoc b/x-pack/docs/en/security/ccs-clients-integrations/java.asciidoc index 3c537ef5ee2..8166f5cff9b 100644 --- a/x-pack/docs/en/security/ccs-clients-integrations/java.asciidoc +++ b/x-pack/docs/en/security/ccs-clients-integrations/java.asciidoc @@ -1,9 +1,9 @@ [[java-clients]] -=== Java Client and Security +=== Java Client and security deprecated[7.0.0, The `TransportClient` is deprecated in favour of the {java-rest}/java-rest-high.html[Java High Level REST Client] and will be removed in Elasticsearch 8.0. The {java-rest}/java-rest-high-level-migration.html[migration guide] describes all the steps needed to migrate.] -{security} supports the Java http://www.elastic.co/guide/en/elasticsearch/client/java-api/current/transport-client.html[transport client] for Elasticsearch. +The {es} {security-features} support the Java http://www.elastic.co/guide/en/elasticsearch/client/java-api/current/transport-client.html[transport client] for Elasticsearch. The transport client uses the same transport protocol that the cluster nodes use for inter-node communication. It is very efficient as it does not have to marshall and unmarshall JSON requests like a typical REST client. @@ -21,7 +21,8 @@ To use the transport client with a secured cluster, you need to: . {ref}/setup-xpack-client.html[Configure the {xpack} transport client]. . Configure a user with the privileges required to start the transport client. -A default `transport_client` role is built-in to {xpack} that grants the +A default `transport_client` role is built-in to the {es} {security-features}, +which grants the appropriate cluster permissions for the transport client to work with the secured cluster. The transport client uses the _Nodes Info API_ to fetch information about the nodes in the cluster. @@ -137,7 +138,7 @@ TransportClient client = new PreBuiltXPackTransportClient(Settings.builder() [float] [[disabling-client-auth]] -===== Disabling Client Authentication +===== Disabling client authentication If you want to disable client authentication, you can use a client-specific transport protocol. For more information see <>. @@ -167,7 +168,7 @@ NOTE: If you are using a public CA that is already trusted by the Java runtime, [float] [[connecting-anonymously]] -===== Connecting Anonymously +===== Connecting anonymously To enable the transport client to connect anonymously, you must assign the anonymous user the privileges defined in the <> @@ -176,14 +177,14 @@ see <>. [float] [[security-client]] -==== Security Client +==== Security client -{security} exposes its own API through the `SecurityClient` class. To get a hold -of a `SecurityClient` you'll first need to create the `XPackClient`, which is a -wrapper around the existing Elasticsearch clients (any client class implementing +The {stack} {security-features} expose an API through the `SecurityClient` class. +To get a hold of a `SecurityClient` you first need to create the `XPackClient`, +which is a wrapper around the existing {es} clients (any client class implementing `org.elasticsearch.client.Client`). -The following example shows how you can clear {security}'s realm caches using +The following example shows how you can clear the realm caches using the `SecurityClient`: [source,java] diff --git a/x-pack/docs/en/security/ccs-clients-integrations/monitoring.asciidoc b/x-pack/docs/en/security/ccs-clients-integrations/monitoring.asciidoc index 67bffadfb29..96ea35173ec 100644 --- a/x-pack/docs/en/security/ccs-clients-integrations/monitoring.asciidoc +++ b/x-pack/docs/en/security/ccs-clients-integrations/monitoring.asciidoc @@ -1,15 +1,15 @@ [[secure-monitoring]] -=== Monitoring and Security +=== Monitoring and security -<> consists of two components: an agent -that you install on on each {es} and Logstash node, and a Monitoring UI +The <> consists of two components: +an agent that you install on on each {es} and Logstash node, and a Monitoring UI in {kib}. The monitoring agent collects and indexes metrics from the nodes and you visualize the data through the Monitoring dashboards in {kib}. The agent can index data on the same {es} cluster, or send it to an external monitoring cluster. -To use {monitoring} with {security} enabled, you need to -{kibana-ref}/using-kibana-with-security.html[set up {kib} to work with {security}] +To use the {monitor-features} with the {security-features} enabled, you need to +{kibana-ref}/using-kibana-with-security.html[set up {kib} to work with the {security-features}] and create at least one user for the Monitoring UI. If you are using an external monitoring cluster, you also need to configure a user for the monitoring agent and configure the agent to use the appropriate credentials when communicating diff --git a/x-pack/docs/en/security/configuring-es.asciidoc b/x-pack/docs/en/security/configuring-es.asciidoc index 22140eb680c..d9be6129347 100644 --- a/x-pack/docs/en/security/configuring-es.asciidoc +++ b/x-pack/docs/en/security/configuring-es.asciidoc @@ -2,25 +2,25 @@ [[configuring-security]] == Configuring security in {es} ++++ -Configuring Security +Configuring security ++++ -{security} enables you to easily secure a cluster. With {security}, you can +The {es} {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. For more information, see -{xpack-ref}/elasticsearch-security.html[Securing the Elastic Stack]. +{stack-ov}/elasticsearch-security.html[Securing the {stack}]. -To use {security} in {es}: +To use {es} {security-features}: -. Verify that you are using a license that includes the {security} feature. +. Verify that you are using a license that includes the {security-features}. + -- -If you want to try all of the {xpack} features, you can start a 30-day trial. At -the end of the trial period, you can purchase a subscription to keep using the -full functionality of the {xpack} components. For more information, see +If you want to try all of the platinum features, you can start a 30-day trial. +At the end of the trial period, you can purchase a subscription to keep using +the full functionality. For more information, see https://www.elastic.co/subscriptions and -{xpack-ref}/license-management.html[License Management]. +{stack-ov}/license-management.html[License Management]. -- . Verify that the `xpack.security.enabled` setting is `true` on each node in @@ -37,7 +37,7 @@ NOTE: This requirement applies to clusters with more than one node and to clusters with a single node that listens on an external interface. Single-node clusters that use a loopback interface do not have this requirement. For more information, see -{xpack-ref}/encrypting-communications.html[Encrypting Communications]. +{stack-ov}/encrypting-communications.html[Encrypting Communications]. -- .. <>. @@ -49,7 +49,7 @@ information, see . Set the passwords for all built-in users. + -- -{security} provides +The {es} {security-features} provide {stack-ov}/built-in-users.html[built-in users] to help you get up and running. The +elasticsearch-setup-passwords+ command is the simplest method to set the built-in users' passwords for the first time. @@ -126,7 +126,7 @@ curl -XPOST -u elastic 'localhost:9200/_security/user/johndoe' -H "Content-Type: xpack.security.audit.enabled: true ---------------------------- + -For more information, see {xpack-ref}/auditing.html[Auditing Security Events] +For more information, see {stack-ov}/auditing.html[Auditing Security Events] and <>. .. Restart {es}. diff --git a/x-pack/docs/en/security/securing-communications.asciidoc b/x-pack/docs/en/security/securing-communications.asciidoc index 84f3b0bc27a..63fded729eb 100644 --- a/x-pack/docs/en/security/securing-communications.asciidoc +++ b/x-pack/docs/en/security/securing-communications.asciidoc @@ -6,7 +6,8 @@ Elasticsearch nodes store data that may be confidential. Attacks on the data may come from the network. These attacks could include sniffing of the data, manipulation of the data, and attempts to gain access to the server and thus the files storing the data. Securing your nodes is required in order to use a production -license that enables {security} and helps reduce the risk from network-based attacks. +license that enables {security-features} and helps reduce the risk from +network-based attacks. This section shows how to: diff --git a/x-pack/docs/en/security/using-ip-filtering.asciidoc b/x-pack/docs/en/security/using-ip-filtering.asciidoc index 86579f220f1..4e99ec4903d 100644 --- a/x-pack/docs/en/security/using-ip-filtering.asciidoc +++ b/x-pack/docs/en/security/using-ip-filtering.asciidoc @@ -5,19 +5,19 @@ You can apply IP filtering to application clients, node clients, or transport clients, in addition to other nodes that are attempting to join the cluster. -If a node's IP address is on the blacklist, {security} will still allow the -connection to Elasticsearch, but it will be dropped immediately, and no requests -will be processed. +If a node's IP address is on the blacklist, the {es} {security-features} allow +the connection to {es} but it is be dropped immediately and no requests are +processed. NOTE: Elasticsearch installations are not designed to be publicly accessible - over the Internet. IP Filtering and the other security capabilities of - {security} do not change this condition. + over the Internet. IP Filtering and the other capabilities of the + {es} {security-features} do not change this condition. [float] === Enabling IP filtering -{security} features an access control feature that allows or rejects hosts, -domains, or subnets. +The {es} {security-features} contain an access control feature that allows or +rejects hosts, domains, or subnets. You configure IP filtering by specifying the `xpack.security.transport.filter.allow` and `xpack.security.transport.filter.deny` settings in in `elasticsearch.yml`. Allow rules @@ -79,7 +79,7 @@ xpack.security.http.filter.enabled: true === Specifying TCP transport profiles {ref}/modules-transport.html[TCP transport profiles] -enable Elasticsearch to bind on multiple hosts. {security} enables you to apply +enable Elasticsearch to bind on multiple hosts. The {es} {security-features} enable you to apply different IP filtering on different profiles. [source,yaml] diff --git a/x-pack/docs/en/watcher/actions/webhook.asciidoc b/x-pack/docs/en/watcher/actions/webhook.asciidoc index 315e2639085..1b7c482d2c4 100644 --- a/x-pack/docs/en/watcher/actions/webhook.asciidoc +++ b/x-pack/docs/en/watcher/actions/webhook.asciidoc @@ -70,13 +70,13 @@ For example, the following `webhook` action creates a new issue in GitHub: <1> The username and password for the user creating the issue NOTE: By default, both the username and the password are stored in the `.watches` - index in plain text. When {security} is enabled, {watcher} can encrypt the - password before storing it. + index in plain text. When the {es} {security-features} are enabled, + {watcher} can encrypt the password before storing it. You can also use PKI-based authentication when submitting requests to a cluster -secured with {security}. When you use PKI-based authentication instead of HTTP -basic auth, you don't need to store any authentication information in the watch -itself. To use PKI-based authentication, you {ref}/notification-settings.html#ssl-notification-settings +that has {es} {security-features} enabled. When you use PKI-based authentication +instead of HTTP basic auth, you don't need to store any authentication +information in the watch itself. To use PKI-based authentication, you {ref}/notification-settings.html#ssl-notification-settings [configure the SSL key settings] for {watcher} in `elasticsearch.yml`. diff --git a/x-pack/docs/en/watcher/java/delete-watch.asciidoc b/x-pack/docs/en/watcher/java/delete-watch.asciidoc index 1e9b7f0e0be..4d37b910fd1 100644 --- a/x-pack/docs/en/watcher/java/delete-watch.asciidoc +++ b/x-pack/docs/en/watcher/java/delete-watch.asciidoc @@ -11,8 +11,8 @@ related to this watch from the watch history. IMPORTANT: Deleting a watch must be done via this API only. Do not delete the watch directly from the `.watches` index using Elasticsearch's DELETE - Document API. I {security} is enabled, make sure no `write` privileges - are granted to anyone over the `.watches` index. + Document API. If the {es} {security-features} are enabled, make sure + no `write` privileges are granted to anyone over the `.watches` index. The following example deletes a watch with the `my-watch` id: diff --git a/x-pack/docs/en/watcher/java/put-watch.asciidoc b/x-pack/docs/en/watcher/java/put-watch.asciidoc index 17d564bbcb9..68250418713 100644 --- a/x-pack/docs/en/watcher/java/put-watch.asciidoc +++ b/x-pack/docs/en/watcher/java/put-watch.asciidoc @@ -10,8 +10,8 @@ registered with the relevant trigger engine (typically the scheduler, for the IMPORTANT: Putting a watch must be done via this API only. Do not put a watch directly to the `.watches` index using Elasticsearch's Index API. - When {security} is enabled, make sure no `write` privileges are - granted to anyone over the `.watches` index. + When the {es} {security-features} are enabled, make sure no `write` + privileges are granted to anyone over the `.watches` index. The following example adds a watch with the `my-watch` id that has the following diff --git a/x-pack/docs/en/watcher/managing-watches.asciidoc b/x-pack/docs/en/watcher/managing-watches.asciidoc index a7598d1f0da..a155132d5e4 100644 --- a/x-pack/docs/en/watcher/managing-watches.asciidoc +++ b/x-pack/docs/en/watcher/managing-watches.asciidoc @@ -19,9 +19,9 @@ since {watcher} stores its watches in the `.watches` index, you can list them by executing a search on this index. IMPORTANT: You can only perform read actions on the `.watches` index. You must - use the {watcher} APIs to create, update, and delete watches. If - {security} is enabled, we recommend you only grant users `read` - privileges on the `.watches` index. + use the {watcher} APIs to create, update, and delete watches. If {es} + {security-features} are enabled, we recommend you only grant users + `read` privileges on the `.watches` index. For example, the following returns the first 100 watches: