Correct plugin capitalization (#3838)

* Correct plugin capitalization

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Revert cluster-stats because the name is in response

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Revert cluster-stats once more

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

---------

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

_api-reference/analyze-apis/perform-text-analysis.md

@@ -10,7 +10,7 @@ nav_order: 2
 
 The perform text analysis API analyzes a text string and returns the resulting tokens.
 
-If you use the security plugin, you must have the `manage index` privilege. If you simply want to analyze text, you must have the `manager cluster` privilege.
+If you use the Security plugin, you must have the `manage index` privilege. If you simply want to analyze text, you must have the `manager cluster` privilege.
 {: .note}
 
 ## Path and HTTP methods

_api-reference/cat/index.md

@@ -81,5 +81,5 @@ GET _cat/<operation_name>?h=<header_name_1>,<header_name_2>&v
 
 Typically, for any operation you can find out what headers are available using the `help` parameter, and then use the `h` parameter to limit the output to only the headers that you care about.
 
-If you use the security plugin, make sure you have the appropriate permissions.
+If you use the Security plugin, make sure you have the appropriate permissions.
 {: .note }

_api-reference/index-apis/clear-index-cache.md

@@ -10,7 +10,7 @@ nav_order: 320
 The clear cache API operation clears the caches of one or more indexes. For data streams, the API clears the caches of the stream’s backing indexes.
 
 
-If you use the security plugin, you must have the `manage index` privileges.
+If you use the Security plugin, you must have the `manage index` privileges.
 {: .note}
 
 ### Path parameters

_api-reference/index-apis/index.md

@@ -11,5 +11,5 @@ redirect_from:
 
 The index API operations let you interact with indices in your cluster. Using these operations, you can create, delete, close, and complete other index-related operations.
 
-If you use the security plugin, make sure you have the appropriate permissions.
+If you use the Security plugin, make sure you have the appropriate permissions.
 {: .note }

_api-reference/nodes-apis/nodes-hot-threads.md

@@ -122,4 +122,4 @@ Then information about threads of the selected type is provided.
 
 ## Required permissions
 
-If you use the security plugin, make sure you set the following permissions: `cluster:monitor/nodes/hot_threads`.
+If you use the Security plugin, make sure you set the following permissions: `cluster:monitor/nodes/hot_threads`.

_api-reference/nodes-apis/nodes-info.md

@@ -164,4 +164,4 @@ aggregations | Information about the available aggregation types.
 
 ## Required permissions
 
-If you use the security plugin, make sure you have the appropriate permissions: `cluster:monitor/nodes/info`.
+If you use the Security plugin, make sure you have the appropriate permissions: `cluster:monitor/nodes/info`.

_api-reference/nodes-apis/nodes-reload-secure.md

@@ -65,4 +65,4 @@ The following is an example response:
 
 ## Required permissions
 
-If you use the security plugin, make sure you set the following permissions: `cluster:manage/nodes`.
+If you use the Security plugin, make sure you set the following permissions: `cluster:manage/nodes`.

_api-reference/nodes-apis/nodes-stats.md

@@ -978,4 +978,4 @@ enforced | Boolean | If true, the shard indexing pressure runs in enforced mode
 
 ## Required permissions
 
-If you use the security plugin, make sure you have the appropriate permissions: `cluster:monitor/nodes/stats`.
+If you use the Security plugin, make sure you have the appropriate permissions: `cluster:monitor/nodes/stats`.

_api-reference/nodes-apis/nodes-usage.md

@@ -92,4 +92,4 @@ The following is an example response:
 
 ## Required permissions
 
-If you use the security plugin, make sure you set the following permissions: `cluster:manage/nodes` or `cluster:monitor/nodes`.
+If you use the Security plugin, make sure you set the following permissions: `cluster:manage/nodes` or `cluster:monitor/nodes`.

_api-reference/snapshots/get-snapshot-status.md

@@ -11,7 +11,7 @@ Returns details about a snapshot’s state during and after snapshot creation.
 
 To learn about snapshot creation, see [Create snapshot]({{site.url}}{{site.baseurl}}/api-reference/snapshots/create-snapshot).
 
-If you use the security plugin, you must have the `monitor_snapshot`, `create_snapshot`, or `manage cluster` privileges.
+If you use the Security plugin, you must have the `monitor_snapshot`, `create_snapshot`, or `manage cluster` privileges.
 {: .note}
 
 ### Path parameters

_api-reference/snapshots/verify-snapshot-repository.md

@@ -12,7 +12,7 @@ Verifies that a snapshot repository is functional. Verifies the repository on ea
 
 If verification is successful, the verify snapshot repository API returns a list of nodes connected to the snapshot repository. If verification failed, the API returns an error.
 
-If you use the security plugin, you must have the `manage cluster` privilege.
+If you use the Security plugin, you must have the `manage cluster` privilege.
 {: .note}
 
 ### Path parameters

_clients/java-rest-high-level.md

@@ -27,7 +27,7 @@ You can now start your OpenSearch cluster. The OpenSearch 1.x high-level REST cl
 
 ## Security
 
-Before using the REST client in your Java application, you must configure the application's truststore to connect to the security plugin. If you are using self-signed certificates or demo configurations, you can use the following command to create a custom truststore and add in root authority certificates.
+Before using the REST client in your Java application, you must configure the application's truststore to connect to the Security plugin. If you are using self-signed certificates or demo configurations, you can use the following command to create a custom truststore and add in root authority certificates.
 
 If you're using certificates from a trusted Certificate Authority (CA), you don't need to configure the truststore.
 

_clients/java.md

@@ -67,7 +67,7 @@ You can now start your OpenSearch cluster.
 
 ## Security
 
-Before using the REST client in your Java application, you must configure the application's truststore to connect to the security plugin. If you are using self-signed certificates or demo configurations, you can use the following command to create a custom truststore and add in root authority certificates.
+Before using the REST client in your Java application, you must configure the application's truststore to connect to the Security plugin. If you are using self-signed certificates or demo configurations, you can use the following command to create a custom truststore and add in root authority certificates.
 
 If you're using certificates from a trusted Certificate Authority (CA), you don't need to configure the truststore.
 

_dashboards/branding.md

@@ -147,7 +147,7 @@ You can continue using the top header bar in the default view for custom navigat
 
 ## Sample configuration
 
-The following configuration enables the security plugin and SSL within OpenSearch Dashboards and uses custom branding elements to replace the OpenSearch logo and application title.
+The following configuration enables the Security plugin and SSL within OpenSearch Dashboards and uses custom branding elements to replace the OpenSearch logo and application title.
 
 ```yml
 server.host: "0"

_dashboards/discover/multi-data-sources.md

@@ -34,7 +34,7 @@ A data source connection specifies the parameters needed to connect to a data so
 
 To create a new data source connection:
 
-1. Open Dashboards. If you’re not running the security plugin, go to [`http://localhost:5601`](http://localhost:5601/). If you’re running the security plugin, go to [`https://localhost:5601`](https://localhost:5601/) and log in with the username `admin` and password `admin`.
+1. Open Dashboards. If you’re not running the Security plugin, go to [`http://localhost:5601`](http://localhost:5601/). If you’re running the Security plugin, go to [`https://localhost:5601`](https://localhost:5601/) and log in with the username `admin` and password `admin`.
 
 1. Under **Management** in the OpenSearch Dashboards main menu, choose **Stack Management**, **Data Sources `Experimental`**, **Data Sources**, and then choose **Create data source connection**, as shown in the following image.
 

_dashboards/reporting.md

@@ -7,7 +7,7 @@ nav_order: 70
 
 # Creating reports with the Dashboards interface
 
-You can use OpenSearch Dashboards to create PNG, PDF, and CSV reports. To create reports, you must have the correct permissions. For a summary of the predefined roles and the permissions they grant, see the [security plugin]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
+You can use OpenSearch Dashboards to create PNG, PDF, and CSV reports. To create reports, you must have the correct permissions. For a summary of the predefined roles and the permissions they grant, see the [Security plugin]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
 
 CSV reports have a non-configurable 10,000 row limit. They have no explicit size limit (for example, MB), but extremely large documents could cause report generation to fail with an out of memory error from the V8 JavaScript engine.
 {: .tip }

_dashboards/visualize/visbuilder.md

@@ -37,8 +37,8 @@ vis_builder.enabled: false
 Follow these steps to create a new visualization using VisBuilder in your environment:
 
 1. Open Dashboards:
-    - If you're not running the security plugin, go to http://localhost:5601.
+    - If you're not running the Security plugin, go to http://localhost:5601.
-    - If you're running the security plugin, go to https://localhost:5601 and log in with your username and password (default is admin/admin).
+    - If you're running the Security plugin, go to https://localhost:5601 and log in with your username and password (default is admin/admin).
 
 2. Confirm that the **Enable experimental visualizations** option is turned on.
    - From the top menu, select **Management** **>** **Stack Management** **>** **Advanced Settings**.

_data-prepper/pipelines/configuration/sinks/opensearch.md

@@ -53,7 +53,7 @@ The following table describes options you can configure for the `opensearch` sin
 Option | Required | Type | Description
 :--- | :--- | :--- | :---
 hosts | Yes | List | List of OpenSearch hosts to write to (for example, `["https://localhost:9200", "https://remote-cluster:9200"]`).
-cert | No | String | Path to the security certificate (for example, `"config/root-ca.pem"`) if the cluster uses the OpenSearch security plugin.
+cert | No | String | Path to the security certificate (for example, `"config/root-ca.pem"`) if the cluster uses the OpenSearch Security plugin.
 username | No | String | Username for HTTP basic authentication.
 password | No | String | Password for HTTP basic authentication.
 aws_sigv4 | No | Boolean | Default value is false. Whether to use AWS Identity and Access Management (IAM) signing to connect to an Amazon OpenSearch Service domain. For your access key, secret key, and optional session token, Data Prepper uses the default credential chain (environment variables, Java system properties, `~/.aws/credential`, etc.).

_im-plugin/data-streams.md

@@ -268,4 +268,4 @@ You can use wildcards to delete more than one data stream.
 
 We recommend deleting data from a data stream using an ISM policy.
 
-You can also use [asynchronous search]({{site.url}}{{site.baseurl}}/search-plugins/async/index/), [SQL]({{site.url}}{{site.baseurl}}/search-plugins/sql/index/), and [PPL]({{site.url}}{{site.baseurl}}/search-plugins/sql/ppl/index/) to query your data stream directly. You can also use the security plugin to define granular permissions for the data stream name.
+You can also use [asynchronous search]({{site.url}}{{site.baseurl}}/search-plugins/async/index/), [SQL]({{site.url}}{{site.baseurl}}/search-plugins/sql/index/), and [PPL]({{site.url}}{{site.baseurl}}/search-plugins/sql/ppl/index/) to query your data stream directly. You can also use the Security plugin to define granular permissions for the data stream name.

_im-plugin/security.md

@@ -7,13 +7,13 @@ has_children: false
 
 # Index management security
 
-Using the security plugin with index management lets you limit non-admin users to certain actions. For example, you might want to set up your security such that a group of users can only read ISM policies, while others can create, delete, or change policies.
+Using the Security plugin with index management lets you limit non-admin users to certain actions. For example, you might want to set up your security such that a group of users can only read ISM policies, while others can create, delete, or change policies.
 
 All index management data are protected as system indices, and only a super admin or an admin with a Transport Layer Security (TLS) certificate can access system indices. For more information, see [System indices]({{site.url}}{{site.baseurl}}/security/configuration/system-indices).
 
 ## Basic permissions
 
-The security plugin comes with one role that offers full access to index management: `index_management_full_access`. For a description of the role's permissions, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
+The Security plugin comes with one role that offers full access to index management: `index_management_full_access`. For a description of the role's permissions, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
 
 With security enabled, users not only need the correct index management permissions, but they also need permissions to execute actions to involved indices. For example, if a user wants to use the REST API to attach a policy that executes a rollup job to an index named `system-logs`, they would need the permissions to attach a policy and execute a rollup job, as well as access to `system-logs`.
 

_install-and-configure/configuration.md

@@ -86,7 +86,7 @@ action.auto_create_index: true
 compatibility.override_main_response_version: true
 ```
 
-The demo configuration includes a number of settings for the security plugin that you should modify before using OpenSearch for a production workload. To learn more, see [Security]({{site.url}}{{site.baseurl}}/security/).
+The demo configuration includes a number of settings for the Security plugin that you should modify before using OpenSearch for a production workload. To learn more, see [Security]({{site.url}}{{site.baseurl}}/security/).
 
 ### (Optional) CORS header configuration
 If you are working on a client application running against an OpenSearch cluster on a different domain, you can configure headers in `opensearch.yml` to allow for developing a local application on the same machine.  Use [Cross Origin Resource Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) so your application can make calls to the OpenSearch API running locally.  Add the following lines in your `custom-opensearch.yml` file (note that the "-" must be the first character in each line).

_install-and-configure/install-opensearch/debian.md

@@ -219,7 +219,7 @@ Before modifying any configuration files, it's always a good idea to save a back
    # fail when you try to start the service.
    discovery.type: single-node
 
-   # If you previously disabled the security plugin in opensearch.yml,
+   # If you previously disabled the Security plugin in opensearch.yml,
    # be sure to re-enable it. Otherwise you can skip this setting.
    plugins.security.disabled: false
    ```
@@ -239,7 +239,7 @@ Before modifying any configuration files, it's always a good idea to save a back
 
 ### Configure TLS
 
-TLS certificates provide additional security for your cluster by allowing clients to confirm the identity of hosts and encrypt traffic between the client and host. For more information, refer to [Configure TLS Certificates]({{site.url}}{{site.baseurl}}/security-plugin/configuration/tls/) and [Generate Certificates]({{site.url}}{{site.baseurl}}/security-plugin/configuration/generate-certificates/), which are included in the [Security Plugin]({{site.url}}{{site.baseurl}}/security-plugin/index/) documentation. For work performed in a development environment, self-signed certificates are usually adequate. This section will guide you through the basic steps required to generate your own TLS certificates and apply them to your OpenSearch host.
+TLS certificates provide additional security for your cluster by allowing clients to confirm the identity of hosts and encrypt traffic between the client and host. For more information, refer to [Configure TLS Certificates]({{site.url}}{{site.baseurl}}/security-plugin/configuration/tls/) and [Generate Certificates]({{site.url}}{{site.baseurl}}/security-plugin/configuration/generate-certificates/), which are included in the [Security plugin]({{site.url}}{{site.baseurl}}/security-plugin/index/) documentation. For work performed in a development environment, self-signed certificates are usually adequate. This section will guide you through the basic steps required to generate your own TLS certificates and apply them to your OpenSearch host.
 
 1. Navigate to the directory where the certificates will be stored.
    ```bash
@@ -258,7 +258,7 @@ TLS certificates provide additional security for your cluster by allowing client
    # replace the arguments passed to -subj so they reflect your specific host.
    sudo openssl req -new -x509 -sha256 -key root-ca-key.pem -subj "/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=ROOT" -out root-ca.pem -days 730
    ```
-1. Next, create the admin certificate. This certificate is used to gain elevated rights for performing administrative tasks relating to the security plugin.
+1. Next, create the admin certificate. This certificate is used to gain elevated rights for performing administrative tasks relating to the Security plugin.
    ```bash
    # Create a private key for the admin certificate.
    sudo openssl genrsa -out admin-key-temp.pem 2048
@@ -337,7 +337,7 @@ TLS certificates provide additional security for your cluster by allowing client
 
 Users are defined and authenticated by OpenSearch in a variety of ways. One method that does not require additional backend infrastructure is to manually configure users in `internal_users.yml`. See [YAML files]({{site.url}}{{site.baseurl}}/security-plugin/configuration/yaml/) for more information about configuring users. The following steps explain how to remove all demo users except for the `admin` user and how to replace the `admin` default password using a script.
 
-1. Navigate to the security plugins tools directory.
+1. Navigate to the Security plugins tools directory.
    ```bash
    cd /usr/share/opensearch/plugins/opensearch-security/tools
    ```
@@ -462,4 +462,4 @@ sudo apt-get upgrade opensearch=<version>
 - [OpenSearch configuration]({{site.url}}{{site.baseurl}}/install-and-configure/configuration/)
 - [Install and configure OpenSearch Dashboards]({{site.url}}{{site.baseurl}}/install-and-configure/install-dashboards/index/)
 - [OpenSearch plugin installation]({{site.url}}{{site.baseurl}}/opensearch/install/plugins/)
-- [About the security plugin]({{site.url}}{{site.baseurl}}/security-plugin/index/)
+- [About the Security plugin]({{site.url}}{{site.baseurl}}/security-plugin/index/)

_install-and-configure/install-opensearch/docker.md

@@ -280,7 +280,7 @@ services:
 
 ### Sample Docker Compose file for development
 
-If you want to build your own compose file from an example, review the following sample `docker-compose.yml` file. This sample file creates two OpenSearch nodes and one OpenSearch Dashboards node with the security plugin disabled. You can use this sample file as a starting point while reviewing [Configuring basic security settings](#configuring-basic-security-settings).
+If you want to build your own compose file from an example, review the following sample `docker-compose.yml` file. This sample file creates two OpenSearch nodes and one OpenSearch Dashboards node with the Security plugin disabled. You can use this sample file as a starting point while reviewing [Configuring basic security settings](#configuring-basic-security-settings).
 ```yml
 version: '3'
 services:
@@ -295,7 +295,7 @@ services:
       - bootstrap.memory_lock=true # Disable JVM heap memory swapping
       - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Set min and max JVM heap sizes to at least 50% of system RAM
       - "DISABLE_INSTALL_DEMO_CONFIG=true" # Prevents execution of bundled demo script which installs demo certificates and security configurations to OpenSearch
-      - "DISABLE_SECURITY_PLUGIN=true" # Disables security plugin
+      - "DISABLE_SECURITY_PLUGIN=true" # Disables Security plugin
     ulimits:
       memlock:
         soft: -1 # Set memlock to unlimited (no soft or hard limit)
@@ -321,7 +321,7 @@ services:
       - bootstrap.memory_lock=true # Disable JVM heap memory swapping
       - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Set min and max JVM heap sizes to at least 50% of system RAM
       - "DISABLE_INSTALL_DEMO_CONFIG=true" # Prevents execution of bundled demo script which installs demo certificates and security configurations to OpenSearch
-      - "DISABLE_SECURITY_PLUGIN=true" # Disables security plugin
+      - "DISABLE_SECURITY_PLUGIN=true" # Disables Security plugin
     ulimits:
       memlock:
         soft: -1 # Set memlock to unlimited (no soft or hard limit)
@@ -440,13 +440,13 @@ docker build --tag=opensearch-custom-plugin .
 docker run -p 9200:9200 -p 9600:9600 -v /usr/share/opensearch/data opensearch-custom-plugin
 ```
 
-Alternatively, you might want to remove a plugin from an image before deploying it. This example Dockerfile removes the security plugin:
+Alternatively, you might want to remove a plugin from an image before deploying it. This example Dockerfile removes the Security plugin:
 ```
 FROM opensearchproject/opensearch:latest
 RUN /usr/share/opensearch/bin/opensearch-plugin remove opensearch-security
 ```
 
-You can also use a Dockerfile to pass your own certificates for use with the [Security Plugin]({{site.url}}{{site.baseurl}}/security/):
+You can also use a Dockerfile to pass your own certificates for use with the [Security plugin]({{site.url}}{{site.baseurl}}/security/):
 ```
 FROM opensearchproject/opensearch:latest
 COPY --chown=opensearch:opensearch opensearch.yml /usr/share/opensearch/config/

_install-and-configure/install-opensearch/rpm.md

@@ -202,7 +202,7 @@ Before modifying any configuration files, it's always a good idea to save a back
    # fail when you try to start the service.
    discovery.type: single-node
 
-   # If you previously disabled the security plugin in opensearch.yml,
+   # If you previously disabled the Security plugin in opensearch.yml,
    # be sure to re-enable it. Otherwise you can skip this setting.
    plugins.security.disabled: false
    ```
@@ -222,7 +222,7 @@ Before modifying any configuration files, it's always a good idea to save a back
 
 ### Configure TLS
 
-TLS certificates provide additional security for your cluster by allowing clients to confirm the identity of hosts and encrypt traffic between the client and host. For more information, refer to [Configure TLS Certificates]({{site.url}}{{site.baseurl}}/security/configuration/tls/) and [Generate Certificates]({{site.url}}{{site.baseurl}}/security/configuration/generate-certificates/), which are included in the [Security Plugin]({{site.url}}{{site.baseurl}}/security/index/) documentation. For work performed in a development environment, self-signed certificates are usually adequate. This section will guide you through the basic steps required to generate your own TLS certificates and apply them to your OpenSearch host.
+TLS certificates provide additional security for your cluster by allowing clients to confirm the identity of hosts and encrypt traffic between the client and host. For more information, refer to [Configure TLS Certificates]({{site.url}}{{site.baseurl}}/security/configuration/tls/) and [Generate Certificates]({{site.url}}{{site.baseurl}}/security/configuration/generate-certificates/), which are included in the [Security plugin]({{site.url}}{{site.baseurl}}/security/index/) documentation. For work performed in a development environment, self-signed certificates are usually adequate. This section will guide you through the basic steps required to generate your own TLS certificates and apply them to your OpenSearch host.
 
 1. Navigate to the directory where the certificates will be stored.
    ```bash
@@ -241,7 +241,7 @@ TLS certificates provide additional security for your cluster by allowing client
    # replace the arguments passed to -subj so they reflect your specific host.
    sudo openssl req -new -x509 -sha256 -key root-ca-key.pem -subj "/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=ROOT" -out root-ca.pem -days 730
    ```
-1. Next, create the admin certificate. This certificate is used to gain elevated rights for performing administrative tasks relating to the security plugin.
+1. Next, create the admin certificate. This certificate is used to gain elevated rights for performing administrative tasks relating to the Security plugin.
    ```bash
    # Create a private key for the admin certificate.
    sudo openssl genrsa -out admin-key-temp.pem 2048
@@ -320,7 +320,7 @@ TLS certificates provide additional security for your cluster by allowing client
 
 Users are defined and authenticated by OpenSearch in a variety of ways. One method that does not require additional backend infrastructure is to manually configure users in `internal_users.yml`. See [YAML files]({{site.url}}{{site.baseurl}}/security/configuration/yaml/) for more information about configuring users. The following steps explain how to remove all demo users except for the `admin` user and how to replace the `admin` default password using a script.
 
-1. Navigate to the security plugins tools directory.
+1. Navigate to the Security plugins tools directory.
    ```bash
    cd /usr/share/opensearch/plugins/opensearch-security/tools
    ```
@@ -446,4 +446,4 @@ sudo yum update
 - [OpenSearch configuration]({{site.url}}{{site.baseurl}}/install-and-configure/configuration/)
 - [Install and configure OpenSearch Dashboards]({{site.url}}{{site.baseurl}}/install-and-configure/install-dashboards/index/)
 - [OpenSearch plugin installation]({{site.url}}{{site.baseurl}}/opensearch/install/plugins/)
-- [About the security plugin]({{site.url}}{{site.baseurl}}/security/index/)
+- [About the Security plugin]({{site.url}}{{site.baseurl}}/security/index/)

_install-and-configure/install-opensearch/tar.md

@@ -75,11 +75,11 @@ Before launching OpenSearch you should review some [important system settings]({
 Before proceeding you should test your installation of OpenSearch. Otherwise, it can be difficult to determine whether future problems are due to installation issues or custom settings you applied after installation. There are two quick methods for testing OpenSearch at this stage:
 
 1. **(Security enabled)** Apply a generic configuration using the demo security script included in the tar archive.
-1. **(Security disabled)** Manually disable the security plugin and test the instance before applying your own custom security settings.
+1. **(Security disabled)** Manually disable the Security plugin and test the instance before applying your own custom security settings.
 
 The demo security script will apply a generic configuration to your instance of OpenSearch. This configuration defines some environment variables and also applies self-signed TLS certificates. If you would like to configure these yourself, see [Step 4: Set up OpenSearch in your environment](#step-4-set-up-opensearch-in-your-environment).
 
-If you only want to verify that the service is properly configured and you intend to configure security settings yourself, then you may want to disable the security plugin and launch the service without encryption or authentication.
+If you only want to verify that the service is properly configured and you intend to configure security settings yourself, then you may want to disable the Security plugin and launch the service without encryption or authentication.
 
 An OpenSearch node configured by the demo security script is not suitable for a production environment. If you plan to use the node in a production environment after running `opensearch-tar-install.sh`, you should, at a minimum, replace the demo TLS certificates with your own TLS certificates and [update the list of internal users and passwords]({{site.url}}{{site.baseurl}}/security/configuration/yaml). See [Security configuration]({{site.url}}{{site.baseurl}}/security/configuration/index/) for additional guidance to ensure that your nodes are configured according to your security requirements.
 {: .warning}
@@ -151,12 +151,12 @@ An OpenSearch node configured by the demo security script is not suitable for a
    ```bash
    vi /path/to/opensearch-{{site.opensearch_version}}/config/opensearch.yml
    ```
-1. Add the following line to disable the security plugin:
+1. Add the following line to disable the Security plugin:
    ```bash
    plugins.security.disabled: true
    ```
 1. Save the change and close the file.
-1. Open another terminal session and send requests to the server to verify that OpenSearch is running. Because the security plugin has been disabled, you will be sending commands using `HTTP` rather than `HTTPS`.
+1. Open another terminal session and send requests to the server to verify that OpenSearch is running. Because the Security plugin has been disabled, you will be sending commands using `HTTP` rather than `HTTPS`.
    - Send a request to port 9200.
       ```bash
       curl -X GET http://localhost:9200
@@ -240,7 +240,7 @@ Before modifying any configuration files, it's always a good idea to save a back
    # fail when you try to start the service.
    discovery.type: single-node
 
-   # If you previously disabled the security plugin in opensearch.yml,
+   # If you previously disabled the Security plugin in opensearch.yml,
    # be sure to re-enable it. Otherwise you can skip this setting.
    plugins.security.disabled: false
    ```
@@ -264,7 +264,7 @@ Before modifying any configuration files, it's always a good idea to save a back
 
 ### Configure TLS
 
-TLS certificates provide additional security for your cluster by allowing clients to confirm the identity of hosts and encrypt traffic between the client and host. For more information, refer to [Configure TLS Certificates]({{site.url}}{{site.baseurl}}/security/configuration/tls/) and [Generate Certificates]({{site.url}}{{site.baseurl}}/security/configuration/generate-certificates/), which are included in the [Security Plugin]({{site.url}}{{site.baseurl}}/security/index/) documentation. For work performed in a development environment, self-signed certificates are usually adequate. This section will guide you through the basic steps required to generate your own TLS certificates and apply them to your OpenSearch host.
+TLS certificates provide additional security for your cluster by allowing clients to confirm the identity of hosts and encrypt traffic between the client and host. For more information, refer to [Configure TLS Certificates]({{site.url}}{{site.baseurl}}/security/configuration/tls/) and [Generate Certificates]({{site.url}}{{site.baseurl}}/security/configuration/generate-certificates/), which are included in the [Security plugin]({{site.url}}{{site.baseurl}}/security/index/) documentation. For work performed in a development environment, self-signed certificates are usually adequate. This section will guide you through the basic steps required to generate your own TLS certificates and apply them to your OpenSearch host.
 
 1. Navigate to the OpenSearch `config` directory. This is where the certificates will be stored.
    ```bash
@@ -279,7 +279,7 @@ TLS certificates provide additional security for your cluster by allowing client
    # replace the arguments passed to -subj so they reflect your specific host.
    openssl req -new -x509 -sha256 -key root-ca-key.pem -subj "/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=ROOT" -out root-ca.pem -days 730
    ```
-1. Next, create the admin certificate. This certificate is used to gain elevated rights for performing administrative tasks relating to the security plugin.
+1. Next, create the admin certificate. This certificate is used to gain elevated rights for performing administrative tasks relating to the Security plugin.
    ```bash
    # Create a private key for the admin certificate.
    openssl genrsa -out admin-key-temp.pem 2048
@@ -355,7 +355,7 @@ TLS certificates provide additional security for your cluster by allowing client
 
 Users are defined and authenticated by OpenSearch in a variety of ways. One method, which does not require additional backend infrastructure, is to manually configure users in `internal_users.yml`. See [YAML files]({{site.url}}{{site.baseurl}}/security/configuration/yaml/) for more information about configuring users. The following steps explain how to remove all demo users except for the `admin` user and how to replace the `admin` default password using a script.
 
-1. Make the security plugin scripts executable.
+1. Make the Security plugin scripts executable.
    ```bash
    chmod 755 /path/to/opensearch-{{site.opensearch_version}}/plugins/opensearch-security/tools/*.sh
    ```
@@ -541,4 +541,4 @@ The following configuration is only suitable for testing in a non-production env
 - [Configure Performance Analyzer for Tarball Installation]({{site.url}}{{site.baseurl}}/monitoring-plugins/pa/index/#install-performance-analyzer)
 - [Install and configure OpenSearch Dashboards]({{site.url}}{{site.baseurl}}/install-and-configure/install-dashboards/index/)
 - [OpenSearch plugin installation]({{site.url}}{{site.baseurl}}/opensearch/install/plugins/)
-- [About the security plugin]({{site.url}}{{site.baseurl}}/security/index/)
+- [About the Security plugin]({{site.url}}{{site.baseurl}}/security/index/)

_install-and-configure/install-opensearch/windows.md

@@ -36,11 +36,11 @@ Perform the following steps to install OpenSearch on Windows.
 Before proceeding with any configuration, you should test your installation of OpenSearch. Otherwise, it can be difficult to determine whether future problems are due to installation issues or custom settings you applied after installation. There are two quick methods for testing OpenSearch at this stage:
 
 1. **(Security enabled)** Apply a generic configuration using the batch script included in the Windows archive. 
-1. **(Security disabled)** Manually disable the security plugin and test the instance before applying your own custom security settings.
+1. **(Security disabled)** Manually disable the Security plugin and test the instance before applying your own custom security settings.
 
 The batch script will apply a generic configuration to your instance of OpenSearch. This configuration defines some environment variables and also applies self-signed TLS certificates. Alternatively, you can choose to configure these yourself.
 
-If you only want to verify that the service is properly configured and you intend to configure security settings yourself, then you may want to disable the security plugin and launch the service without encryption or authentication.
+If you only want to verify that the service is properly configured and you intend to configure security settings yourself, then you may want to disable the Security plugin and launch the service without encryption or authentication.
 
 An OpenSearch node in its default configuration (with demo certificates and users with default passwords) is not suitable for a production environment. If you plan to use the node in a production environment, you should, at a minimum, replace the demo TLS certificates with your own TLS certificates and [update the list of internal users and passwords]({{site.url}}{{site.baseurl}}/security/configuration/yaml). See [Security configuration]({{site.url}}{{site.baseurl}}/security/configuration/index/) for additional guidance to ensure that your nodes are configured according to your security requirements.
 {: .warning}
@@ -123,14 +123,14 @@ An OpenSearch node in its default configuration (with demo certificates and user
 
 1. Open the `opensearch-{{site.opensearch_version}}\config` folder.
 1. Open the `opensearch.yml` file with a text editor.
-1. Add the following line to disable the security plugin:
+1. Add the following line to disable the Security plugin:
    ```yaml
    plugins.security.disabled: true
    ```
 1. Save the change and close the file.
 1. Navigate to the top directory of your OpenSearch installation and open the `opensearch-{{site.opensearch_version}}` folder.
 1. Run the default by double-clicking the `opensearch-windows-install.bat` file. This opens a command prompt with an OpenSearch instance running.
-1. Open a new command prompt and send requests to the server to verify that OpenSearch is running. Because the security plugin has been disabled, you will be sending commands using `HTTP` rather than `HTTPS`.
+1. Open a new command prompt and send requests to the server to verify that OpenSearch is running. Because the Security plugin has been disabled, you will be sending commands using `HTTP` rather than `HTTPS`.
    - Send a request to port 9200:
       ```bat
       curl.exe -X GET http://localhost:9200
@@ -214,7 +214,7 @@ Before modifying any configuration files, it's always a good idea to save a back
    # fail when you try to start the service.
    discovery.type: single-node
 
-   # If you previously disabled the security plugin in opensearch.yml,
+   # If you previously disabled the Security plugin in opensearch.yml,
    # be sure to re-enable it. Otherwise you can skip this setting.
    plugins.security.disabled: false
    ```
@@ -246,4 +246,4 @@ The Performance Analyzer plugin is not available on Windows. All other OpenSearc
 
 - [OpenSearch configuration]({{site.url}}{{site.baseurl}}/install-and-configure/configuration/)
 - [OpenSearch plugin installation]({{site.url}}{{site.baseurl}}/opensearch/install/plugins/)
-- [About the security plugin]({{site.url}}{{site.baseurl}}/security/index/)
+- [About the Security plugin]({{site.url}}{{site.baseurl}}/security/index/)

_install-and-configure/plugins.md

@@ -293,14 +293,14 @@ Members of the OpenSearch community have built countless plugins for the service
 
 - [About Observability]({{site.url}}{{site.baseurl}}/observability-plugin/index/)
 - [About security analytics]({{site.url}}{{site.baseurl}}/security-analytics/index/)
-- [About the security plugin]({{site.url}}{{site.baseurl}}/security/index/)
+- [About the Security plugin]({{site.url}}{{site.baseurl}}/security/index/)
 - [Alerting]({{site.url}}{{site.baseurl}}/monitoring-plugins/alerting/index/)
 - [Anomaly detection]({{site.url}}{{site.baseurl}}/monitoring-plugins/ad/index/)
 - [Asynchronous search]({{site.url}}{{site.baseurl}}/search-plugins/async/index/)
 - [Cross-cluster replication]({{site.url}}{{site.baseurl}}/replication-plugin/index/)
 - [Index State Management]({{site.url}}{{site.baseurl}}/im-plugin/ism/index/)
 - [k-NN]({{site.url}}{{site.baseurl}}/search-plugins/knn/index/)
-- [ML Commons Plugin]({{site.url}}{{site.baseurl}}/ml-commons-plugin/index/)
+- [ML Commons plugin]({{site.url}}{{site.baseurl}}/ml-commons-plugin/index/)
 - [Neural Search]({{site.url}}{{site.baseurl}}/neural-search-plugin/index/)
 - [Notifications]({{site.url}}{{site.baseurl}}/notifications-plugin/index/)
 - [OpenSearch Dashboards]({{site.url}}{{site.baseurl}}/dashboards/index/)

_ml-commons-plugin/cluster-settings.md

@@ -7,7 +7,7 @@ nav_order: 160
 
 # ML Commons cluster settings
 
-To enhance and customize your OpenSearch cluster for machine learning (ML), you can add and modify several configuration settings for the ML commons plugin in your 'opensearch.yml' file.
+To enhance and customize your OpenSearch cluster for machine learning (ML), you can add and modify several configuration settings for the ML Commons plugin in your 'opensearch.yml' file.
 
 
 ## Run tasks and models on ML nodes only

_ml-commons-plugin/index.md

@@ -19,7 +19,7 @@ Should you not want to use a model, you can use the [Train and Predict]({{site.u
 
 ## Permissions
 
-There are two reserved user roles that can use of the ML commons plugin.
+There are two reserved user roles that can use of the ML Commons plugin.
 
 - `ml_full_access`: Full access to all ML features, including starting new ML tasks and reading or deleting models.
 - `ml_readonly_access`: Can only read ML tasks, trained models and statistics relevant to the model's cluster. Cannot start nor delete ML tasks or models.

_observing-your-data/ad/security.md

@@ -10,7 +10,7 @@ redirect_from:
 
 # Anomaly detection security
 
-You can use the security plugin with anomaly detection in OpenSearch to limit non-admin users to specific actions. For example, you might want some users to only be able to create, update, or delete detectors, while others to only view detectors.
+You can use the Security plugin with anomaly detection in OpenSearch to limit non-admin users to specific actions. For example, you might want some users to only be able to create, update, or delete detectors, while others to only view detectors.
 
 All anomaly detection indices are protected as system indices. Only a super admin user or an admin user with a TLS certificate can access system indices. For more information, see [System indices]({{site.url}}{{site.baseurl}}/security/configuration/system-indices/).
 
@@ -19,9 +19,9 @@ Security for anomaly detection works the same as [security for alerting]({{site.
 
 ## Basic permissions
 
-As an admin user, you can use the security plugin to assign specific permissions to users based on which APIs they need access to. For a list of supported APIs, see [Anomaly detection API]({{site.url}}{{site.baseurl}}/monitoring-plugins/ad/api/).
+As an admin user, you can use the Security plugin to assign specific permissions to users based on which APIs they need access to. For a list of supported APIs, see [Anomaly detection API]({{site.url}}{{site.baseurl}}/monitoring-plugins/ad/api/).
 
-The security plugin has two built-in roles that cover most anomaly detection use cases: `anomaly_full_access` and `anomaly_read_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
+The Security plugin has two built-in roles that cover most anomaly detection use cases: `anomaly_full_access` and `anomaly_read_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
 
 If these roles don't meet your needs, mix and match individual anomaly detection [permissions]({{site.url}}{{site.baseurl}}/security/access-control/permissions/) to suit your use case. Each action corresponds to an operation in the REST API. For example, the `cluster:admin/opensearch/ad/detector/delete` permission lets you delete detectors.
 

_observing-your-data/ad/settings.md

@@ -35,7 +35,7 @@ plugins.anomaly_detection.ad_result_history_max_docs_per_shard | 1,350,000,000 |
 plugins.anomaly_detection.max_entities_per_query | 1,000,000 | The maximum unique values per detection interval for high cardinality detectors. By default, if the category field(s) have more than the configured unique values in a detector interval, the anomaly detection plugin orders them by the natural ordering of categorical values (for example, entity `ab` comes before `bc`) and then selects the top values.
 plugins.anomaly_detection.max_entities_for_preview | 5 | The maximum unique category field values displayed with the preview operation for high cardinality detectors. By default, if the category field(s) have more than the configured unique values in a detector interval, the anomaly detection plugin orders them by the natural ordering of categorical values (for example, entity `ab` comes before `bc`) and then selects the top values.
 plugins.anomaly_detection.max_primary_shards | 10 | The maximum number of primary shards an anomaly detection index can have.
-plugins.anomaly_detection.filter_by_backend_roles | False | When you enable the security plugin and set this to `true`, the anomaly detection plugin filters results based on the user's backend role(s).
+plugins.anomaly_detection.filter_by_backend_roles | False | When you enable the Security plugin and set this to `true`, the anomaly detection plugin filters results based on the user's backend role(s).
 plugins.anomaly_detection.max_batch_task_per_node | 10 | Starting a historical analysis triggers a batch task. This setting is the number of batch tasks that you can run per data node. You can tune this setting from 1 to 1,000. If the data nodes can’t support all batch tasks and you’re not sure if the data nodes are capable of running more historical analysis, add more data nodes instead of changing this setting to a higher value. Increasing this value might bring more load on each data node.
 plugins.anomaly_detection.max_old_ad_task_docs_per_detector | 1 | You can run historical analysis for the same detector many times. For each run, the anomaly detection plugin creates a new task. This setting is the number of previous tasks the plugin keeps. Set this value to at least 1 to track its last run. You can keep a maximum of 1,000 old tasks to avoid overwhelming the cluster.
 plugins.anomaly_detection.batch_task_piece_size | 1,000 | The date range for a historical task is split into smaller pieces and the anomaly detection plugin runs the task piece by piece. Each piece contains 1,000 detection intervals by default. For example, if detector interval is 1 minute and one piece is 1,000 minutes, the feature data is queried every 1,000 minutes. You can change this setting from 1 to 10,000.

_observing-your-data/alerting/monitors.md

@@ -432,7 +432,7 @@ If you don't want to receive notifications for alerts, you don't have to add act
 
 1. Choose **Create**.
 
-After an action sends a message, the content of that message has left the purview of the security plugin. Securing access to the message (e.g. access to the Slack channel) is your responsibility.
+After an action sends a message, the content of that message has left the purview of the Security plugin. Securing access to the message (e.g. access to the Slack channel) is your responsibility.
 
 
 #### Sample message

_observing-your-data/alerting/security.md

@@ -10,12 +10,12 @@ redirect_from:
 
 # Alerting security
 
-If you use the security plugin alongside alerting, you might want to limit certain users to certain actions. For example, you might want some users to only be able to view and acknowledge alerts, while others can modify monitors and destinations.
+If you use the Security plugin alongside alerting, you might want to limit certain users to certain actions. For example, you might want some users to only be able to view and acknowledge alerts, while others can modify monitors and destinations.
 
 
 ## Basic permissions
 
-The security plugin has three built-in roles that cover most alerting use cases: `alerting_read_access`, `alerting_ack_alerts`, and `alerting_full_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
+The Security plugin has three built-in roles that cover most alerting use cases: `alerting_read_access`, `alerting_ack_alerts`, and `alerting_full_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
 
 If these roles don't meet your needs, mix and match individual alerting [permissions]({{site.url}}{{site.baseurl}}/security/access-control/permissions/) to suit your use case. Each action corresponds to an operation in the REST API. For example, the `cluster:admin/opensearch/alerting/destination/delete` permission lets you delete destinations.
 
@@ -50,7 +50,7 @@ To reduce the chances of unintended users viewing metadata that could describe a
 
 Out of the box, the alerting plugin has no concept of ownership. For example, if you have the `cluster:admin/opensearch/alerting/monitor/write` permission, you can edit *all* monitors, regardless of whether you created them. If a small number of trusted users manage your monitors and destinations, this lack of ownership generally isn't a problem. A larger organization might need to segment access by backend role.
 
-First, make sure that your users have the appropriate [backend roles]({{site.url}}{{site.baseurl}}/security/access-control/index/). Backend roles usually come from an [LDAP server]({{site.url}}{{site.baseurl}}/security/configuration/ldap/) or [SAML provider]({{site.url}}{{site.baseurl}}/security/configuration/saml/). However, if you use the internal user database, you can use the REST API to add them manually with a create user operation. To add a backend role to a create user request, follow the [Create user]({{site.url}}{{site.baseurl}}/security/access-control/api#create-user) instructions in the Security Plugin API documentation.
+First, make sure that your users have the appropriate [backend roles]({{site.url}}{{site.baseurl}}/security/access-control/index/). Backend roles usually come from an [LDAP server]({{site.url}}{{site.baseurl}}/security/configuration/ldap/) or [SAML provider]({{site.url}}{{site.baseurl}}/security/configuration/saml/). However, if you use the internal user database, you can use the REST API to add them manually with a create user operation. To add a backend role to a create user request, follow the [Create user]({{site.url}}{{site.baseurl}}/security/access-control/api#create-user) instructions in the Security plugin API documentation.
 
 Next, enable the following setting:
 
@@ -115,7 +115,7 @@ Regular user | No | Don’t update the backend roles on the monitor.
 - If the user tries to associate roles that they don't have permission to use, it will throw an exception.
 {: .note }
 
-To create an RBAC role, follow instructions in the Security Plugin API documentation to [Create role]({{site.url}}{{site.baseurl}}/security/access-control/api#create-role).
+To create an RBAC role, follow instructions in the Security plugin API documentation to [Create role]({{site.url}}{{site.baseurl}}/security/access-control/api#create-role).
 ### Create a monitor with an RBAC role
 
 When you create a monitor with the Alerting API, you can specify the RBAC roles at the bottom of the request body. Use the `rbac_roles` parameter.

_observing-your-data/alerting/settings.md

@@ -12,7 +12,7 @@ redirect_from:
 
 ## Alerting indices
 
-The alerting feature creates several indices and one alias. The security plugin demo script configures them as [system indices]({{site.url}}{{site.baseurl}}/security/configuration/system-indices/) for an extra layer of protection. Don't delete these indices or modify their contents without using the alerting APIs.
+The alerting feature creates several indices and one alias. The Security plugin demo script configures them as [system indices]({{site.url}}{{site.baseurl}}/security/configuration/system-indices/) for an extra layer of protection. Don't delete these indices or modify their contents without using the alerting APIs.
 
 Index | Purpose
 :--- | :---

_observing-your-data/observability-security.md

@@ -9,11 +9,11 @@ redirect_from:
 
 # Observability security
 
-You can use the security plugin with Observability in OpenSearch to limit non-admin users to specific actions. For example, you might want some users to only view visualizations, notebooks, and other Observability objects, while others can create and modify them.
+You can use the Security plugin with Observability in OpenSearch to limit non-admin users to specific actions. For example, you might want some users to only view visualizations, notebooks, and other Observability objects, while others can create and modify them.
 
 ## Basic permissions
 
-The security plugin has two built-in roles that cover most Observability use cases: `observability_full_access` and `observability_read_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles). If you don't see these predefined roles in OpenSearch Dashboards, you can create them with the following commands:
+The Security plugin has two built-in roles that cover most Observability use cases: `observability_full_access` and `observability_read_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles). If you don't see these predefined roles in OpenSearch Dashboards, you can create them with the following commands:
 
 ```json
 PUT _plugins/_security/api/roles/observability_read_access

_replication-plugin/api.md

@@ -39,7 +39,7 @@ Options | Description | Type | Required
 :--- | :--- |:--- |:--- |
 `leader_alias` |  The name of the cross-cluster connection. You define this alias when you [set up a cross-cluster connection]({{site.url}}{{site.baseurl}}/replication-plugin/get-started/#set-up-a-cross-cluster-connection). | `string` | Yes
 `leader_index` |  The index on the leader cluster that you want to replicate. | `string` | Yes
-`use_roles` |  The roles to use for all subsequent backend replication tasks between the indexes. Specify a `leader_cluster_role` and `follower_cluster_role`. See [Map the leader and follower cluster roles]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles). | `string` | If security plugin is enabled
+`use_roles` |  The roles to use for all subsequent backend replication tasks between the indexes. Specify a `leader_cluster_role` and `follower_cluster_role`. See [Map the leader and follower cluster roles]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles). | `string` | If Security plugin is enabled
 
 #### Sample response
 
@@ -347,7 +347,7 @@ Options | Description | Type | Required
 `leader_alias` |  The name of the cross-cluster connection. You define this alias when you [set up a cross-cluster connection]({{site.url}}{{site.baseurl}}/replication-plugin/get-started/#set-up-a-cross-cluster-connection). | `string` | Yes
 `name` |  A name for the auto-follow pattern. | `string` | Yes
 `pattern` |  An array of index patterns to match against indexes in the specified leader cluster. Supports wildcard characters. For example, `leader-*`. | `string` | Yes
-`use_roles` |  The roles to use for all subsequent backend replication tasks between the indexes. Specify a `leader_cluster_role` and `follower_cluster_role`. See [Map the leader and follower cluster roles]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles). | `string` | If security plugin is enabled
+`use_roles` |  The roles to use for all subsequent backend replication tasks between the indexes. Specify a `leader_cluster_role` and `follower_cluster_role`. See [Map the leader and follower cluster roles]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles). | `string` | If Security plugin is enabled
 
 #### Sample response
 

_replication-plugin/auto-follow.md

@@ -18,7 +18,7 @@ You need to [set up a cross-cluster connection]({{site.url}}{{site.baseurl}}/rep
 
 ## Permissions
 
-If the security plugin is enabled, make sure that non-admin users are mapped to the appropriate permissions so they can perform replication actions. For index and cluster-level permissions requirements, see [Cross-cluster replication permissions]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/).
+If the Security plugin is enabled, make sure that non-admin users are mapped to the appropriate permissions so they can perform replication actions. For index and cluster-level permissions requirements, see [Cross-cluster replication permissions]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/).
 
 ## Get started with auto-follow
 
@@ -39,7 +39,7 @@ curl -XPOST -k -H 'Content-Type: application/json' -u 'admin:admin' 'https://loc
 }'
 ```
 
-If the security plugin is disabled, you can leave out the `use_roles` parameter. If it's enabled, however, you need to specify the leader and follower cluster roles that OpenSearch uses to authenticate requests. This example uses `all_access` for simplicity, but we recommend creating a replication user on each cluster and [mapping it accordingly]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles).
+If the Security plugin is disabled, you can leave out the `use_roles` parameter. If it's enabled, however, you need to specify the leader and follower cluster roles that OpenSearch uses to authenticate requests. This example uses `all_access` for simplicity, but we recommend creating a replication user on each cluster and [mapping it accordingly]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles).
 {: .tip }
 
 To test the rule, create a matching index on the leader cluster:

_replication-plugin/get-started.md

@@ -20,9 +20,9 @@ Cross-cluster replication has the following prerequisites:
 
 ## Permissions
 
-Make sure the security plugin is either enabled on both clusters or disabled on both clusters. If you disabled the security plugin, you can skip this section. However, we strongly recommend enabling the security plugin in production scenarios.
+Make sure the Security plugin is either enabled on both clusters or disabled on both clusters. If you disabled the Security plugin, you can skip this section. However, we strongly recommend enabling the Security plugin in production scenarios.
 
-If the security plugin is enabled, make sure that non-admin users are mapped to the appropriate permissions so they can perform replication actions. For index and cluster-level permissions requirements, see [Cross-cluster replication permissions]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/).
+If the Security plugin is enabled, make sure that non-admin users are mapped to the appropriate permissions so they can perform replication actions. For index and cluster-level permissions requirements, see [Cross-cluster replication permissions]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/).
 
 In addition, verify and add the distinguished names (DNs) of each follower cluster node on the leader cluster to allow connections from the followers to the leader.
 
@@ -181,7 +181,7 @@ curl -XPUT -k -H 'Content-Type: application/json' -u 'admin:admin' 'https://loca
 }'
 ```
 
-If the security plugin is disabled, omit the `use_roles` parameter. If it's enabled, however, you must specify the leader and follower cluster roles that OpenSearch will use to authenticate the request. This example uses `all_access` for simplicity, but we recommend creating a replication user on each cluster and [mapping it accordingly]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles).
+If the Security plugin is disabled, omit the `use_roles` parameter. If it's enabled, however, you must specify the leader and follower cluster roles that OpenSearch will use to authenticate the request. This example uses `all_access` for simplicity, but we recommend creating a replication user on each cluster and [mapping it accordingly]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles).
 {: .tip }
 
 This command creates an identical read-only index named `follower-01` on the follower cluster that continuously stays updated with changes to the `leader-01` index on the leader cluster. Starting replication creates a follower index from scratch -- you can't convert an existing index to a follower index. 

_replication-plugin/index.md

@@ -18,6 +18,6 @@ Replication follows an active-passive model where the follower index (where the
 
 The replication plugin supports replication of indexes using wildcard pattern matching and provides commands to pause, resume, and stop replication. Once replication starts on an index, it initiates persistent background tasks on all primary shards on the follower cluster, which continuously poll corresponding shards from the leader cluster for updates.
 
-You can use the replication plugin with the security plugin to encrypt cross-cluster traffic with node-to-node encryption and control access to replication activities.
+You can use the replication plugin with the Security plugin to encrypt cross-cluster traffic with node-to-node encryption and control access to replication activities.
 
 To start, see [Get started with cross-cluster replication]({{site.url}}{{site.baseurl}}/replication-plugin/get-started/).

_replication-plugin/permissions.md

@@ -6,7 +6,7 @@ nav_order: 30
 
 # Cross-cluster replication security
 
-You can use the [security plugin]({{site.url}}{{site.baseurl}}/security/index/) with cross-cluster replication to limit users to certain actions. For example, you might want certain users to only perform replication activity on the leader or follower cluster.
+You can use the [Security plugin]({{site.url}}{{site.baseurl}}/security/index/) with cross-cluster replication to limit users to certain actions. For example, you might want certain users to only perform replication activity on the leader or follower cluster.
 
 Because cross-cluster replication involves multiple clusters, it's possible that clusters might have different security configurations. The following configurations are supported:
 
@@ -20,7 +20,7 @@ Enable node-to-node encryption on both the leader and the follower cluster to en
 
 In order for non-admin users to perform replication activities, they must be mapped to the appropriate permissions.  
 
-The security plugin has two built-in roles that cover most replication use cases: `cross_cluster_replication_leader_full_access`, which provides replication permissions on the leader cluster, and `cross_cluster_replication_follower_full_access`, which provides replication permissions on the follower cluster. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
+The Security plugin has two built-in roles that cover most replication use cases: `cross_cluster_replication_leader_full_access`, which provides replication permissions on the leader cluster, and `cross_cluster_replication_follower_full_access`, which provides replication permissions on the follower cluster. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
 
 If you don't want to use the default roles, you can combine individual replication [permissions]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#replication-permissions) to meet your needs. Most permissions correspond to specific REST API operations. For example, the `indices:admin/plugins/replication/index/pause` permission lets you pause replication.
 
@@ -53,7 +53,7 @@ The following sections list the available index and cluster-level permissions fo
 
 ### Follower cluster
 
-The security plugin supports these permissions for the follower cluster:
+The Security plugin supports these permissions for the follower cluster:
 
 ```
 indices:admin/plugins/replication/index/setup/validate
@@ -69,7 +69,7 @@ cluster:admin/plugins/replication/autofollow/update
 
 ### Leader cluster
 
-The security plugin supports these permissions for the leader cluster:
+The Security plugin supports these permissions for the leader cluster:
 
 ```
 indices:admin/plugins/replication/validate

_search-plugins/async/security.md

@@ -8,15 +8,15 @@ has_children: false
 
 # Asynchronous search security
 
-You can use the security plugin with asynchronous searches to limit non-admin users to specific actions. For example, you might want some users to only be able to submit or delete asynchronous searches, while you might want others to only view the results.
+You can use the Security plugin with asynchronous searches to limit non-admin users to specific actions. For example, you might want some users to only be able to submit or delete asynchronous searches, while you might want others to only view the results.
 
 All asynchronous search indices are protected as system indices. Only a super admin user or an admin user with a Transport Layer Security (TLS) certificate can access system indices. For more information, see [System indices]({{site.url}}{{site.baseurl}}/security/configuration/system-indices/).
 
 ## Basic permissions
 
-As an admin user, you can use the security plugin to assign specific permissions to users based on which API operations they need access to. For a list of supported APIs operations, see [Asynchronous search]({{site.url}}{{site.baseurl}}/).
+As an admin user, you can use the Security plugin to assign specific permissions to users based on which API operations they need access to. For a list of supported APIs operations, see [Asynchronous search]({{site.url}}{{site.baseurl}}/).
 
-The security plugin has two built-in roles that cover most asynchronous search use cases: `asynchronous_search_full_access` and `asynchronous_search_read_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
+The Security plugin has two built-in roles that cover most asynchronous search use cases: `asynchronous_search_full_access` and `asynchronous_search_read_access`. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
 
 If these roles don’t meet your needs, mix and match individual asynchronous search permissions to suit your use case. Each action corresponds to an operation in the REST API. For example, the `cluster:admin/opensearch/asynchronous_search/delete` permission lets you delete a previously submitted asynchronous search.
 

_search-plugins/async/settings.md

@@ -7,7 +7,7 @@ nav_order: 4
 
 # Settings
 
-The asynchronous search plugin adds several settings to the standard OpenSearch cluster settings. They are dynamic, so you can change the default behavior of the plugin without restarting your cluster. You can mark the settings as `persistent` or `transient`.
+The Asynchronous Search plugin adds several settings to the standard OpenSearch cluster settings. They are dynamic, so you can change the default behavior of the plugin without restarting your cluster. You can mark the settings as `persistent` or `transient`.
 
 For example, to update the retention period of the result index:
 

_search-plugins/point-in-time.md

@@ -121,7 +121,7 @@ In every request you can only query for one slice, so the next query will be the
 
 ## Security model
 
-This section describes the permissions needed to use PIT API operations if you are running OpenSearch with the security plugin enabled.
+This section describes the permissions needed to use PIT API operations if you are running OpenSearch with the Security plugin enabled.
 
 Users can access all PIT API operations using the `point_in_time_full_access` role. If this role doesn't meet your needs, mix and match individual PIT permissions to suit your use case. Each action corresponds to an operation in the REST API. For example, the `indices:data/read/point_in_time/create` permission lets you create a PIT. The following are the possible permissions:
 

_search-plugins/sql/cli.md

@@ -55,7 +55,7 @@ When you first launch the SQL CLI, a configuration file is automatically created
 You can configure the following connection properties:
 
 - `endpoint`: You do not need to specify an option. Anything that follows the launch command `opensearchsql` is considered as the endpoint. If you do not provide an endpoint, by default, the SQL CLI connects to http://localhost:9200.
-- `-u/-w`: Supports username and password for HTTP basic authentication, such as with the security plugin or fine-grained access control for Amazon OpenSearch Service.
+- `-u/-w`: Supports username and password for HTTP basic authentication, such as with the Security plugin or fine-grained access control for Amazon OpenSearch Service.
 - `--aws-auth`: Turns on AWS sigV4 authentication to connect to an Amazon OpenSearch endpoint. Use with the AWS CLI (`aws configure`) to retrieve the local AWS configuration to authenticate and connect.
 
 For a list of all available configurations, see [clirc](https://github.com/opensearch-project/sql/blob/1.x/sql-cli/src/opensearch_sql_cli/conf/clirc).

_security/access-control/api.md

@@ -7,7 +7,7 @@ nav_order: 120
 
 # API
 
-The security plugin REST API lets you programmatically create and manage users, roles, role mappings, action groups, and tenants.
+The Security plugin REST API lets you programmatically create and manage users, roles, role mappings, action groups, and tenants.
 
 ---
 
@@ -20,7 +20,7 @@ The security plugin REST API lets you programmatically create and manage users,
 
 ## Access control for the API
 
-Just like OpenSearch permissions, you control access to the security plugin REST API using roles. Specify roles in `opensearch.yml`:
+Just like OpenSearch permissions, you control access to the Security plugin REST API using roles. Specify roles in `opensearch.yml`:
 
 ```yml
 plugins.security.restapi.roles_enabled: ["<role>", ...]
@@ -422,9 +422,9 @@ DELETE _plugins/_security/api/internalusers/<username>
 Introduced 1.0
 {: .label .label-purple }
 
-Creates or replaces the specified user. You must specify either `password` (plain text) or `hash` (the hashed user password). If you specify `password`, the security plugin automatically hashes the password before storing it.
+Creates or replaces the specified user. You must specify either `password` (plain text) or `hash` (the hashed user password). If you specify `password`, the Security plugin automatically hashes the password before storing it.
 
-Note that any role you supply in the `opendistro_security_roles` array must already exist for the security plugin to map the user to that role. To see predefined roles, refer to [the list of predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles). For instructions on how to create a role, refer to [creating a role](#create-role).
+Note that any role you supply in the `opendistro_security_roles` array must already exist for the Security plugin to map the user to that role. To see predefined roles, refer to [the list of predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles). For instructions on how to create a role, refer to [creating a role](#create-role).
 
 #### Request
 
@@ -1092,7 +1092,7 @@ PATCH _plugins/_security/api/tenants/
 Introduced 1.0
 {: .label .label-purple }
 
-Retrieves the current security plugin configuration in JSON format.
+Retrieves the current Security plugin configuration in JSON format.
 
 #### Request
 
@@ -1364,7 +1364,7 @@ PUT _opendistro/_security/api/ssl/http/reloadcerts
 Introduced 1.0
 {: .label .label-purple }
 
-Flushes the security plugin user, authentication, and authorization cache.
+Flushes the Security plugin user, authentication, and authorization cache.
 
 
 #### Request
@@ -1392,7 +1392,7 @@ DELETE _plugins/_security/api/cache
 Introduced 1.0
 {: .label .label-purple }
 
-Checks to see if the security plugin is up and running. If you operate your cluster behind a load balancer, this operation is useful for determining node health and doesn't require a signed request.
+Checks to see if the Security plugin is up and running. If you operate your cluster behind a load balancer, this operation is useful for determining node health and doesn't require a signed request.
 
 
 #### Request
@@ -1417,7 +1417,7 @@ GET _plugins/_security/health
 
 ## Audit logs
 
-The following API is available for audit logging in the security plugin.
+The following API is available for audit logging in the Security plugin.
 
 ### Enable Audit Logs
 

_security/access-control/cross-cluster-search.md

@@ -7,7 +7,7 @@ nav_order: 105
 
 # Cross-cluster search
 
-Cross-cluster search is exactly what it sounds like: it lets any node in a cluster execute search requests against other clusters. The security plugin supports cross-cluster search out of the box.
+Cross-cluster search is exactly what it sounds like: it lets any node in a cluster execute search requests against other clusters. The Security plugin supports cross-cluster search out of the box.
 
 ---
 
@@ -22,8 +22,8 @@ Cross-cluster search is exactly what it sounds like: it lets any node in a clust
 
 When accessing a *remote cluster* from a *coordinating cluster* using cross-cluster search:
 
-1. The security plugin authenticates the user on the coordinating cluster.
+1. The Security plugin authenticates the user on the coordinating cluster.
-1. The security plugin fetches the user's backend roles on the coordinating cluster.
+1. The Security plugin fetches the user's backend roles on the coordinating cluster.
 1. The call, including the authenticated user, is forwarded to the remote cluster.
 1. The user's permissions are evaluated on the remote cluster.
 

_security/access-control/document-level-security.md

@@ -163,7 +163,7 @@ PUT _plugins/_security/api/roles/abac
 
 You can perform term-level lookup queries (TLQs) with document-level security (DLS) using either of two modes: adaptive or filter level. The default mode is adaptive, where OpenSearch automatically switches between Lucene-level or filter-level mode depending on whether or not there is a TLQ. DLS queries without TLQs are executed in Lucene-level mode, whereas DLS queries with TLQs are executed in filter-level mode.
 
-By default, the security plugin detects if a DLS query contains a TLQ or not and chooses the appropriate mode automatically at runtime.
+By default, the Security plugin detects if a DLS query contains a TLQ or not and chooses the appropriate mode automatically at runtime.
 
 To learn more about OpenSearch queries, see [Term-level queries]({{site.url}}{{site.baseurl}}/opensearch/query-dsl/term/).
 

_security/access-control/field-level-security.md

@@ -98,7 +98,7 @@ See [Create role]({{site.url}}{{site.baseurl}}/security/access-control/api/#crea
 
 ## Interaction with multiple roles
 
-If you map a user to multiple roles, we recommend that those roles use either include *or* exclude statements for each index. The security plugin evaluates field-level security settings using the `AND` operator, so combining include and exclude statements can lead to neither behavior working properly.
+If you map a user to multiple roles, we recommend that those roles use either include *or* exclude statements for each index. The Security plugin evaluates field-level security settings using the `AND` operator, so combining include and exclude statements can lead to neither behavior working properly.
 
 For example, in the `movies` index, if you include `actors`, `title`, and `year` in one role, exclude `actors`, `title`, and `genres` in another role, and then map both roles to the same user, a search result might look like this:
 

_security/access-control/field-masking.md

@@ -73,7 +73,7 @@ See [Create role]({{site.url}}{{site.baseurl}}/security/access-control/api/#crea
 
 ## (Advanced) Use an alternative hash algorithm
 
-By default, the security plugin uses the BLAKE2b algorithm, but you can use any hashing algorithm that your JVM provides. This list typically includes MD5, SHA-1, SHA-384, and SHA-512.
+By default, the Security plugin uses the BLAKE2b algorithm, but you can use any hashing algorithm that your JVM provides. This list typically includes MD5, SHA-1, SHA-384, and SHA-512.
 
 To specify a different algorithm, add it after the masked field:
 

_security/access-control/index.md

@@ -26,4 +26,4 @@ Backend role | (Optional) Arbitrary strings that you specify *or* that come from
 User | Users make requests to OpenSearch clusters. A user has credentials (e.g. a username and password), zero or more backend roles, and zero or more custom attributes.
 Role mapping | Users assume roles after they successfully authenticate. Role mappings, well, map roles to users (or backend roles). For example, a mapping of `kibana_user` (role) to `jdoe` (user) means that John Doe gains all the permissions of `kibana_user` after authenticating. Likewise, a mapping of `all_access` (role) to `admin` (backend role) means that any user with the backend role of `admin` gains all the permissions of `all_access` after authenticating. You can map each role to many users and/or backend roles.
 
-The security plugin comes with a number of [predefined action groups]({{site.url}}{{site.baseurl}}/security/access-control/default-action-groups/), roles, mappings, and users. These entities serve as sensible defaults and are good examples of how to use the plugin.
+The Security plugin comes with a number of [predefined action groups]({{site.url}}{{site.baseurl}}/security/access-control/default-action-groups/), roles, mappings, and users. These entities serve as sensible defaults and are good examples of how to use the plugin.

_security/access-control/permissions.md

@@ -9,13 +9,13 @@ redirect_from:
 
 # Permissions
 
-Each permission in the security plugin controls access to some action that the OpenSearch cluster can perform, such as indexing a document or checking cluster health.
+Each permission in the Security plugin controls access to some action that the OpenSearch cluster can perform, such as indexing a document or checking cluster health.
 
 Most permissions are self-describing. For example, `cluster:admin/ingest/pipeline/get` lets you retrieve information about ingest pipelines. _In many cases_, a permission correlates to a specific REST API operation, such as `GET _ingest/pipeline`.
 
 Despite this correlation, permissions do **not** directly map to REST API operations. Operations such as `POST _bulk` and `GET _msearch` can access many indices and perform many actions in a single request. Even a simple request, such as `GET _cat/nodes`, performs several actions in order to generate its response.
 
-In short, controlling access to the REST API is insufficient. Instead, the security plugin controls access to the underlying OpenSearch actions.
+In short, controlling access to the REST API is insufficient. Instead, the Security plugin controls access to the underlying OpenSearch actions.
 
 For example, consider the following `_bulk` request:
 
@@ -43,7 +43,7 @@ These permissions also allow you add, update, or delete documents (e.g. `PUT tes
 
 ## Test permissions
 
-If you want a user to have the absolute minimum set of permissions necessary to perform some function—the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)—the best way is to send representative requests to your cluster as a new test user. In the case of a permissions error, the security plugin is very explicit about which permissions are missing. Consider this request and response:
+If you want a user to have the absolute minimum set of permissions necessary to perform some function—the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)—the best way is to send representative requests to your cluster as a new test user. In the case of a permissions error, the Security plugin is very explicit about which permissions are missing. Consider this request and response:
 
 ```json
 GET _cat/shards?v

_security/access-control/users-roles.md

@@ -7,7 +7,7 @@ nav_order: 80
 
 # Users and roles
 
-The security plugin includes an internal user database. Use this database in place of or in addition to an external authentication system such as LDAP or Active Directory.
+The Security plugin includes an internal user database. Use this database in place of or in addition to an external authentication system such as LDAP or Active Directory.
 
 Roles are the core way of controlling access to your cluster. Roles contain any combination of cluster-wide permissions, index-specific permissions, document- and field-level security, and tenants. Then you map users to these roles so that users gain those permissions.
 
@@ -30,7 +30,7 @@ You can create users using OpenSearch Dashboards, `internal_users.yml`, or the R
 ### OpenSearch Dashboards
 
 1. Choose **Security**, **Internal Users**, and **Create internal user**.
-1. Provide a username and password. The security plugin automatically hashes the password and stores it in the `.opendistro_security` index.
+1. Provide a username and password. The Security plugin automatically hashes the password and stores it in the `.opendistro_security` index.
 1. If desired, specify user attributes.
 
    Attributes are optional user properties that you can use for variable substitution in index permissions or document-level security.
@@ -99,7 +99,7 @@ See [Create role mapping]({{site.url}}{{site.baseurl}}/security/access-control/a
 
 ## Predefined roles
 
-The security plugin includes several predefined roles that serve as useful defaults.
+The Security plugin includes several predefined roles that serve as useful defaults.
 
 | **Role** | **Description** |
 | :--- | :--- |

_security/audit-logs/index.md

@@ -47,8 +47,8 @@ Event | Logged on REST | Logged on transport | Description
 `MISSING_PRIVILEGES` | No | Yes | The user does not have the required permissions to execute the request.
 `GRANTED_PRIVILEGES` | No | Yes | A user made a successful request to OpenSearch.
 `SSL_EXCEPTION` | Yes | Yes | An attempt was made to access OpenSearch without a valid SSL/TLS certificate.
-`opensearch_SECURITY_INDEX_ATTEMPT` | No | Yes | An attempt was made to modify the security plugin internal user and privileges index without the required permissions or TLS admin certificate.
+`opensearch_SECURITY_INDEX_ATTEMPT` | No | Yes | An attempt was made to modify the Security plugin internal user and privileges index without the required permissions or TLS admin certificate.
-`BAD_HEADERS` | Yes | Yes | An attempt was made to spoof a request to OpenSearch with the security plugin internal headers.
+`BAD_HEADERS` | Yes | Yes | An attempt was made to spoof a request to OpenSearch with the Security plugin internal headers.
 
 These default log settings work well for most use cases, but you can change settings to save storage space or adapt the information to your exact needs.
 
@@ -79,7 +79,7 @@ plugins.security.audit.config.disabled_transport_categories: NONE
 
 ## Disable REST or the transport layer
 
-By default, the security plugin logs events on both REST and the transport layer. You can disable either type:
+By default, the Security plugin logs events on both REST and the transport layer. You can disable either type:
 
 ```yml
 plugins.security.audit.enable_rest: false
@@ -89,7 +89,7 @@ plugins.security.audit.enable_transport: false
 
 ## Disable request body logging
 
-By default, the security plugin includes the body of the request (if available) for both REST and the transport layer. If you do not want or need the request body, you can disable it:
+By default, the Security plugin includes the body of the request (if available) for both REST and the transport layer. If you do not want or need the request body, you can disable it:
 
 ```yml
 plugins.security.audit.log_request_body: false
@@ -98,7 +98,7 @@ plugins.security.audit.log_request_body: false
 
 ## Log index names
 
-By default, the security plugin logs all indices affected by a request. Because index names can be aliases and contain wildcards/date patterns, the security plugin logs the index name that the user submitted *and* the actual index name to which it resolves.
+By default, the Security plugin logs all indices affected by a request. Because index names can be aliases and contain wildcards/date patterns, the Security plugin logs the index name that the user submitted *and* the actual index name to which it resolves.
 
 For example, if you use an alias or a wildcard, the audit event might look like:
 
@@ -123,9 +123,9 @@ Disabling this feature only takes effect if `plugins.security.audit.log_request_
 
 ## Configure bulk request handling
 
-Bulk requests can contain many indexing operations. By default, the security plugin only logs the single bulk request, not each individual operation.
+Bulk requests can contain many indexing operations. By default, the Security plugin only logs the single bulk request, not each individual operation.
 
-The security plugin can be configured to log each indexing operation as a separate event:
+The Security plugin can be configured to log each indexing operation as a separate event:
 
 ```yml
 plugins.security.audit.resolve_bulk_requests: true
@@ -145,7 +145,7 @@ plugins.security.audit.ignore_requests: ["indices:data/read/*", "SearchRequest"]
 
 ## Exclude users
 
-By default, the security plugin logs events from all users, but excludes the internal OpenSearch Dashboards server user `kibanaserver`. You can exclude other users:
+By default, the Security plugin logs events from all users, but excludes the internal OpenSearch Dashboards server user `kibanaserver`. You can exclude other users:
 
 ```yml
 plugins.security.audit.ignore_users:
@@ -162,7 +162,7 @@ plugins.security.audit.ignore_users: NONE
 
 ## Configure the audit log index name
 
-By default, the security plugin stores audit events in a daily rolling index named `auditlog-YYYY.MM.dd`. You can configure the name of the index in `opensearch.yml`:
+By default, the Security plugin stores audit events in a daily rolling index named `auditlog-YYYY.MM.dd`. You can configure the name of the index in `opensearch.yml`:
 
 ```yml
 plugins.security.audit.config.index: myauditlogindex

_security/audit-logs/storage-types.md

@@ -7,7 +7,7 @@ nav_order: 135
 
 # Audit log storage types
 
-Audit logs can take up quite a bit of space, so the security plugin offers several options for storage locations.
+Audit logs can take up quite a bit of space, so the Security plugin offers several options for storage locations.
 
 Setting | Description
 :--- | :---
@@ -37,13 +37,13 @@ plugins.security.audit.config.index: <indexname>
 plugins.security.audit.config.type: _doc
 ```
 
-The security plugin uses the OpenSearch REST API to send events, just like any other indexing request. For `plugins.security.audit.config.http_endpoints`, use a comma-separated list of hosts/IP addresses and the REST port (default 9200).
+The Security plugin uses the OpenSearch REST API to send events, just like any other indexing request. For `plugins.security.audit.config.http_endpoints`, use a comma-separated list of hosts/IP addresses and the REST port (default 9200).
 
 ```
 plugins.security.audit.config.http_endpoints: [192.168.178.1:9200,192.168.178.2:9200]
 ```
 
-If you use `external_opensearch` and the remote cluster also uses the security plugin, you must supply some additional parameters for authentication. These parameters depend on which authentication type you configured for the remote cluster.
+If you use `external_opensearch` and the remote cluster also uses the Security plugin, you must supply some additional parameters for authentication. These parameters depend on which authentication type you configured for the remote cluster.
 
 
 ### TLS settings
@@ -105,4 +105,4 @@ plugins.security.audit.config.log4j.logger_name: audit
 plugins.security.audit.config.log4j.level: INFO
 ```
 
-By default, the security plugin uses the logger name `audit` and logs the events on `INFO` level. Audit events are stored in JSON format.
+By default, the Security plugin uses the logger name `audit` and logs the events on `INFO` level. Audit events are stored in JSON format.

_security/authentication-backends/authc-index.md

@@ -20,11 +20,11 @@ Authentication backend configurations determine the method or methods you use fo
 
 2. The Security plugin authenticates a request against a backend configured for an authentication provider. Some examples of authentication providers used with OpenSearch include Basic Auth (which uses the internal user database), LDAP/Active Directory, JSON web tokens, SAML, or another authentication protocol.
 
-   The plugin supports chaining backends in `config/opensearch-security/config.yml`. If more than one backend is present, the plugin tries to authenticate the user sequentially against each until one succeeds. A common use case is to combine the internal user database of the security plugin with LDAP/Active Directory.
+   The plugin supports chaining backends in `config/opensearch-security/config.yml`. If more than one backend is present, the plugin tries to authenticate the user sequentially against each until one succeeds. A common use case is to combine the internal user database of the Security plugin with LDAP/Active Directory.
 
 3. After a backend verifies the user's credentials, the plugin collects any [backend roles]({{site.url}}{{site.baseurl}}/security/access-control/index/#concepts). The authentication provider determines the way these roles are retrieved. For example, LDAP extracts backend roles from its directory service based on their mappings to roles in OpenSearch, while SAML stores the roles as attributes. When basic authentication is used, the internal user database refers to role mappings configured in OpenSearch.
 
-4. After the user is authenticated and any backend roles are retrieved, the security plugin uses the role mapping to assign security roles to the user.
+4. After the user is authenticated and any backend roles are retrieved, the Security plugin uses the role mapping to assign security roles to the user.
 
    If the role mapping doesn't include the user (or the user's backend roles), the user is successfully authenticated, but has no permissions.
 

_security/authentication-backends/ldap.md

@@ -12,7 +12,7 @@ redirect_from:
 
 Active Directory and LDAP can be used for both authentication and authorization (the `authc` and `authz` sections of the configuration, respectively). Authentication checks whether the user has entered valid credentials. Authorization retrieves any backend roles for the user.
 
-In most cases, you want to configure both authentication and authorization. You can also use authentication only and map the users retrieved from LDAP directly to security plugin roles.
+In most cases, you want to configure both authentication and authorization. You can also use authentication only and map the users retrieved from LDAP directly to Security plugin roles.
 
 
 ## Docker example
@@ -29,7 +29,7 @@ We provide a fully functional example that can help you understand how to use an
 
    * `directory.ldif` seeds the LDAP server with three users and two groups.
 
-     `psantos` is in the `Administrator` and `Developers` groups. `jroe` and `jdoe` are in the `Developers` group. The security plugin loads these groups as backend roles.
+     `psantos` is in the `Administrator` and `Developers` groups. `jroe` and `jdoe` are in the `Developers` group. The Security plugin loads these groups as backend roles.
 
    * `roles_mapping.yml` maps the `Administrator` and `Developers` LDAP groups (as backend roles) to security roles so that users gain the appropriate permissions after authenticating.
 
@@ -100,7 +100,7 @@ config:
     - secondary.ldap.example.com:389
 ```
 
-You can configure more than one server here. If the security plugin cannot connect to the first server, it tries to connect to the remaining servers sequentially.
+You can configure more than one server here. If the Security plugin cannot connect to the first server, it tries to connect to the remaining servers sequentially.
 
 
 ### Timeouts
@@ -118,7 +118,7 @@ If your server supports two-factor authentication (2FA), the default timeout set
 
 ### Bind DN and password
 
-To configure the `bind_dn` and `password` that the security plugin uses when issuing queries to your server, use the following:
+To configure the `bind_dn` and `password` that the Security plugin uses when issuing queries to your server, use the following:
 
 ```yml
 config:
@@ -151,7 +151,7 @@ Name | Description
 
 ### Certificate validation
 
-By default, the security plugin validates the TLS certificate of the LDAP servers against the root CA configured in `opensearch.yml`, either as a PEM certificate or a truststore:
+By default, the Security plugin validates the TLS certificate of the LDAP servers against the root CA configured in `opensearch.yml`, either as a PEM certificate or a truststore:
 
 ```
 plugins.security.ssl.transport.pemtrustedcas_filepath: ...
@@ -185,7 +185,7 @@ Name | Description
 
 ### Client authentication
 
-If you use TLS client authentication, the security plugin sends the PEM certificate of the node, as configured in `opensearch.yml`. Set one of the following configuration options:
+If you use TLS client authentication, the Security plugin sends the PEM certificate of the node, as configured in `opensearch.yml`. Set one of the following configuration options:
 
 ```yml
 config:
@@ -283,7 +283,7 @@ config:
 
 Authentication works by issuing an LDAP query containing the user name against the user subtree of the LDAP tree.
 
-The security plugin first takes the configured LDAP query and replaces the placeholder `{0}` with the user name from the user's credentials.
+The Security plugin first takes the configured LDAP query and replaces the placeholder `{0}` with the user name from the user's credentials.
 
 ```yml
 usersearch: '(sAMAccountName={0})'
@@ -295,7 +295,7 @@ Then it issues this query against the user subtree. Currently, the entire subtre
 userbase: 'ou=people,dc=example,dc=com'
 ```
 
-If the query is successful, the security plugin retrieves the user name from the LDAP entry. You can specify which attribute from the LDAP entry the security plugin should use as the user name:
+If the query is successful, the Security plugin retrieves the user name from the LDAP entry. You can specify which attribute from the LDAP entry the Security plugin should use as the user name:
 
 ```yml
 username_attribute: uid
@@ -309,8 +309,8 @@ If this key is not set or null, then the distinguished name (DN) of the LDAP ent
 Name | Description
 :--- | :---
 `userbase` | Specifies the subtree in the directory where user information is stored.
-`usersearch` | The actual LDAP query that the security plugin executes when trying to authenticate a user. The variable {0} is substituted with the user name.
+`usersearch` | The actual LDAP query that the Security plugin executes when trying to authenticate a user. The variable {0} is substituted with the user name.
-`username_attribute` | The security plugin uses this attribute of the directory entry to look for the user name. If set to null, the DN is used (default).
+`username_attribute` | The Security plugin uses this attribute of the directory entry to look for the user name. If set to null, the DN is used (default).
 
 
 ### Complete authentication example
@@ -359,16 +359,16 @@ authz:
 
 Authorization is the process of retrieving backend roles for an authenticated user from an LDAP server. This is typically the same servers that you use for authentication, but you can also use a different server. The only requirement is that the user you use to fetch the roles actually exists on the LDAP server.
 
-Because the security plugin always checks if a user exists in the LDAP server, you must also configure `userbase`, `usersearch` and `username_attribute` in the `authz` section.
+Because the Security plugin always checks if a user exists in the LDAP server, you must also configure `userbase`, `usersearch` and `username_attribute` in the `authz` section.
 
-Authorization works similarly to authentication. The security plugin issues an LDAP query containing the user name against the role subtree of the LDAP tree.
+Authorization works similarly to authentication. The Security plugin issues an LDAP query containing the user name against the role subtree of the LDAP tree.
 
-As an alternative, the security plugin can also fetch roles that are defined as a direct attribute of the user entry in the user subtree.
+As an alternative, the Security plugin can also fetch roles that are defined as a direct attribute of the user entry in the user subtree.
 
 
 ### Approach 1: Query the role subtree
 
-The security plugin first takes the LDAP query for fetching roles ("rolesearch") and substitutes any variables found in the query. For example, for a standard Active Directory installation, you would use the following role search:
+The Security plugin first takes the LDAP query for fetching roles ("rolesearch") and substitutes any variables found in the query. For example, for a standard Active Directory installation, you would use the following role search:
 
 ```yml
 rolesearch: '(member={0})'
@@ -386,25 +386,25 @@ The variable `{2}` refers to an attribute from the user's directory entry. The a
 userroleattribute: myattribute
 ```
 
-The security plugin then issues the substituted query against the configured role subtree. The entire subtree under `rolebase` is searched:
+The Security plugin then issues the substituted query against the configured role subtree. The entire subtree under `rolebase` is searched:
 
 ```yml
 rolebase: 'ou=groups,dc=example,dc=com'
 ```
 
-If you use nested roles (roles that are members of other roles), you can configure the security plugin to resolve them:
+If you use nested roles (roles that are members of other roles), you can configure the Security plugin to resolve them:
 
 ```yml
 resolve_nested_roles: false
 ```
 
-After all roles have been fetched, the security plugin extracts the final role names from a configurable attribute of the role entries:
+After all roles have been fetched, the Security plugin extracts the final role names from a configurable attribute of the role entries:
 
 ```yml
 rolename: cn
 ```
 
-If this is not set, the DN of the role entry is used. You can now use this role name for mapping it to one or more of the security plugin roles, as defined in `roles_mapping.yml`.
+If this is not set, the DN of the role entry is used. You can now use this role name for mapping it to one or more of the Security plugin roles, as defined in `roles_mapping.yml`.
 
 
 ### Approach 2: Use a user's attribute as the role name
@@ -421,7 +421,7 @@ You can configure multiple attribute names:
 userrolename: roles, otherroles
 ```
 
-This approach can be combined with querying the role subtree. The security plugin fetches the roles from the user's role attribute and then executes the role search.
+This approach can be combined with querying the role subtree. The Security plugin fetches the roles from the user's role attribute and then executes the role search.
 
 If you don't use or have a role subtree, you can disable the role search completely:
 
@@ -432,7 +432,7 @@ rolesearch_enabled: false
 
 ### (Advanced) Control LDAP user attributes
 
-By default, the security plugin reads all LDAP user attributes and makes them available for index name variable substitution and DLS query variable substitution. If your LDAP entries have a lot of attributes, you might want to control which attributes should be made available. The fewer the attributes, the better the performance.
+By default, the Security plugin reads all LDAP user attributes and makes them available for index name variable substitution and DLS query variable substitution. If your LDAP entries have a lot of attributes, you might want to control which attributes should be made available. The fewer the attributes, the better the performance.
 
 Note that this setting is made in the authentication `authc` section of the config.yml file.
 
@@ -465,7 +465,7 @@ If you are using multiple authentication methods, it can make sense to exclude c
 
 Consider the following scenario for a typical OpenSearch Dashboards setup: All OpenSearch Dashboards users are stored in an LDAP/Active Directory server.
 
-However, you also have an OpenSearch Dashboards server user. OpenSearch Dashboards uses this user to manage stored objects and perform monitoring and maintenance tasks. You do not want to add this user to your Active Directory installation, but rather store it in the security plugin internal user database.
+However, you also have an OpenSearch Dashboards server user. OpenSearch Dashboards uses this user to manage stored objects and perform monitoring and maintenance tasks. You do not want to add this user to your Active Directory installation, but rather store it in the Security plugin internal user database.
 
 In this case, it makes sense to exclude the OpenSearch Dashboards server user from the LDAP authorization because we already know that there is no corresponding entry. You can use the `skip_users` configuration setting to define which users should be skipped. Wildcards and regular expressions are supported:
 
@@ -497,7 +497,7 @@ nested_role_filter:
 Name | Description
 :--- | :---
 `rolebase`  | Specifies the subtree in the directory where role/group information is stored.
-`rolesearch` | The actual LDAP query that the security plugin executes when trying to determine the roles of a user. You can use three variables here (see below).
+`rolesearch` | The actual LDAP query that the Security plugin executes when trying to determine the roles of a user. You can use three variables here (see below).
 `userroleattribute`  | The attribute in a user entry to use for `{2}` variable substitution.
 `userrolename`  | If the roles/groups of a user are not stored in the groups subtree, but as an attribute of the user's directory entry, define this attribute name here.
 `rolename`  | The attribute of the role entry that should be used as the role name.

_security/authentication-backends/proxy.md

@@ -9,9 +9,9 @@ nav_order: 65
 
 If you already have a single sign-on (SSO) solution in place, you might want to use it as an authentication backend.
 
-Most solutions work as a proxy in front of OpenSearch and the security plugin. If proxy authentication succeeds, the proxy adds the (verified) username and its (verified) roles in HTTP header fields. The names of these fields depend on the SSO solution you have in place.
+Most solutions work as a proxy in front of OpenSearch and the Security plugin. If proxy authentication succeeds, the proxy adds the (verified) username and its (verified) roles in HTTP header fields. The names of these fields depend on the SSO solution you have in place.
 
-The security plugin then extracts these HTTP header fields from the request and uses the values to determine the user's permissions.
+The Security plugin then extracts these HTTP header fields from the request and uses the values to determine the user's permissions.
 
 
 ## Enable proxy detection
@@ -42,7 +42,7 @@ Name | Description
 `internalProxies` | A regular expression containing the IP addresses of all trusted proxies. The pattern `.*` trusts all internal proxies.
 `remoteIpHeader` | Name of the HTTP header field that has the hostname chain. Default is `x-forwarded-for`.
 
-To determine whether a request comes from a trusted internal proxy, the security plugin compares the remote address of the HTTP request with the list of configured internal proxies.  If the remote address is not in the list, the plugin treats the request like a client request.
+To determine whether a request comes from a trusted internal proxy, the Security plugin compares the remote address of the HTTP request with the list of configured internal proxies.  If the remote address is not in the list, the plugin treats the request like a client request.
 
 
 ## Enable proxy authentication
@@ -67,13 +67,13 @@ proxy_auth_domain:
 Name | Description
 :--- | :---
 `user_header` | The HTTP header field containing the authenticated username. Default is `x-proxy-user`.
-`roles_header` | The HTTP header field containing the comma-separated list of authenticated role names. The security plugin uses the roles found in this header field as backend roles. Default is `x-proxy-roles`.
+`roles_header` | The HTTP header field containing the comma-separated list of authenticated role names. The Security plugin uses the roles found in this header field as backend roles. Default is `x-proxy-roles`.
 `roles_separator` | The separator for roles. Default is `,`.
 
 
 ## Enable extended proxy authentication
 
-The security plugin has an extended version of the `proxy` type that lets you pass additional user attributes for use with document-level security. Aside from `type: extended-proxy` and `attr_header_prefix`, configuration is identical:
+The Security plugin has an extended version of the `proxy` type that lets you pass additional user attributes for use with document-level security. Aside from `type: extended-proxy` and `attr_header_prefix`, configuration is identical:
 
 ```yml
 proxy_auth_domain:
@@ -168,12 +168,12 @@ enabled: true
 internalProxies: '172.16.0.203' # nginx proxy
 ```
 
-In this case, `nginx.example.com` runs on `172.16.0.203`, so add this IP to the list of internal proxies. Be sure to set `internalProxies` to the minimum number of IP addresses so that the security plugin only accepts requests from trusted IPs.
+In this case, `nginx.example.com` runs on `172.16.0.203`, so add this IP to the list of internal proxies. Be sure to set `internalProxies` to the minimum number of IP addresses so that the Security plugin only accepts requests from trusted IPs.
 
 
 ## OpenSearch Dashboards proxy authentication
 
-To use proxy authentication with OpenSearch Dashboards, the most common configuration is to place the proxy in front of OpenSearch Dashboards and let OpenSearch Dashboards pass the user and role headers to the security plugin.
+To use proxy authentication with OpenSearch Dashboards, the most common configuration is to place the proxy in front of OpenSearch Dashboards and let OpenSearch Dashboards pass the user and role headers to the Security plugin.
 
 In this case, the remote address of the HTTP call is the IP of OpenSearch Dashboards, because it sits directly in front of OpenSearch. Add the IP of OpenSearch Dashboards to the list of internal proxies:
 
@@ -192,7 +192,7 @@ config:
         internalProxies: '<opensearch-dashboards-ip-address>'
 ```
 
-To pass the user and role headers that the authenticating proxy adds from OpenSearch Dashboards to the security plugin, add them to the HTTP header allow list in `opensearch_dashboards.yml`:
+To pass the user and role headers that the authenticating proxy adds from OpenSearch Dashboards to the Security plugin, add them to the HTTP header allow list in `opensearch_dashboards.yml`:
 
 ```yml
 opensearch.requestHeadersAllowlist: ["securitytenant","Authorization","x-forwarded-for","x-proxy-user","x-proxy-roles"]

_security/configuration/disable.md

@@ -7,28 +7,28 @@ nav_order: 40
 
 # Disabling security
 
-You might want to temporarily disable the security plugin to make testing or internal usage more straightforward. To disable the plugin, add the following line in `opensearch.yml`:
+You might want to temporarily disable the Security plugin to make testing or internal usage more straightforward. To disable the plugin, add the following line in `opensearch.yml`:
 
 ```yml
 plugins.security.disabled: true
 ```
 
-A more permanent option is to remove the security plugin entirely:
+A more permanent option is to remove the Security plugin entirely:
 
 1. Delete the `plugins/opensearch-security` folder on all nodes.
 1. Delete all `plugins.security.*` configuration entries from `opensearch.yml`.
 
 To perform these steps on the Docker image, see [Working with plugins]({{site.url}}{{site.baseurl}}/opensearch/install/docker#working-with-plugins).
 
-Disabling or removing the plugin exposes the configuration index for the security plugin. If the index contains sensitive information, be sure to protect it through some other means. If you no longer need the index, delete it.
+Disabling or removing the plugin exposes the configuration index for the Security plugin. If the index contains sensitive information, be sure to protect it through some other means. If you no longer need the index, delete it.
 {: .warning }
 
 
 ## Remove OpenSearch Dashboards plugin
 
-The security plugin is actually two plugins: one for OpenSearch and one for OpenSearch Dashboards. You can use the OpenSearch plugin independently, but the OpenSearch Dashboards plugin depends on a secured OpenSearch cluster.
+The Security plugin is actually two plugins: one for OpenSearch and one for OpenSearch Dashboards. You can use the OpenSearch plugin independently, but the OpenSearch Dashboards plugin depends on a secured OpenSearch cluster.
 
-If you disable the security plugin in `opensearch.yml` (or delete the plugin entirely) and still want to use OpenSearch Dashboards, you must remove the corresponding OpenSearch Dashboards plugin. For more information, see [OpenSearch Dashboards remove plugins]({{site.url}}{{site.baseurl}}/install-and-configure/install-dashboards/plugins/#remove-plugins).
+If you disable the Security plugin in `opensearch.yml` (or delete the plugin entirely) and still want to use OpenSearch Dashboards, you must remove the corresponding OpenSearch Dashboards plugin. For more information, see [OpenSearch Dashboards remove plugins]({{site.url}}{{site.baseurl}}/install-and-configure/install-dashboards/plugins/#remove-plugins).
 
 
 ### Docker
@@ -41,7 +41,7 @@ If you disable the security plugin in `opensearch.yml` (or delete the plugin ent
    COPY --chown=opensearch-dashboards:opensearch-dashboards opensearch_dashboards.yml /usr/share/opensearch-dashboards/config/
    ```
 
-   In this case, `opensearch_dashboards.yml` is a "vanilla" version of the file with no entries for the security plugin. It might look like this:
+   In this case, `opensearch_dashboards.yml` is a "vanilla" version of the file with no entries for the Security plugin. It might look like this:
 
    ```yml
    ---

_security/configuration/generate-certificates.md

@@ -235,7 +235,7 @@ For more information about adding and using these certificates in your own setup
 
 ## Run securityadmin.sh
 
-After configuring your certificates and starting OpenSearch, run `securityadmin.sh` to initialize the security plugin. For information about how to use this script, see [Applying changes to configuration files]({{site.url}}{{site.baseurl}}/security/configuration/security-admin/).
+After configuring your certificates and starting OpenSearch, run `securityadmin.sh` to initialize the Security plugin. For information about how to use this script, see [Applying changes to configuration files]({{site.url}}{{site.baseurl}}/security/configuration/security-admin/).
 
 
 ## OpenSearch Dashboards

_security/configuration/index.md

@@ -24,5 +24,5 @@ The plugin includes demo certificates so that you can get up and running quickly
 
 If you don't want to use the plugin, see [Disable security]({{site.url}}{{site.baseurl}}/security/configuration/disable).
 
-The security plugin has several default users, roles, action groups, permissions, and settings for OpenSearch Dashboards that use kibana in their names. We will change these names in a future release.
+The Security plugin has several default users, roles, action groups, permissions, and settings for OpenSearch Dashboards that use kibana in their names. We will change these names in a future release.
 {: .note }

_security/configuration/tls.md

@@ -42,7 +42,7 @@ Name | Description
 
 ## Keystore and truststore files
 
-As an alternative to certificates and private keys in PEM format, you can instead use keystore and truststore files in JKS or PKCS12/PFX format. For the security plugin to operate, you need certificates and private keys.
+As an alternative to certificates and private keys in PEM format, you can instead use keystore and truststore files in JKS or PKCS12/PFX format. For the Security plugin to operate, you need certificates and private keys.
 
 The following settings configure the location and password of your keystore and truststore files. If you want, you can use different keystore and truststore files for the REST and the transport layer.
 
@@ -78,7 +78,7 @@ Name | Description
 
 ## Configuring node certificates
 
-OpenSearch Security needs to identify requests between the nodes in the cluster. It uses node certificates to secure these requests. The simplest way to configure node certificates is to list the Distinguished Names (DNs) of these certificates in `opensearch.yml`. All DNs must be included in `opensearch.yml` on all nodes. Keep in mind that the security plugin supports wildcards and regular expressions:
+OpenSearch Security needs to identify requests between the nodes in the cluster. It uses node certificates to secure these requests. The simplest way to configure node certificates is to list the Distinguished Names (DNs) of these certificates in `opensearch.yml`. All DNs must be included in `opensearch.yml` on all nodes. Keep in mind that the Security plugin supports wildcards and regular expressions:
 
 ```yml
 plugins.security.nodes_dn:
@@ -93,7 +93,7 @@ If your node certificates have an Object ID (OID) identifier in the SAN section,
 
 ## Configuring admin certificates
 
-Admin certificates are regular client certificates that have elevated rights to perform administrative tasks. You need an admin certificate to change the security plugin configuration using [`plugins/opensearch-security/tools/securityadmin.sh`]({{site.url}}{{site.baseurl}}/security/configuration/security-admin/) or the REST API. Admin certificates are configured in `opensearch.yml` by stating their DN(s):
+Admin certificates are regular client certificates that have elevated rights to perform administrative tasks. You need an admin certificate to change the Security plugin configuration using [`plugins/opensearch-security/tools/securityadmin.sh`]({{site.url}}{{site.baseurl}}/security/configuration/security-admin/) or the REST API. Admin certificates are configured in `opensearch.yml` by stating their DN(s):
 
 ```yml
 plugins.security.authcz.admin_dn:
@@ -105,11 +105,11 @@ For security reasons, you can't use wildcards or regular expressions here.
 
 ## (Advanced) OpenSSL
 
-The security plugin supports OpenSSL, but we only recommend it if you use Java 8. If you use Java 11, we recommend the default configuration.
+The Security plugin supports OpenSSL, but we only recommend it if you use Java 8. If you use Java 11, we recommend the default configuration.
 
 To use OpenSSL, you must install OpenSSL, the Apache Portable Runtime, and a Netty version with OpenSSL support matching your platform on all nodes.
 
-If OpenSSL is enabled, but for one reason or another the installation does not work, the security plugin falls back to the Java JCE as the security engine.
+If OpenSSL is enabled, but for one reason or another the installation does not work, the Security plugin falls back to the Java JCE as the security engine.
 
 Name | Description
 :--- | :---
@@ -128,16 +128,16 @@ Name | Description
 
 ## (Advanced) Hostname verification and DNS lookup
 
-In addition to verifying the TLS certificates against the root CA and/or intermediate CA(s), the security plugin can apply additional checks on the transport layer.
+In addition to verifying the TLS certificates against the root CA and/or intermediate CA(s), the Security plugin can apply additional checks on the transport layer.
 
-With `enforce_hostname_verification` enabled, the security plugin verifies that the hostname of the communication partner matches the hostname in the certificate. The hostname is taken from the `subject` or `SAN` entries of your certificate. For example, if the hostname of your node is `node-0.example.com`, then the hostname in the TLS certificate has to be set to `node-0.example.com`, as well. Otherwise, errors are thrown:
+With `enforce_hostname_verification` enabled, the Security plugin verifies that the hostname of the communication partner matches the hostname in the certificate. The hostname is taken from the `subject` or `SAN` entries of your certificate. For example, if the hostname of your node is `node-0.example.com`, then the hostname in the TLS certificate has to be set to `node-0.example.com`, as well. Otherwise, errors are thrown:
 
 ```
 [ERROR][c.a.o.s.s.t.opensearchSecuritySSLNettyTransport] [WX6omJY] SSL Problem No name matching <hostname> found
 [ERROR][c.a.o.s.s.t.opensearchSecuritySSLNettyTransport] [WX6omJY] SSL Problem Received fatal alert: certificate_unknown
 ```
 
-In addition, when `resolve_hostname` is enabled, the security plugin resolves the (verified) hostname against your DNS. If the hostname does not resolve, errors are thrown:
+In addition, when `resolve_hostname` is enabled, the Security plugin resolves the (verified) hostname against your DNS. If the hostname does not resolve, errors are thrown:
 
 
 Name | Description
@@ -148,7 +148,7 @@ Name | Description
 
 ## (Advanced) Client authentication
 
-With TLS client authentication enabled, REST clients can send a TLS certificate with the HTTP request to provide identity information to the security plugin. There are three main usage scenarios for TLS client authentication:
+With TLS client authentication enabled, REST clients can send a TLS certificate with the HTTP request to provide identity information to the Security plugin. There are three main usage scenarios for TLS client authentication:
 
 - Providing an admin certificate when using the REST management API.
 - Configuring roles and permissions based on a client certificate.
@@ -156,9 +156,9 @@ With TLS client authentication enabled, REST clients can send a TLS certificate
 
 TLS client authentication has three modes:
 
-* `NONE`: The security plugin does not accept TLS client certificates. If one is sent, it is discarded.
+* `NONE`: The Security plugin does not accept TLS client certificates. If one is sent, it is discarded.
-* `OPTIONAL`: The security plugin accepts TLS client certificates if they are sent, but does not require them.
+* `OPTIONAL`: The Security plugin accepts TLS client certificates if they are sent, but does not require them.
-* `REQUIRE`: The security plugin only accepts REST requests when a valid client TLS certificate is sent.
+* `REQUIRE`: The Security plugin only accepts REST requests when a valid client TLS certificate is sent.
 
 For the REST management API, the client authentication modes has to be OPTIONAL at a minimum.
 
@@ -173,7 +173,7 @@ plugins.security.ssl.http.clientauth_mode | The TLS client authentication mode t
 
 You can limit the allowed ciphers and TLS protocols for the REST layer. For example, you can only allow strong ciphers and limit the TLS versions to the most recent ones.
 
-If this setting is not enabled, the ciphers and TLS versions are negotiated between the browser and the security plugin automatically, which in some cases can lead to a weaker cipher suite being used. You can configure the ciphers and protocols using the following settings.
+If this setting is not enabled, the ciphers and TLS versions are negotiated between the browser and the Security plugin automatically, which in some cases can lead to a weaker cipher suite being used. You can configure the ciphers and protocols using the following settings.
 
 Name | Data type | Description
 :--- | :--- | :---
@@ -193,7 +193,7 @@ plugins.security.ssl.http.enabled_protocols:
   - "TLSv1.2"
 ```
 
-Because it is insecure, the security plugin disables `TLSv1` by default. If you need to use `TLSv1` and accept the risks, you can still enable it:
+Because it is insecure, the Security plugin disables `TLSv1` by default. If you need to use `TLSv1` and accept the risks, you can still enable it:
 
 ```yml
 plugins.security.ssl.http.enabled_protocols:

_security/configuration/yaml.md

@@ -18,7 +18,7 @@ The approach we recommend for using the YAML files is to first configure [reserv
 
 ## internal_users.yml
 
-This file contains any initial users that you want to add to the security plugin's internal user database.
+This file contains any initial users that you want to add to the Security plugin's internal user database.
 
 The file format requires a hashed password. To generate one, run `plugins/opensearch-security/tools/hash.sh -p <new-password>`. If you decide to keep any of the demo users, *change their passwords* and re-run [securityadmin.sh]({{site.url}}{{site.baseurl}}/security/configuration/security-admin/) to apply the new passwords.
 
@@ -129,13 +129,13 @@ plugins.security.restapi.password_validation_regex: '(?=.*[A-Z])(?=.*[^a-zA-Z\d]
 plugins.security.restapi.password_validation_error_message: "Password must be minimum 8 characters long and must contain at least one uppercase letter, one lowercase letter, one digit, and one special character."
 ```
 
-The opensearch.yml file also contains the `plugins.security.allow_default_init_securityindex` property. When set to `true`, the security plugin uses default security settings if an attempt to create the security index fails when OpenSearch launches. Default security settings are stored in YAML files contained in the `opensearch-project/security/config` directory. By default, this setting is `false`.
+The opensearch.yml file also contains the `plugins.security.allow_default_init_securityindex` property. When set to `true`, the Security plugin uses default security settings if an attempt to create the security index fails when OpenSearch launches. Default security settings are stored in YAML files contained in the `opensearch-project/security/config` directory. By default, this setting is `false`.
 
 ```yml
 plugins.security.allow_default_init_securityindex: true
 ```
 
-Authentication cache for the security plugin exists to help speed up authentication by temporarily storing user objects returned from the backend so that the security plugin is not required to make repeated requests for them. To determine how long it takes for caching to time out, you can use the `plugins.security.cache.ttl_minutes` property to set a value in minutes. The default is `60`. You can disable caching by setting the value to `0`.
+Authentication cache for the Security plugin exists to help speed up authentication by temporarily storing user objects returned from the backend so that the Security plugin is not required to make repeated requests for them. To determine how long it takes for caching to time out, you can use the `plugins.security.cache.ttl_minutes` property to set a value in minutes. The default is `60`. You can disable caching by setting the value to `0`.
 
 ```yml
 plugins.security.cache.ttl_minutes: 60
@@ -145,7 +145,7 @@ plugins.security.cache.ttl_minutes: 60
 
 You can use `allowlist.yml` to add any endpoints and HTTP requests to a list of allowed endpoints and requests. If enabled, all users except the super admin are allowed access to only the specified endpoints and HTTP requests, and all other HTTP requests associated with the endpoint are denied. For example, if GET `_cluster/settings` is added to the allow list, users cannot submit PUT requests to `_cluster/settings` to update cluster settings.
 
-Note that while you can configure access to endpoints this way, for most cases, it is still best to configure permissions using the security plugin's users and roles, which have more granular settings.
+Note that while you can configure access to endpoints this way, for most cases, it is still best to configure permissions using the Security plugin's users and roles, which have more granular settings.
 
 ```yml
 ---
@@ -195,7 +195,7 @@ requests: # Only allow GET requests to /sample-index1/_doc/1 and /sample-index2/
 
 ## roles.yml
 
-This file contains any initial roles that you want to add to the security plugin. Aside from some metadata, the default file is empty, because the security plugin has a number of static roles that it adds automatically.
+This file contains any initial roles that you want to add to the Security plugin. Aside from some metadata, the default file is empty, because the Security plugin has a number of static roles that it adds automatically.
 
 ```yml
 ---
@@ -308,9 +308,9 @@ kibana_server:
 
 ## action_groups.yml
 
-This file contains any initial action groups that you want to add to the security plugin.
+This file contains any initial action groups that you want to add to the Security plugin.
 
-Aside from some metadata, the default file is empty, because the security plugin has a number of static action groups that it adds automatically. These static action groups cover a wide variety of use cases and are a great way to get started with the plugin.
+Aside from some metadata, the default file is empty, because the Security plugin has a number of static action groups that it adds automatically. These static action groups cover a wide variety of use cases and are a great way to get started with the plugin.
 
 ```yml
 ---

_security/multi-tenancy/multi-tenancy-config.md

@@ -138,14 +138,14 @@ _meta:
 
 ## Manage OpenSearch Dashboards indices
 
-The open source version of OpenSearch Dashboards saves all objects to a single index: `.kibana`. The security plugin uses this index for the global tenant, but separate indices for every other tenant. Each user also has a private tenant, so you might see a large number of indices that follow two patterns:
+The open source version of OpenSearch Dashboards saves all objects to a single index: `.kibana`. The Security plugin uses this index for the global tenant, but separate indices for every other tenant. Each user also has a private tenant, so you might see a large number of indices that follow two patterns:
 
 ```
 .kibana_<hash>_<tenant_name>
 .kibana_<hash>_<username>
 ```
 
-The security plugin scrubs these index names of special characters, so they might not be a perfect match of tenant names and usernames.
+The Security plugin scrubs these index names of special characters, so they might not be a perfect match of tenant names and usernames.
 {: .tip }
 
 To back up your OpenSearch Dashboards data, [take a snapshot]({{site.url}}{{site.baseurl}}/opensearch/snapshots/snapshot-restore/) of all tenant indexes using an index pattern such as `.kibana*`.

_troubleshoot/index.md

@@ -67,7 +67,7 @@ For full documentation about the command, see [cryptsetup(8) — Linux manual pa
 
 If you encounter compatibility issues when attempting to connect Beats to OpenSearch, make sure you're using the Apache 2.0 distribution of Beats, not the default distribution, which uses a proprietary license.
 
-Try this minimal output configuration for using Beats with the security plugin:
+Try this minimal output configuration for using Beats with the Security plugin:
 
 ```yml
 output.elasticsearch:
@@ -91,7 +91,7 @@ setup.ilm.check_exists: false
 
 ## Logstash
 
-If you have trouble connecting Logstash to OpenSearch, try this minimal output configuration, which works with the security plugin:
+If you have trouble connecting Logstash to OpenSearch, try this minimal output configuration, which works with the Security plugin:
 
 ```conf
 output {
@@ -110,7 +110,7 @@ output {
 
 ## Can't update by script when FLS, DLS, or field masking is active
 
-The security plugin blocks the update by script operation (`POST <index>/_update/<id>`) when field-level security, document-level security, or field masking are active. You can still update documents using the standard index operation (`PUT <index>/_doc/<id>`).
+The Security plugin blocks the update by script operation (`POST <index>/_update/<id>`) when field-level security, document-level security, or field masking are active. You can still update documents using the standard index operation (`PUT <index>/_doc/<id>`).
 
 
 ## Illegal reflective access operation in logs

_troubleshoot/openid-connect.md

@@ -6,7 +6,7 @@ nav_order: 30
 
 # OpenID Connect troubleshooting
 
-This page includes troubleshooting steps for using OpenID Connect with the security plugin.
+This page includes troubleshooting steps for using OpenID Connect with the Security plugin.
 
 
 ---
@@ -32,7 +32,7 @@ This setting prints a lot of helpful information to your log file. If this infor
 
 ## "Failed when trying to obtain the endpoints from your IdP"
 
-This error indicates that the security plugin can't reach the metadata endpoint of your IdP. In `opensearch_dashboards.yml`, check the following setting:
+This error indicates that the Security plugin can't reach the metadata endpoint of your IdP. In `opensearch_dashboards.yml`, check the following setting:
 
 ```
 plugins.security.openid.connect_url: "http://keycloak.example.com:8080/auth/realms/master/.well-known/openid-configuration"

_troubleshoot/saml.md

@@ -39,7 +39,7 @@ saml:
 
 After a successful login, your IdP sends a SAML response using HTTP POST to OpenSearch Dashboards's "assertion consumer service URL" (ACS).
 
-The endpoint the OpenSearch Dashboards security plugin provides is:
+The endpoint the OpenSearch Dashboards Security plugin provides is:
 
 ```
 /_opendistro/_security/saml/acs
@@ -102,9 +102,9 @@ Inspect the payload of this POST request, and use a tool like [base64decode.org]
 
 ## Check role mapping
 
-The security plugin uses a standard role mapping to map a user or backend role to one or more Security roles.
+The Security plugin uses a standard role mapping to map a user or backend role to one or more Security roles.
 
-For username, the security plugin uses the `NameID` attribute of the SAML response by default. For some IdPs, this attribute does not contain the expected username, but some internal user ID. Check the content of the SAML response to locate the element you want to use as username, and configure it by setting the `subject_key`:
+For username, the Security plugin uses the `NameID` attribute of the SAML response by default. For some IdPs, this attribute does not contain the expected username, but some internal user ID. Check the content of the SAML response to locate the element you want to use as username, and configure it by setting the `subject_key`:
 
 ```yml
 saml:
@@ -133,6 +133,6 @@ saml:
 
 ## Inspect the JWT token
 
-The security plugin trades the SAML response for a more lightweight JSON web token. The username and backend roles in the JWT are ultimately mapped to roles in the security plugin. If there is a problem with the mapping, you can enable the token debug mode using the same setting as [Inspect the SAML response](#inspect-the-saml-response).
+The Security plugin trades the SAML response for a more lightweight JSON web token. The username and backend roles in the JWT are ultimately mapped to roles in the Security plugin. If there is a problem with the mapping, you can enable the token debug mode using the same setting as [Inspect the SAML response](#inspect-the-saml-response).
 
 This setting prints the JWT to the OpenSearch log file so that you can inspect and debug it using a tool like [JWT.io](https://jwt.io/).

_troubleshoot/security-admin.md

@@ -80,7 +80,7 @@ If your cluster state is red, you can still execute `securityadmin.sh`, but you
 
 ### Check the security index name
 
-By default, the security plugin uses `.opendistro_security` as the name of the configuration index. If you configured a different index name in `opensearch.yml`, specify it using the `-i` option.
+By default, the Security plugin uses `.opendistro_security` as the name of the configuration index. If you configured a different index name in `opensearch.yml`, specify it using the `-i` option.
 
 
 ## "ERR: DN is not an admin user"

_troubleshoot/tls.md

@@ -6,7 +6,7 @@ nav_order: 15
 
 # TLS troubleshooting
 
-This page includes troubleshooting steps for configuring TLS certificates with the security plugin.
+This page includes troubleshooting steps for configuring TLS certificates with the Security plugin.
 
 
 ---
@@ -43,7 +43,7 @@ openssl x509 -in node1.pem -text -noout
 
 ### Check for special characters and whitespace in DNs
 
-The security plugin uses the [string representation of Distinguished Names (RFC1779)](https://www.ietf.org/rfc/rfc1779.txt) when validating node certificates.
+The Security plugin uses the [string representation of Distinguished Names (RFC1779)](https://www.ietf.org/rfc/rfc1779.txt) when validating node certificates.
 
 If parts of your DN contain special characters (e.g. a comma), make sure you escape it in your configuration:
 
@@ -96,7 +96,7 @@ In this example, the node tries to join the cluster with the IPv4 address of `10
 
 ### Validate certificate chain
 
-TLS certificates are organized in a certificate chain. You can check with `keytool` that the certificate chain is correct by inspecting the owner and the issuer of each certificate. If you used the demo installation script that ships with the security plugin, the chain looks like:
+TLS certificates are organized in a certificate chain. You can check with `keytool` that the certificate chain is correct by inspecting the owner and the issuer of each certificate. If you used the demo installation script that ships with the Security plugin, the chain looks like:
 
 #### Node certificate
 
@@ -193,7 +193,7 @@ ExtendedKeyUsages [
 
 ## TLS versions
 
-The security plugin disables TLS version 1.0 by default; it is outdated, insecure, and vulnerable. If you need to use `TLSv1` and accept the risks, you can enable it in `opensearch.yml`:
+The Security plugin disables TLS version 1.0 by default; it is outdated, insecure, and vulnerable. If you need to use `TLSv1` and accept the risks, you can enable it in `opensearch.yml`:
 
 ```yml
 plugins.security.ssl.http.enabled_protocols:
@@ -215,7 +215,7 @@ That is not an issue, it just limits possible encryption strength.
 To enable AES 256 install 'Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files'
 ```
 
-The security plugin still works and falls back to weaker cipher suites. The plugin also prints out all available cipher suites during startup:
+The Security plugin still works and falls back to weaker cipher suites. The plugin also prints out all available cipher suites during startup:
 
 ```
 [INFO ] sslTransportClientProvider:

_tuning-your-cluster/availability-and-recovery/remote.md

@@ -216,7 +216,7 @@ curl -X POST "https://localhost:9200/_remotestore/_restore" -ku admin:admin -H '
 '
 ```
 
-If the security plugin is enabled, a user must have the `cluster:admin/remotestore/restore` permission. See [Access control](/security-plugin/access-control/index/) for information about configuring user permissions.
+If the Security plugin is enabled, a user must have the `cluster:admin/remotestore/restore` permission. See [Access control](/security-plugin/access-control/index/) for information about configuring user permissions.
 {: .note}
 
 ## Potential use cases

_tuning-your-cluster/availability-and-recovery/snapshots/snapshot-restore.md

@@ -357,7 +357,7 @@ Snapshots are only forward-compatible by one major version. If you have an old s
 
 ## Security considerations
 
-If you're using the security plugin, snapshots have some additional restrictions:
+If you're using the Security plugin, snapshots have some additional restrictions:
 
 - To perform snapshot and restore operations, users must have the built-in `manage_snapshots` role.
 - You can't restore snapshots that contain global state or the `.opendistro_security` index.
@@ -380,5 +380,5 @@ curl -k --cert ./kirk.pem --key ./kirk-key.pem -XPOST 'https://localhost:9200/_s
 ```
 {% include copy-curl.html %}
 
-We strongly recommend against restoring `.opendistro_security` using an admin certificate because doing so can alter the security posture of the entire cluster. See [A word of caution]({{site.url}}{{site.baseurl}}/security-plugin/configuration/security-admin/#a-word-of-caution) for a recommended process to back up and restore your security plugin configuration.
+We strongly recommend against restoring `.opendistro_security` using an admin certificate because doing so can alter the security posture of the entire cluster. See [A word of caution]({{site.url}}{{site.baseurl}}/security-plugin/configuration/security-admin/#a-word-of-caution) for a recommended process to back up and restore your Security plugin configuration.
 {: .warning}

_tuning-your-cluster/cluster.md

@@ -343,4 +343,4 @@ You can then use the [Index State Management (ISM)]({{site.url}}{{site.baseurl}}
 
 ## Next steps
 
-If you are using the security plugin, the previous request to `_cat/nodes?v` might have failed with an initialization error. For full guidance around using the security plugin, see [Security configuration]({{site.url}}{{site.baseurl}}/security/configuration/index/).
+If you are using the Security plugin, the previous request to `_cat/nodes?v` might have failed with an initialization error. For full guidance around using the Security plugin, see [Security configuration]({{site.url}}{{site.baseurl}}/security/configuration/index/).

_tuning-your-cluster/replication-plugin/api.md

@@ -42,7 +42,7 @@ Options | Description | Type | Required
 :--- | :--- |:--- |:--- |
 `leader_alias` |  The name of the cross-cluster connection. You define this alias when you [set up a cross-cluster connection]({{site.url}}{{site.baseurl}}/replication-plugin/get-started/#set-up-a-cross-cluster-connection). | `string` | Yes
 `leader_index` |  The index on the leader cluster that you want to replicate. | `string` | Yes
-`use_roles` |  The roles to use for all subsequent backend replication tasks between the indexes. Specify a `leader_cluster_role` and `follower_cluster_role`. See [Map the leader and follower cluster roles]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles). | `string` | If security plugin is enabled
+`use_roles` |  The roles to use for all subsequent backend replication tasks between the indexes. Specify a `leader_cluster_role` and `follower_cluster_role`. See [Map the leader and follower cluster roles]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles). | `string` | If Security plugin is enabled
 
 #### Example response
 
@@ -350,7 +350,7 @@ Options | Description | Type | Required
 `leader_alias` |  The name of the cross-cluster connection. You define this alias when you [set up a cross-cluster connection]({{site.url}}{{site.baseurl}}/replication-plugin/get-started/#set-up-a-cross-cluster-connection). | `string` | Yes
 `name` |  A name for the auto-follow pattern. | `string` | Yes
 `pattern` |  An array of index patterns to match against indexes in the specified leader cluster. Supports wildcard characters. For example, `leader-*`. | `string` | Yes
-`use_roles` |  The roles to use for all subsequent backend replication tasks between the indexes. Specify a `leader_cluster_role` and `follower_cluster_role`. See [Map the leader and follower cluster roles]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles). | `string` | If security plugin is enabled
+`use_roles` |  The roles to use for all subsequent backend replication tasks between the indexes. Specify a `leader_cluster_role` and `follower_cluster_role`. See [Map the leader and follower cluster roles]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles). | `string` | If Security plugin is enabled
 
 #### Example response
 

_tuning-your-cluster/replication-plugin/auto-follow.md

@@ -19,7 +19,7 @@ You need to [set up a cross-cluster connection]({{site.url}}{{site.baseurl}}/rep
 
 ## Permissions
 
-If the security plugin is enabled, make sure that non-admin users are mapped to the appropriate permissions so they can perform replication actions. For index and cluster-level permissions requirements, see [Cross-cluster replication permissions]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/).
+If the Security plugin is enabled, make sure that non-admin users are mapped to the appropriate permissions so they can perform replication actions. For index and cluster-level permissions requirements, see [Cross-cluster replication permissions]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/).
 
 ## Get started with auto-follow
 
@@ -40,7 +40,7 @@ curl -XPOST -k -H 'Content-Type: application/json' -u 'admin:admin' 'https://loc
 }'
 ```
 
-If the security plugin is disabled, you can leave out the `use_roles` parameter. If it's enabled, however, you need to specify the leader and follower cluster roles that OpenSearch uses to authenticate requests. This example uses `all_access` for simplicity, but we recommend creating a replication user on each cluster and [mapping it accordingly]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles).
+If the Security plugin is disabled, you can leave out the `use_roles` parameter. If it's enabled, however, you need to specify the leader and follower cluster roles that OpenSearch uses to authenticate requests. This example uses `all_access` for simplicity, but we recommend creating a replication user on each cluster and [mapping it accordingly]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles).
 {: .tip }
 
 To test the rule, create a matching index on the leader cluster:

_tuning-your-cluster/replication-plugin/getting-started.md

@@ -23,9 +23,9 @@ Cross-cluster replication has the following prerequisites:
 
 ## Permissions
 
-Make sure the security plugin is either enabled on both clusters or disabled on both clusters. If you disabled the security plugin, you can skip this section. However, we strongly recommend enabling the security plugin in production scenarios.
+Make sure the Security plugin is either enabled on both clusters or disabled on both clusters. If you disabled the Security plugin, you can skip this section. However, we strongly recommend enabling the Security plugin in production scenarios.
 
-If the security plugin is enabled, make sure that non-admin users are mapped to the appropriate permissions so they can perform replication actions. For index and cluster-level permissions requirements, see [Cross-cluster replication permissions]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/).
+If the Security plugin is enabled, make sure that non-admin users are mapped to the appropriate permissions so they can perform replication actions. For index and cluster-level permissions requirements, see [Cross-cluster replication permissions]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/).
 
 In addition, verify and add the distinguished names (DNs) of each follower cluster node on the leader cluster to allow connections from the followers to the leader.
 
@@ -184,7 +184,7 @@ curl -XPUT -k -H 'Content-Type: application/json' -u 'admin:admin' 'https://loca
 }'
 ```
 
-If the security plugin is disabled, omit the `use_roles` parameter. If it's enabled, however, you must specify the leader and follower cluster roles that OpenSearch will use to authenticate the request. This example uses `all_access` for simplicity, but we recommend creating a replication user on each cluster and [mapping it accordingly]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles).
+If the Security plugin is disabled, omit the `use_roles` parameter. If it's enabled, however, you must specify the leader and follower cluster roles that OpenSearch will use to authenticate the request. This example uses `all_access` for simplicity, but we recommend creating a replication user on each cluster and [mapping it accordingly]({{site.url}}{{site.baseurl}}/replication-plugin/permissions/#map-the-leader-and-follower-cluster-roles).
 {: .tip }
 
 This command creates an identical read-only index named `follower-01` on the follower cluster that continuously stays updated with changes to the `leader-01` index on the leader cluster. Starting replication creates a follower index from scratch -- you can't convert an existing index to a follower index. 

_tuning-your-cluster/replication-plugin/index.md

@@ -19,6 +19,6 @@ Replication follows an active-passive model where the follower index (where the
 
 The replication plugin supports replication of indexes using wildcard pattern matching and provides commands to pause, resume, and stop replication. Once replication starts on an index, it initiates persistent background tasks on all primary shards on the follower cluster, which continuously poll corresponding shards from the leader cluster for updates.
 
-You can use the replication plugin with the security plugin to encrypt cross-cluster traffic with node-to-node encryption and control access to replication activities.
+You can use the replication plugin with the Security plugin to encrypt cross-cluster traffic with node-to-node encryption and control access to replication activities.
 
 To start, see [Get started with cross-cluster replication]({{site.url}}{{site.baseurl}}/replication-plugin/get-started/).

_tuning-your-cluster/replication-plugin/permissions.md

@@ -9,7 +9,7 @@ redirect_from:
 
 # Cross-cluster replication security
 
-You can use the [security plugin]({{site.url}}{{site.baseurl}}/security/index/) with cross-cluster replication to limit users to certain actions. For example, you might want certain users to only perform replication activity on the leader or follower cluster.
+You can use the [Security plugin]({{site.url}}{{site.baseurl}}/security/index/) with cross-cluster replication to limit users to certain actions. For example, you might want certain users to only perform replication activity on the leader or follower cluster.
 
 Because cross-cluster replication involves multiple clusters, it's possible that clusters might have different security configurations. The following configurations are supported:
 
@@ -23,7 +23,7 @@ Enable node-to-node encryption on both the leader and the follower cluster to en
 
 In order for non-admin users to perform replication activities, they must be mapped to the appropriate permissions.  
 
-The security plugin has two built-in roles that cover most replication use cases: `cross_cluster_replication_leader_full_access`, which provides replication permissions on the leader cluster, and `cross_cluster_replication_follower_full_access`, which provides replication permissions on the follower cluster. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
+The Security plugin has two built-in roles that cover most replication use cases: `cross_cluster_replication_leader_full_access`, which provides replication permissions on the leader cluster, and `cross_cluster_replication_follower_full_access`, which provides replication permissions on the follower cluster. For descriptions of each, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
 
 If you don't want to use the default roles, you can combine individual replication [permissions]({{site.url}}{{site.baseurl}}/tuning-your-cluster/replication-plugin/permissions/#replication-permissions) to meet your needs. Most permissions correspond to specific REST API operations. For example, the `indices:admin/plugins/replication/index/pause` permission lets you pause replication.
 
@@ -56,7 +56,7 @@ The following sections list the available index and cluster-level permissions fo
 
 ### Follower cluster
 
-The security plugin supports these permissions for the follower cluster:
+The Security plugin supports these permissions for the follower cluster:
 
 ```
 indices:admin/plugins/replication/index/setup/validate
@@ -72,7 +72,7 @@ cluster:admin/plugins/replication/autofollow/update
 
 ### Leader cluster
 
-The security plugin supports these permissions for the leader cluster:
+The Security plugin supports these permissions for the leader cluster:
 
 ```
 indices:admin/plugins/replication/validate

_upgrade-to/dashboards-upgrade-to.md

@@ -23,9 +23,9 @@ Consider exporting all Kibana objects prior to starting the migration. In Kibana
 
    For a full list of OpenSearch Dashboards settings, see [opensearch_dashboards.yml](https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/config/opensearch_dashboards.yml){:target='\_blank'}.
 
-1. If your OpenSearch cluster uses the security plugin, preserve and modify the default settings in `opensearch_dashboards.yml`, particularly `opensearch.username` and `opensearch.password`.
+1. If your OpenSearch cluster uses the Security plugin, preserve and modify the default settings in `opensearch_dashboards.yml`, particularly `opensearch.username` and `opensearch.password`.
 
-   If you disabled the security plugin on your OpenSearch cluster, remove or comment out all `opensearch_security` settings. Then run `rm -rf plugins/security-dashboards/` to remove the security plugin.
+   If you disabled the Security plugin on your OpenSearch cluster, remove or comment out all `opensearch_security` settings. Then run `rm -rf plugins/security-dashboards/` to remove the Security plugin.
 
 1. Start OpenSearch Dashboards:
 

_upgrade-to/upgrade-to.md

@@ -79,7 +79,7 @@ If you are migrating an Open Distro for Elasticsearch cluster, we recommend firs
    ```bash
    # Elasticsearch OSS
    curl -XGET 'localhost:9200/_nodes/_all?pretty=true'
-   # Open Distro for Elasticsearch with security plugin enabled
+   # Open Distro for Elasticsearch with Security plugin enabled
    curl -XGET 'https://localhost:9200/_nodes/_all?pretty=true' -u 'admin:admin' -k
    ```
 
@@ -134,7 +134,7 @@ If you are migrating an Open Distro for Elasticsearch cluster, we recommend firs
 
    1. Set the `OPENSEARCH_PATH_CONF` environment variable to the directory that contains `opensearch.yml` (for example, `/etc/opensearch`).
 
-   1. In `opensearch.yml`, set `path.data` and `path.logs`. You might also want to disable the security plugin for now. `opensearch.yml` might look something like this:
+   1. In `opensearch.yml`, set `path.data` and `path.logs`. You might also want to disable the Security plugin for now. `opensearch.yml` might look something like this:
 
       ```yml
       path.data: /var/lib/opensearch
@@ -150,7 +150,7 @@ If you are migrating an Open Distro for Elasticsearch cluster, we recommend firs
       compatibility.override_main_response_version: true
       ```
 
-   1. (Optional) Add your certificates to your `config` directory, add them to `opensearch.yml`, and initialize the security plugin.
+   1. (Optional) Add your certificates to your `config` directory, add them to `opensearch.yml`, and initialize the Security plugin.
 
 1. Start OpenSearch on the node (rolling) or all nodes (cluster restart).
 

index.md

@@ -58,7 +58,7 @@ OpenSearch has several features and plugins to help index, secure, monitor, and
 
 
 ## The secure path forward
-OpenSearch includes a demo configuration so that you can get up and running quickly, but before using OpenSearch in a production environment, you must [configure the security plugin manually]({{site.url}}{{site.baseurl}}/security/configuration/index/) with your own certificates, authentication method, users, and passwords.
+OpenSearch includes a demo configuration so that you can get up and running quickly, but before using OpenSearch in a production environment, you must [configure the Security plugin manually]({{site.url}}{{site.baseurl}}/security/configuration/index/) with your own certificates, authentication method, users, and passwords.
 
 ## Looking for the Javadoc?
 

quickstart.md

@@ -129,7 +129,7 @@ Create an index and define field mappings using a dataset provided by the OpenSe
 ## Next steps
 
 You successfully deployed your own OpenSearch cluster with OpenSearch Dashboards and added some sample data. Now you're ready to learn about configuration and functionality in more detail. Here are a few recommendations on where to begin:
-- [About the security plugin]({{site.url}}{{site.baseurl}}/security/index/)
+- [About the Security plugin]({{site.url}}{{site.baseurl}}/security/index/)
 - [OpenSearch configuration]({{site.url}}{{site.baseurl}}/install-and-configure/configuration/)
 - [OpenSearch plugin installation]({{site.url}}{{site.baseurl}}/opensearch/install/plugins/)
 - [Getting started with OpenSearch Dashboards]({{site.url}}{{site.baseurl}}/dashboards/index/)