deploy and manage > users and roles > cluster/deployment > roles

deploy-manage/_snippets/field-doc-sec-limitations.md

@@ -0,0 +1,44 @@
+Field and document security is subject to the following limitations: 
+
+### Document level security limitations
+
+When a user’s role enables [document level security](/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md) for a data stream or index:
+
+* Document level security doesn’t affect global index statistics that relevancy scoring uses. This means that scores are computed without taking the role query into account. Documents that don’t match the role query are never returned.
+* The `has_child` and `has_parent` queries aren’t supported as query parameters in the role definition. The `has_child` and `has_parent` queries can be used in the search API with document level security enabled.
+* [Date math](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/rest-apis/common-options.md#date-math) expressions cannot contain `now` in [range queries with date fields](asciidocalypse://docs/elasticsearch/docs/reference/query-languages/query-dsl-range-query.md#ranges-on-dates).
+* Any query that makes remote calls to fetch query data isn’t supported, including the following queries:
+
+    * `terms` query with terms lookup
+    * `geo_shape` query with indexed shapes
+    * `percolate` query
+
+* If suggesters are specified and document level security is enabled, the specified suggesters are ignored.
+* A search request cannot be profiled if document level security is enabled.
+* The [terms enum API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-terms-enum) does not return terms if document level security is enabled.
+* The [`multi_match`](asciidocalypse://docs/elasticsearch/docs/reference/query-languages/query-dsl-multi-match-query.md) query does not support specifying fields using wildcards.
+
+:::{note} 
+While document-level security prevents users from viewing restricted documents, it’s still possible to write search requests that return aggregate information about the entire index. A user whose access is restricted to specific documents in an index could still learn about field names and terms that only exist in inaccessible documents, and count how many inaccessible documents contain a given term.
+:::
+
+### Field level security limitations
+
+When a user’s role enables document or [field level security](/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md) for a data stream or index:
+
+* The user cannot perform write operations:
+
+    * The update API isn’t supported.
+    * Update requests included in bulk requests aren’t supported.
+
+* The user cannot perform operations that effectively make contents accessible under another name, including actions from the following APIs:
+
+    * [Clone index API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-clone)
+    * [Shrink index API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-shrink)
+    * [Split index API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-split)
+    * [Aliases API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-update-aliases)
+
+* The request cache is disabled for search requests if either of the following are true:
+
+    * The role query that defines document level security is [templated](/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md#templating-role-query) using a [stored script](/explore-analyze/scripting/modules-scripting-using.md#script-stored-scripts).
+    * The target indices are a mix of local and remote indices.

deploy-manage/api-keys/serverless-project-api-keys.md

@@ -70,7 +70,7 @@ For example, the following `role_descriptors` object defines a `books-read-only`
 }
 ```
 
-For the `role_descriptors` object schema, check out the [`/_security/api_key` endpoint](https://www.elastic.co/docs/api/doc/elasticsearch-serverless/operation/operation-security-create-api-key) docs. For supported privileges, check [Security privileges](../users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md#privileges-list-indices).
+For the `role_descriptors` object schema, check out the [`/_security/api_key` endpoint](https://www.elastic.co/docs/api/doc/elasticsearch-serverless/operation/operation-security-create-api-key) docs. For supported privileges, check [Security privileges](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/security-privileges.md#privileges-list-indices).
 
 
 ## Update an API key [api-keys-update-an-api-key]

deploy-manage/security/secure-endpoints.md

@@ -27,5 +27,5 @@ While you absolutely shouldn’t expose {{es}} directly to the internet, you als
 
 ## Implement role based access control [security-create-appropriate-users] 
 
-[Define roles](../users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](../users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request.
+[Define roles](../users-roles/cluster-or-deployment-auth/defining-roles.md) for your users and [assign appropriate privileges](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/security-privileges.md) to ensure that users have access only to the resources that they need. This process determines whether the user behind an incoming request is allowed to run that request.
 

deploy-manage/toc.yml

@@ -594,7 +594,7 @@ toc:
               - file: users-roles/cloud-enterprise-orchestrator/ldap.md
               - file: users-roles/cloud-enterprise-orchestrator/saml.md
           - file: users-roles/cloud-enterprise-orchestrator/configure-sso-for-deployments.md
-      - file: users-roles/custom-roles.md
+      - file: users-roles/serverless-custom-roles.md
       - file: users-roles/cluster-or-deployment-auth.md
         children:
           - file: users-roles/cluster-or-deployment-auth/quickstart.md
@@ -646,14 +646,17 @@ toc:
               - file: users-roles/cluster-or-deployment-auth/manage-authentication-for-multiple-clusters.md
           - file: users-roles/cluster-or-deployment-auth/user-roles.md
             children:
+              - file: users-roles/cluster-or-deployment-auth/built-in-roles.md
               - file: users-roles/cluster-or-deployment-auth/defining-roles.md
                 children:
                   - file: users-roles/cluster-or-deployment-auth/granting-privileges-for-data-streams-aliases.md
+                  - file: users-roles/cluster-or-deployment-auth/kibana-role-management.md
                   - file: users-roles/cluster-or-deployment-auth/role-restriction.md
-              - file: users-roles/cluster-or-deployment-auth/built-in-roles.md
-              - file: users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md
+              - file: users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md                  
               - file: users-roles/cluster-or-deployment-auth/kibana-privileges.md
               - file: users-roles/cluster-or-deployment-auth/mapping-users-groups-to-roles.md
+                children:
+                  - file: users-roles/cluster-or-deployment-auth/role-mapping-resources.md
               - file: users-roles/cluster-or-deployment-auth/authorization-delegation.md
               - file: users-roles/cluster-or-deployment-auth/authorization-plugins.md
               - file: users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md

deploy-manage/tools/snapshot-and-restore/create-snapshots.md

@@ -26,8 +26,8 @@ The guide also provides tips for creating dedicated cluster state snapshots and
 
 * To use {{kib}}'s **Snapshot and Restore** feature, you must have the following permissions:
 
-    * [Cluster privileges](../../users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md#privileges-list-cluster): `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
-    * [Index privilege](../../users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md#privileges-list-indices): `all` on the `monitor` index
+    * [Cluster privileges](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/security-privileges.md#privileges-list-cluster): `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
+    * [Index privilege](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/security-privileges.md#privileges-list-indices): `all` on the `monitor` index
 
 * You can only take a snapshot from a running cluster with an elected [master node](../../distributed-architecture/clusters-nodes-shards/node-roles.md#master-node-role).
 * A snapshot repository must be [registered](self-managed.md) and available to the cluster.
@@ -59,7 +59,7 @@ Elastic Cloud Hosted deployments automatically include the `cloud-snapshot-polic
 
 ### {{slm-init}} security [slm-security]
 
-The following [cluster privileges](../../users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md#privileges-list-cluster) control access to the {{slm-init}} actions when {{es}} {{security-features}} are enabled:
+The following [cluster privileges](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/security-privileges.md#privileges-list-cluster) control access to the {{slm-init}} actions when {{es}} {{security-features}} are enabled:
 
 `manage_slm`
 :   Allows a user to perform all {{slm-init}} actions, including creating and updating policies and starting and stopping {{slm-init}}.

deploy-manage/tools/snapshot-and-restore/restore-snapshot.md

@@ -24,8 +24,8 @@ This guide also provides tips for [restoring to another cluster](#restore-differ
 
 ## Prerequisites
 - To use Kibana’s Snapshot and Restore feature, you must have the following permissions:
-  - [Cluster privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md#privileges-list-cluster): `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
-  - [Index privilege](/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md#privileges-list-indices): `all` on the monitor index
+  - [Cluster privileges](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/security-privileges.md#privileges-list-cluster): `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
+  - [Index privilege](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/security-privileges.md#privileges-list-indices): `all` on the monitor index
 - You can only restore a snapshot to a running cluster with an elected [master node](/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles.md#master-node-role). The snapshot’s repository must be registered and available to the cluster.
 - The snapshot and cluster versions must be compatible. See [Snapshot compatibility](/deploy-manage/tools/snapshot-and-restore.md#snapshot-compatibility).
 - To restore a snapshot, the cluster’s global metadata must be writable. Ensure there aren’t any cluster blocks that prevent writes. The restore operation ignores index blocks.

deploy-manage/tools/snapshot-and-restore/self-managed.md

@@ -20,8 +20,8 @@ In this guide, you’ll learn how to:
 
 * To use {{kib}}'s **Snapshot and Restore** feature, you must have the following permissions:
 
-    * [Cluster privileges](../../users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md#privileges-list-cluster): `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
-    * [Index privilege](../../users-roles/cluster-or-deployment-auth/elasticsearch-privileges.md#privileges-list-indices): `all` on the `monitor` index
+    * [Cluster privileges](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/security-privileges.md#privileges-list-cluster): `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
+    * [Index privilege](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/security-privileges.md#privileges-list-indices): `all` on the `monitor` index
 
 * To register a snapshot repository, the cluster’s global metadata must be writeable. Ensure there aren’t any [cluster blocks](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/configuration-reference/miscellaneous-cluster-settings.md#cluster-read-only) that prevent write access.
 

deploy-manage/users-roles.md

@@ -40,7 +40,7 @@ If you’re using {{ecloud}}, then you can perform the following tasks to contro
 * [Invite users to join your organization](/deploy-manage/users-roles/cloud-organization/manage-users.md)
 * Assign [user roles and privileges](/deploy-manage/users-roles/cloud-organization/user-roles.md): 
   * Manage organization-level roles and high-level access to deployments and projects. 
-  * Assign project-level roles and [create custom roles](/deploy-manage/users-roles/custom-roles.md). ({{serverless-short}} only)
+  * Assign project-level roles and [create custom roles](/deploy-manage/users-roles/serverless-custom-roles.md). ({{serverless-short}} only)
 * Configure [SAML single sign-on](/deploy-manage/users-roles/cloud-organization/configure-saml-authentication.md) for your organization
 
 ::::{tip}
@@ -84,7 +84,7 @@ You can't manage users and roles for {{eck}} clusters at the orchestrator level.
 
 As an extension of the [predefined instance access roles](/deploy-manage/users-roles/cloud-organization/user-roles.md#ec_instance_access_roles) offered for {{serverless-short}} projects, you can create custom roles at the project level to provide more granular control, and provide users with only the access they need within specific projects.
 
-[Learn more about custom roles for {{serverless-full}} projects](/deploy-manage/users-roles/custom-roles.md).
+[Learn more about custom roles for {{serverless-full}} projects](/deploy-manage/users-roles/serverless-custom-roles.md).
 
 ## Cluster or deployment level
 

deploy-manage/users-roles/cloud-organization/user-roles.md

@@ -69,7 +69,7 @@ For {{ech}} deployments, the following predefined roles are available:
 There are two ways for a user to access {{kib}} instances of an {{ech}} deployment:
 
 * [Directly with {{es}} credentials](/deploy-manage/users-roles/cluster-or-deployment-auth.md). In this case, users and their roles are managed directly in {{kib}}. Users in this case don’t need to be members of the {{ecloud}} organization to access the deployment. Note that if you have several deployments, you need to manage users for each of them, individually.
-* Through your {{ecloud}} organization. In this case, users who are members of your organization log in to {{ecloud}} and can open the deployments they have access to. Their access level is determined by the roles assigned to them from the **Organization** page. {{ecloud}} roles are mapped to [Stack roles](/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-roles.md#built-in-roles) on a per-deployment level. When logging in to a specific deployment, users get the stack role that maps to their {{ecloud}} role for that particular deployment.
+* Through your {{ecloud}} organization. In this case, users who are members of your organization log in to {{ecloud}} and can open the deployments they have access to. Their access level is determined by the roles assigned to them from the **Organization** page. {{ecloud}} roles are mapped to [{{stack}} roles](/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-roles.md) on a per-deployment level. When logging in to a specific deployment, users get the stack role that maps to their {{ecloud}} role for that particular deployment.
 
 The following table shows the default mapping:
 

deploy-manage/users-roles/cluster-or-deployment-auth/authorization-delegation.md

@@ -1,17 +1,23 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-authorization-delegation.html
+applies_to:
+  deployment:
+    ece:
+    eck:
+    ess:
+    self:
 ---
 
 # Authorization delegation [configuring-authorization-delegation]
 
 In some cases, after the user has been authenticated by a realm, we may want to delegate user lookup and assignment of roles to another realm. Any realm that supports [user lookup](looking-up-users-without-authentication.md) (without needing the user’s credentials) can be used as an authorization realm.
 
-For example, a user that is authenticated by the Kerberos realm can be looked up in the LDAP realm. The LDAP realm takes on responsibility for searching the user in LDAP and determining the role. In this case, the LDAP realm acts as an *authorization realm*.
+For example, a user that is authenticated by the Kerberos or PKI realm can be looked up in the LDAP realm. The LDAP realm takes on responsibility for searching the user in LDAP and determining the role. In this case, the LDAP realm acts as an *authorization realm*.
 
 ## LDAP realm as an authorization realm [_ldap_realm_as_an_authorization_realm]
 
-Following is an example configuration for the LDAP realm that can be used as an *authorization realm*. This LDAP realm is configured in user search mode with a specified filter.
+The following is an example configuration for the LDAP realm that can be used as an *authorization realm*. This LDAP realm is configured in user search mode with a specified filter.
 
 For more information on configuring LDAP realms see [LDAP user authentication](ldap.md).
 
@@ -36,11 +42,11 @@ xpack:
 
 1. Here, we explicitly allow the LDAP realm to be used for authentication (that is, users can authenticate using their LDAP username and password). If we wanted this LDAP realm to be used for authorization only, then we would set this to `false`.
 
-
-
 ## Kerberos realm configured to delegate authorization [_kerberos_realm_configured_to_delegate_authorization]
 
-Following is an example configuration where the Kerberos realm authenticates a user and then delegates authorization to the LDAP realm. The Kerberos realm authenticates the user and extracts user principal name (usually of format `user@REALM`). In this example, we enable the `remove_realm_name` setting to remove the `@REALM` part from the user principal name to get the username. This username is used to do a user lookup by the configured authorization realms (in this case the LDAP realm).
+The following is an example configuration where the Kerberos realm authenticates a user and then delegates authorization to the LDAP realm. The Kerberos realm authenticates the user and extracts user principal name (usually of format `user@REALM`). 
+
+In this example, we enable the `remove_realm_name` setting to remove the `@REALM` part from the user principal name to get the username. This username is used to do a user lookup by the configured authorization realms (in this case the LDAP realm).
 
 For more information on Kerberos realm see [Kerberos authentication](kerberos.md).
 
@@ -60,7 +66,9 @@ xpack:
 
 ## PKI realm configured to delegate authorization [_pki_realm_configured_to_delegate_authorization]
 
-We can similarly configure PKI realm to delegate authorization to LDAP realm. The user is authenticated by the PKI realm and the authorization is delegated to the LDAP realm. In this example, the username is the common name (CN) extracted from the DN of the client certificate. The LDAP realm uses this username to lookup user and assign the role.
+is an example configuration where the PKI realm authenticates a user and then delegates authorization to the LDAP realm.
+
+In this example, the username is the common name (CN) extracted from the DN of the client certificate. The LDAP realm uses this username to lookup user and assign the role.
 
 For more information on PKI realms see [PKI user authentication](pki.md).
 
@@ -74,7 +82,3 @@ xpack:
             order: 2
             authorization_realms: ldap1
 ```
-
-Similar to the above examples, we can configure realms to delegate authorization to authorization realms (which have the capability to lookup users by the username and assign roles).
-
-