Adds documentation for permission that provides access to system indexes

_security/access-control/permissions.md

@@ -65,6 +65,47 @@ Rather than individual permissions, you can often achieve your desired security
 {: .tip }
 
 
+## System index permissions
+
+System index permissions are unique among other permissions in that they extend some traditional admin-only accessibility to non-admin users. These permissions give normal users the ability to modify any system index specified in the role or roles to which they are mapped. The exception to this is the security system index, `.opendistro_security`, which is used to store Security's configuration YAML files and remains accessible only to admins with an admin certificate.
+
+Along with standard index permissions, you specify system index permissions in the 'roles.yml' configuration file under 'index_permissions' (See [roles.yml]({{site.url}}{{site.baseurl}}/security/configuration/yaml/#rolesyml). You do this by specifying `system:admin/system_index` in the role's `allowed_actions` section and adding the system index in the `index_patterns` section.
+
+For example, the system index permission that gives a user permission to modify the system index that stores configurations for the Alerting plugin is defined by the index pattern `.opendistro-alerting-config` and its allowed action is defined as `system:admin/system_index`. The following role shows how this system index permission is configured along with other attributes:
+
+```yml
+alerting-role:
+  reserved: true
+  hidden: false
+  cluster_permissions:
+  - "cluster:admin/opendistro/alerting/alerts/ack"
+  - "cluster:admin/opendistro/alerting/alerts/get"
+  index_permissions:
+  - index_patterns:
+    - ".opendistro-alerting-config"
+  - allowed_actions:
+    - "system:admin/system_index"
+```
+
+The permission prefix `.opendistro` also works with the wildcard to extend its reach of access. This can be useful, but it should be used with caution to avoid giving unintentional access to system indexes. When specifying system indexes for roles, keep the following considerations in mind:
+
+* Specifying the full name of a system index limits access to that index alone: `.opendistro-alerting-config`.
+* Specifying the prefix and a partial name for a system index provides access to all system indexes that begin with the name: `.opendistro-anomaly-detector*`.
+* Using `.*` is effectively the same as specifying the prefix with wildcard, as described in the previous point. This gives access to all system indexes that begin with a `.`.
+* Entering the wildcard `*` by itself does not give access to any indexes.
+
+Use extreme caution when using the wildcard to configure access to system indexes. We highly recommend thinking ahead and anticipating the range of access that you will be extending to users before updating your configuration files.
+{: .warning }
+
+
+### Enabling system index permissions
+
+Users that have the permission [`restapi:admin/roles`]({{site.url}}{{site.baseurl}}/security/access-control/api/#access-control-for-the-api) are able to map system index permissions to all users in the same way they would for a cluster or index permission in the `roles.yml` file. However, to preserve some control over this permission, the system index permission feature is disabled by default and allows administrators to enable this feature by setting the configuration `plugins.security.system_indices.additional_control.enabled` to `true`. For more information about this setting, see [Enabling user access to system indexes]({{site.url}}{{site.baseurl}}/security/configuration/yaml/#enabling-user-access-to-system-indexes).
+
+Keep in mind that an admin user who enables this feature necessarily accepts the risks involved with giving normal users access to system indexes, which may contain sensitive information and configurations essential to a cluster's health. An admin user should also take precautions when assigning `restapi:admin/roles` to users because this permission gives a user not only the ability to assign the system index permission to another user but, equally, the ability to self-assign access to any system index.
+{: .warning }
+
+
 ## Cluster permissions
 
 These permissions are for the cluster and can't be applied granularly. For example, you either have permissions to take snapshots (`cluster:admin/snapshot/create`) or you don't. The cluster permission, therefore, cannot grant a user privileges to take snapshots of a select set of indexes while preventing the user from taking snapshots of others.

_security/configuration/yaml.md

@@ -134,6 +134,20 @@ An authentication cache for the Security plugin exists to help speed up authenti
 plugins.security.cache.ttl_minutes: 60
 ```
 
+### Enabling user access to system indexes
+
+Mapping a system permission to a user allows that user to modify the system index specified in the permission's name. (The one exception is the Security plugin's [system index]({{site.url}}{{site.baseurl}}/security/configuration/system-indices/)). The `plugins.security.system_indices.additional_control.enabled` setting provides a way for administrators to make this permission available for or hidden from role mapping.
+
+When set to `true`, the feature is enabled and users with access to modify roles can add an index pattern and the allowed action `system:admin/system_index` to a role.
+
+```yml
+plugins.security.system_indices.additional_control.enabled: true
+```
+When set to `false`, the permission is disabled and only admins with an admin certificate can make changes to system indexes. By default, the setting is `false` for a new cluster.
+
+To learn more about system index permissions, see [System index permissions]({{site.url}}{{site.baseurl}}/security/access-control/permissions/#system-index-permissions) in Permissions documentation.
+
+
 ### Password settings
 
 If you want to run your users' passwords against some validation, specify a regular expression (regex) in this file. You can also include an error message that loads when passwords don't pass validation. The following example demonstrates how to include a regex so OpenSearch requires new passwords to be a minimum of eight characters with at least one uppercase, one lowercase, one digit, and one special character.