more redirect changes 5 (#4028)

Signed-off-by: Heather Halter <hdhalter@amazon.com>

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

@@ -5,6 +5,7 @@ parent: Installing OpenSearch
 nav_order: 5
 redirect_from: 
   - /opensearch/install/docker/
+  - /install-and-configure/install-opensearch/docker/
 ---
 
 # Docker

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

@@ -8,6 +8,7 @@ redirect_from:
   - /opensearch/install/compatibility/
   - /opensearch/install/important-settings/
   - /install-and-configure/index/
+  - /opensearch/install/index/
 ---
 
 # Installing OpenSearch

_search-plugins/async/security.md

@@ -4,13 +4,15 @@ title: Asynchronous search security
 nav_order: 2
 parent: Asynchronous search
 has_children: false
+redirect_from:
+ - /search-plugins/async/security/
 ---
 
 # 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.
 
-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/).
+All asynchronous search indexes are protected as system indexes. Only a super admin user or an admin user with a Transport Layer Security (TLS) certificate can access system indexes. For more information, see [System indexes]({{site.url}}{{site.baseurl}}/security/configuration/system-indices/).
 
 ## Basic permissions
 

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

@@ -3,6 +3,8 @@ layout: default
 title: Cross-cluster search
 parent: Access control
 nav_order: 105
+redirect_from:
+ - /security/access-control/cross-cluster-search/
 ---
 
 # Cross-cluster search

_security/access-control/default-action-groups.md

@@ -3,6 +3,8 @@ layout: default
 title: Default action groups
 parent: Access control
 nav_order: 115
+redirect_from:
+ - /security/access-control/default-action-groups/
 ---
 
 # Default action groups

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

@@ -3,11 +3,13 @@ layout: default
 title: Document-level security
 parent: Access control
 nav_order: 85
+redirect_from:
+ - /security/access-control/document-level-security/
 ---
 
 # Document-level security (DLS)
 
-Document-level security lets you restrict a role to a subset of documents in an index. The easiest way to get started with document- and field-level security is open OpenSearch Dashboards and choose **Security**. Then choose **Roles**, create a new role, and review the **Index permissions** section.
+Document-level security lets you restrict a role to a subset of documents in an index. The easiest way to get started with document- and field-level security is to open OpenSearch Dashboards and choose **Security**. Then choose **Roles**, create a new role, and review the **Index permissions** section.
 
 ![Document- and field-level security screen in OpenSearch Dashboards]({{site.url}}{{site.baseurl}}/images/security-dls.png)
 

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

@@ -3,6 +3,8 @@ layout: default
 title: Field-level security
 parent: Access control
 nav_order: 90
+redirect_from:
+ - /security/access-control/field-level-security/
 ---
 
 # Field-level security

_security/access-control/field-masking.md

@@ -3,6 +3,8 @@ layout: default
 title: Field masking
 parent: Access control
 nav_order: 95
+redirect_from:
+ - /security/access-control/field-masking/
 ---
 
 # Field masking

_security/access-control/impersonation.md

@@ -3,6 +3,8 @@ layout: default
 title: User impersonation
 parent: Access control
 nav_order: 100
+redirect_from:
+ - /security/access-control/impersonation/
 ---
 
 # User impersonation

_security/access-control/index.md

@@ -21,9 +21,9 @@ Term | Description
 :--- | :---
 Permission | An individual action, such as creating an index (e.g. `indices:admin/create`). For a complete list, see [Permissions]({{site.url}}{{site.baseurl}}/security/access-control/permissions/).
 Action group | A set of permissions. For example, the predefined `SEARCH` action group authorizes roles to use the `_search` and `_msearch` APIs.
-Role | Security roles define the scope of a permission or action group: cluster, index, document, or field. For example, a role named `delivery_analyst` might have no cluster permissions, the `READ` action group for all indices that match the `delivery-data-*` pattern, access to all document types within those indices, and access to all fields except `delivery_driver_name`.
-Backend role | (Optional) Arbitrary strings that you specify *or* that come from an external authentication system (e.g. LDAP/Active Directory). Backend roles can help simplify the role mapping process. Rather than mapping a role to 100 individual users, you can map the role to a single backend role that all 100 users share.
+Role | Security roles define the scope of a permission or action group: cluster, index, document, or field. For example, a role named `delivery_analyst` might have no cluster permissions, the `READ` action group for all indexes that match the `delivery-data-*` pattern, access to all document types within those indexes, and access to all fields except `delivery_driver_name`.
+Backend role | (Optional) Arbitrary strings that you specify *or* that come from an external authentication system (for example, LDAP/Active Directory). Backend roles can help simplify the role mapping process. Rather than mapping a role to 100 individual users, you can map the role to a single backend role that all 100 users share.
 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.
+Role mapping | Users assume roles after they successfully authenticate. Role mappings 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 multiple 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.

_security/access-control/permissions.md

@@ -13,7 +13,7 @@ Each permission in the Security plugin controls access to some action that the O
 
 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.
+Despite this correlation, permissions do **not** directly map to REST API operations. Operations such as `POST _bulk` and `GET _msearch` can access many indexes 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.
 
@@ -313,7 +313,7 @@ See [Index templates]({{site.url}}{{site.baseurl}}/im-plugin/index-templates/).
 
 ## Index permissions
 
-These permissions apply to an index or index pattern. You might want a user to have read access to all indices (i.e. `*`), but write access to only a few (e.g. `web-logs` and `product-catalog`).
+These permissions apply to an index or index pattern. You might want a user to have read access to all indexes (that is, `*`), but write access to only a few (for example, `web-logs` and `product-catalog`).
 
 - indices:admin/aliases
 - indices:admin/aliases/exists
@@ -322,11 +322,11 @@ These permissions apply to an index or index pattern. You might want a user to h
 - indices:admin/cache/clear
 - indices:admin/close
 - indices:admin/close*
-- indices:admin/create (create indices)
+- indices:admin/create (create indexes)
 - indices:admin/data_stream/create
 - indices:admin/data_stream/delete
 - indices:admin/data_stream/get
-- indices:admin/delete (delete indices)
+- indices:admin/delete (delete indexes)
 - indices:admin/exists
 - indices:admin/flush
 - indices:admin/flush*
@@ -382,7 +382,7 @@ These permissions apply to an index or index pattern. You might want a user to h
 - indices:data/write/delete (delete documents)
 - indices:data/write/delete/byquery
 - indices:data/write/plugins/replication/changes
-- indices:data/write/index (add documents to existing indices)
+- indices:data/write/index (add documents to existing indexes)
 - indices:data/write/reindex
 - indices:data/write/update
 - indices:data/write/update/byquery

_security/access-control/users-roles.md

@@ -3,6 +3,8 @@ layout: default
 title: Users and roles
 parent: Access control
 nav_order: 80
+redirect_from:
+ - /security/access-control/users-roles/
 ---
 
 # Users and roles
@@ -58,7 +60,7 @@ Just like users, you can create roles using OpenSearch Dashboards, `roles.yml`,
 1. Provide a name for the role.
 1. Add permissions as desired.
 
-   For example, you might give a role no cluster permissions, `read` permissions to two indices, `unlimited` permissions to a third index, and read permissions to the `analysts` tenant.
+   For example, you might give a role no cluster permissions, `read` permissions to two indexes, `unlimited` permissions to a third index, and read permissions to the `analysts` tenant.
 
 1. Choose **Submit**.
 
@@ -130,7 +132,7 @@ The Security plugin includes several predefined roles that serve as useful defau
 | `snapshot_management_read_access` | Grants permissions to view policies but not to create, modify, start, stop, or delete them. |
 | `point_in_time_full_access` | Grants full permissions to all Point in Time operations. |
 | `security_analytics_full_access` | Grants full permissions to all Security Analytics functionality. |
-| `security_analytics_read_access` | Grants permissions to view the various components in Security Analytics, such as detectors, alerts, and findings. It also includes permissions that allow users to search for detectors and rules. This role does not allow a user to perform actions such as modfying or deleting a detector. |
+| `security_analytics_read_access` | Grants permissions to view the various components in Security Analytics, such as detectors, alerts, and findings. It also includes permissions that allow users to search for detectors and rules. This role does not allow a user to perform actions such as modifying or deleting a detector. |
 | `security_analytics_ack_alerts` | Grants permissions to view and acknowledge alerts. |
 
 For more detailed summaries of the permissions for each role, reference their action groups against the descriptions in [Default action groups]({{site.url}}{{site.baseurl}}/security/access-control/default-action-groups/).

_security/authentication-backends/authc-index.md

@@ -6,6 +6,7 @@ has_children: true
 has_toc: false
 redirect_from:
   - /security/authentication-backends/
+  - /security-plugin/configuration/concepts/
 ---
 
 # Authentication backends

_security/authentication-backends/proxy.md

@@ -3,6 +3,8 @@ layout: default
 title: Proxy-based authentication
 parent: Authentication backends
 nav_order: 65
+redirect_from:
+ - /security-plugin/configuration/proxy/
 ---
 
 # Proxy-based authentication

_tools/logstash/index.md

@@ -6,6 +6,7 @@ has_children: true
 has_toc: true
 redirect_from:
   - /clients/logstash/
+  - /clients/logstash/index/
 ---
 
 # Logstash