[Docs] Update security and spaces docs/screenshots (#105652) (#105846)

# Conflicts:
#	docs/user/security/authorization/index.asciidoc
#	docs/user/security/images/create-role-dls-example.png
#	docs/user/security/images/create-role-index-example.png

docs/management/managing-saved-objects.asciidoc

@@ -37,12 +37,15 @@ and select *Relationships*.
 [[managing-saved-objects-export-objects]]
 === Import and export
 
-Using the import and export commands, you can move objects between different
+Using the import and export actions, you can move objects between different
 {kib} instances. This action is useful when you
 have multiple environments for development and production.
 Import and export also work well when you have a large number
 of objects to update and want to batch the process.
 
+In addition to the user interface, {kib} provides beta <<saved-objects-api-import, import>> and <<saved-objects-api-export, export>> APIs if
+you want to automate this process.
+
 [float]
 ==== Compatibility across versions
 

docs/spaces/index.asciidoc

@@ -12,7 +12,7 @@ spaces, you're asked to choose a space when you log in to Kibana. You can change
 current space at any time by using the menu.
 
 [role="screenshot"]
-image::spaces/images/change-space.png["Change current space menu"]
+image::images/change-space.png["Change current space menu"]
 
 Kibana supports spaces in several ways.  You can:
 
@@ -40,7 +40,7 @@ Open the main menu, then click *Stack Management > Spaces* for an overview of yo
 for you to create, edit, and delete spaces.
 
 [role="screenshot"]
-image::spaces/images/space-management.png["Space management"]
+image::images/space-management.png["Space management"]
 
 [float]
 ==== Create or edit a space
@@ -57,7 +57,7 @@ You cannot change the space identifier once you create the space.
 if you prefer to create spaces programatically.
 
 [role="screenshot"]
-image::spaces/images/edit-space.png["Space management"]
+image::images/edit-space.png["Space management"]
 
 [float]
 ==== Delete a space
@@ -81,7 +81,7 @@ to specific features on a per-user basis, you must configure
 <<xpack-security-authorization, Kibana Security>>.
 
 [role="screenshot"]
-image::spaces/images/edit-space-feature-visibility.png["Controlling features visiblity"]
+image::images/edit-space-feature-visibility.png["Controlling features visiblity"]
 
 [float]
 [[spaces-control-user-access]]
@@ -95,26 +95,13 @@ while analysts or executives might have Dashboard and Canvas with read-only priv
 See <<adding_kibana_privileges>> for details.
 
 [role="screenshot"]
-image::spaces/images/spaces-roles.png["Controlling features visiblity"]
+image::images/spaces-roles.png["Controlling features visiblity"]
 
 [float]
 [[spaces-moving-objects]]
 === Move saved objects between spaces
 
-To <<managing-saved-objects-copy-to-space, copy objects>> from one space to another, open the main menu,
-then click *Stack Management > Saved Objects*.
-
-Alternately, you can move objects using {kib}'s <<managing-saved-objects-export-objects, import and export>>
-interface.
-
-. Navigate to the space that contains your saved objects.
-. Export your saved objects.
-. Navigate to the space where you want to import the objects.
-. Import your saved objects.
-. (Optional) Delete objects in the export space that you no longer need.
-
-{kib} also has beta <<saved-objects-api-import, import>> and
-<<saved-objects-api-export, export>> APIs if you want to automate this process.
+To move saved objects between spaces, you can <<managing-saved-objects-copy-to-space, copy objects>>, or <<managing-saved-objects-export-objects, export and import objects>>.
 
 [float]
 [[spaces-default-route]]
@@ -125,10 +112,10 @@ The landing page can route users to a specific dashboard, application, or saved
 
 To configure the landing page, use the default route setting in
 <<kibana-general-settings, Stack Management > {kib} > Advanced settings>>.
-For example, you might set the default route to `/app/kibana#/dashboards`.
+For example, you might set the default route to `/app/dashboards`.
 
 [role="screenshot"]
-image::spaces/images/spaces-configure-landing-page.png["Configure space-level landing page"]
+image::images/spaces-configure-landing-page.png["Configure space-level landing page"]
 
 
 [float]

docs/user/introduction.asciidoc

@@ -206,7 +206,7 @@ image::images/rules-and-connectors.png[Rules and Connectors view]
 === Organize your work in spaces
 
 Want to share {kib}’s goodness with other people or teams without overwhelming them? You can do so
-with <<xpack-spaces, Spaces>>, built for organizing your visualizations, dashboards, and indices.
+with <<xpack-spaces, Spaces>>, built for organizing your visualizations, dashboards, and index patterns.
 Think of a space as its own mini {kib} installation&mdash;it’s isolated from all other spaces,
 so you can tailor it to your specific needs without impacting others.
 
@@ -234,15 +234,15 @@ For example, roles with no access to an app will not have access to its alerts.
 ==== Control feature visibility
 
 You can take spaces one step further and control which features are visible
-within each space. For example, you might hide **Dev Tools** in your "Executive"
-space or show **Stack Monitoring** only in your "Admin" space.
+within each space. For example, you might hide **Dev Tools** in your "Marketing"
+space or show **Stack Monitoring** only in your "Engineering" space.
 
 Controlling feature visibility is not a security feature. To secure access
 to specific features on a per-user basis, you must configure
 <<xpack-security-authorization,{kib} Security>>.
 
 [role="screenshot"]
-image::images/features-control.png[Features Controls view]
+image::spaces/images/edit-space-feature-visibility.png[Features Controls view]
 
 [float]
 [[intro-kibana-Security]]
@@ -260,7 +260,7 @@ see <<security-settings-kb,Security settings in {kib}>>.
 allowing you to login using {es}’s built-in realms, or by your own single sign-on provider.
 
 [role="screenshot"]
-image::images/login-screen.png[Login page]
+image::security/images/kibana-login.png[Login page]
 
 [float]
 ==== Secure access
@@ -281,7 +281,7 @@ while analysts or executives might have *Dashboard* and *Canvas* with read-only
 levels, or you can automate role creation via our <<role-management-api,API>>.
 
 [role="screenshot"]
-image::images/roles-and-privileges.png[{kib privileges}]
+image::spaces/images/spaces-roles.png[{kib privileges}]
 
 [float]
 ==== Audit access

docs/user/security/access-agreement.asciidoc

@@ -2,14 +2,16 @@
 [[xpack-security-access-agreement]]
 === Access agreement
 
-Some work environments require you to acknowledge and accept an agreement before you can access {kib}, which can contain sensitive information. The agreement text supports Markdown format and can be specified using the `xpack.security.authc.providers.<provider-type>.<provider-name>.accessAgreement.message` setting.
+Access agreement is a https://www.elastic.co/subscriptions[subscription feature] that requires users to acknowledge and accept an
+agreement before accessing {kib}. The agreement text supports Markdown format and can be specified using the
+`xpack.security.authc.providers.<provider-type>.<provider-name>.accessAgreement.message` setting.
 
 [NOTE]
 ============================================================================
 You need to acknowledge the access agreement only once per session, and {kib} reports the acknowledgement in the audit logs.
 ============================================================================
 
-Here is how your `kibana.yml` can look like if you define an access agreement:
+Here is an example of defining an access agreement in `kibana.yml`:
 
 [source,yaml]
 --------------------------------------------------------------------------------
@@ -17,11 +19,14 @@ xpack.security.authc.providers:
   basic.basic1:
     order: 0
     accessAgreement:
-      message: "**You are accessing a system with a sensitive information** \n\n
-                  By logging in, you acknowledge that (shortened ...)"
+      message: |
+        **You are accessing a system with sensitive information**
+
+        By logging in, you acknowledge that information system usage
+        ...(shortened)
 --------------------------------------------------------------------------------
 
 When you authenticate using `basic.basic1`, you'll see the following agreement that you must acknowledge before you can access {kib}:
 
 [role="screenshot"]
-image::user/security/images/access-agreement.png["Access Agreement UI"]
+image::images/access-agreement.png["Access Agreement UI"]

docs/user/security/api-keys/index.asciidoc

@@ -17,7 +17,7 @@ remote sources, without a live user interaction.
 To manage API keys, open the main menu, then click *Stack Management > API Keys*.
 
 [role="screenshot"]
-image:user/security/api-keys/images/api-keys.png["API Keys UI"]
+image:images/api-keys.png["API Keys UI"]
 
 [float]
 [[api-keys-service]]
@@ -49,7 +49,7 @@ cluster privileges to use API keys in {kib}. To manage roles, open the main menu
 To create an API key, open the main menu, then click *Stack Management > API Keys > Create API key*.
 
 [role="screenshot"]
-image:user/security/api-keys/images/create-api-key.png["Create API Key UI"]
+image:images/create-api-key.png["Create API Key UI"]
 
 Once created, you can copy the API key (Base64 encoded) and use it to send requests to {es} on your behalf. For example:
 

docs/user/security/audit-logging.asciidoc

@@ -2,9 +2,9 @@
 [[xpack-security-audit-logging]]
 === Audit logs
 
-You can enable auditing to keep track of security-related events such as
-authorization success and failures. Logging these events enables you to monitor
-{kib} for suspicious activity and provides evidence in the event of an attack.
+Audit logging is a https://www.elastic.co/subscriptions[subscription feature] that you can enable to keep track of security-related events,
+such as authorization success and failures. Logging these events enables you to monitor {kib} for suspicious activity and provides evidence
+in the event of an attack.
 
 Use the {kib} audit logs in conjunction with {ref}/enable-audit-logging.html[{es} audit logging] to get a
 holistic view of all security related events. {kib} defers to the {es} security

docs/user/security/authentication/index.asciidoc

@@ -61,7 +61,7 @@ xpack.security.authc.providers:
 --------------------------------------------------------------------------------
 
 [role="screenshot"]
-image::user/security/images/kibana-login.png["Login Selector UI"]
+image::security/images/kibana-login.png["Login Selector UI"]
 
 For more information, refer to <<authentication-security-settings, authentication security settings>>.
 
@@ -82,7 +82,9 @@ For more information about basic authentication and built-in users, see
 [[token-authentication]]
 ==== Token authentication
 
-Token authentication allows users to log in using the same {kib} provided login form as basic authentication, and is based on the Native security realm or LDAP security realm that is provided by {es}. The token authentication provider is built on {es} token APIs.
+Token authentication is a https://www.elastic.co/subscriptions[subscription feature]. This allows users to log in using the same {kib}
+provided login form as basic authentication, and is based on the Native security realm or LDAP security realm that is provided by {es}. The
+token authentication provider is built on {es} token APIs.
 
 Prior to configuring {kib}, ensure token support is enabled in {es}. See the {ref}/security-api-get-token.html[{es} token API] documentation for more information.
 
@@ -107,7 +109,11 @@ Switching to the token authentication provider from basic one will make {kib} to
 PKI authentication will not work if {kib} is hosted behind a TLS termination reverse proxy. In this configuration, {kib} does not have direct access to the client certificates and cannot authenticate the user.
 ============================================================================
 
-PKI authentication allows users to log into {kib} using X.509 client certificates that must be presented while connecting to {kib}. The certificates must first be accepted for authentication on the {kib} TLS layer, and then they are further validated by an {es} PKI realm. The PKI authentication provider relies on the {es} {ref}/security-api-delegate-pki-authentication.html[Delegate PKI authentication API] to exchange X.509 client certificates to access tokens. All subsequent requests to {es} APIs on behalf of users will be authenticated using these access tokens.
+PKI authentication is a https://www.elastic.co/subscriptions[subscription feature]. This allows users to log
+into {kib} using X.509 client certificates that must be presented while connecting to {kib}. The certificates must first be accepted for
+authentication on the {kib} TLS layer, and then they are further validated by an {es} PKI realm. The PKI authentication provider relies on
+the {es} {ref}/security-api-delegate-pki-authentication.html[Delegate PKI authentication API] to exchange X.509 client certificates to
+access tokens. All subsequent requests to {es} APIs on behalf of users will be authenticated using these access tokens.
 
 Prior to configuring {kib}, ensure that the PKI realm is enabled in {es} and configured to permit delegation. See {ref}/configuring-pki-realm.html[Configuring a PKI realm] for more information.
 
@@ -144,9 +150,11 @@ Note that with `server.ssl.clientAuthentication` set to `required`, users are as
 [[saml]]
 ==== SAML single sign-on
 
-SAML authentication allows users to log in to {kib} with an external Identity Provider, such as Okta or Auth0. Make sure that SAML is enabled and configured in {es} before setting it up in {kib}. See {ref}/saml-guide.html[Configuring SAML single sign-on on the Elastic Stack].
+SAML authentication is part of single sign-on (SSO), a https://www.elastic.co/subscriptions[subscription feature]. This allows users to log
+in to {kib} with an external Identity Provider, such as Okta or Auth0. Make sure that SAML is enabled and configured in {es} before setting
+it up in {kib}. See {ref}/saml-guide.html[Configuring SAML single sign-on on the Elastic Stack].
 
-Enable the SAML authentication specifying which SAML realm in {es} should be used:
+Enable SAML authentication by specifying which SAML realm in {es} should be used:
 
 [source,yaml]
 --------------------------------------------------------------------------------
@@ -156,7 +164,7 @@ xpack.security.authc.providers:
     realm: saml1
 --------------------------------------------------------------------------------
 
-You can log in to {kib} via SAML Single Sign-On by navigating directly to the {kib} URL. If you aren't authenticated, you are redirected to the Identity Provider for login. Most Identity Providers maintain a long-lived session. If you log in to a different application using the same Identity Provider in the same browser, you are automatically authenticated. An exception is if {es} or the Identity Provider is configured to force you to re-authenticate. This login scenario is called _Service Provider initiated login_.
+You can log in to {kib} via SAML SSO by navigating directly to the {kib} URL. If you aren't authenticated, you are redirected to the Identity Provider for login. Most Identity Providers maintain a long-lived session. If you log in to a different application using the same Identity Provider in the same browser, you are automatically authenticated. An exception is if {es} or the Identity Provider is configured to force you to re-authenticate. This login scenario is called _Service Provider initiated login_.
 
 It's also possible to configure multiple SAML authentication providers at the same time. In this case, you will need to choose which provider to use for login at the Login Selector UI:
 
@@ -176,7 +184,7 @@ xpack.security.authc.providers:
 [float]
 ===== SAML and basic authentication
 
-You can also configure both SAML and basic authentication for the same {kib} instance. This might be the case for {kib} or {es} admins whose accounts aren't linked to the Single Sign-On users database:
+You can also configure both SAML and basic authentication for the same {kib} instance. This might be the case for {kib} or {es} admins whose accounts aren't linked to the SSO users database:
 
 [source,yaml]
 --------------------------------------------------------------------------------
@@ -196,10 +204,11 @@ To support basic authentication for the applications like `curl` or when the `Au
 [[oidc]]
 ==== OpenID Connect single sign-on
 
-Similar to SAML, authentication with OpenID Connect allows users to log in to {kib} using an OpenID Connect Provider such as Google, or Okta. OpenID Connect
-should also be configured in {es}. For more details, see {ref}/oidc-guide.html[Configuring single sign-on to the {stack} using OpenID Connect].
+OpenID Connect (OIDC) authentication is part of single sign-on (SSO), a https://www.elastic.co/subscriptions[subscription feature]. Similar
+to SAML, authentication with OIDC allows users to log in to {kib} using an OIDC Provider such as Google, or Okta. OIDC should also
+be configured in {es}. For more details, see {ref}/oidc-guide.html[Configuring single sign-on to the {stack} using OpenID Connect].
 
-Enable the OpenID Connect authentication specifying which OpenID Connect realm in {es} should be used:
+Enable OIDC authentication by specifying which OIDC realm in {es} to use:
 
 [source,yaml]
 --------------------------------------------------------------------------------
@@ -209,7 +218,7 @@ xpack.security.authc.providers:
     realm: oidc1
 --------------------------------------------------------------------------------
 
-If you want to use Third Party initiated Single Sign-On, configure your OpenID Provider to use `/api/security/oidc/initiate_login` as `Initiate Login URI`.
+To use third party initiated SSO, configure your OpenID Provider to use `/api/security/oidc/initiate_login` as `Initiate Login URI`.
 
 It's also possible to configure multiple OpenID Connect authentication providers at the same time. In this case, you need to choose which provider to use for login at the Login Selector UI:
 
@@ -229,7 +238,7 @@ xpack.security.authc.providers:
 [float]
 ===== OpenID Connect and basic authentication
 
-You can also configure both OpenID Connect and basic authentication for the same {kib} instance. This might be the case for {kib} or {es} admins whose accounts aren't linked to the Single Sign-On users database:
+You can also configure both OpenID Connect and basic authentication for the same {kib} instance. This might be the case for {kib} or {es} admins whose accounts aren't linked to the SSO users database:
 
 [source,yaml]
 --------------------------------------------------------------------------------
@@ -254,7 +263,7 @@ The following sections apply both to <<saml>> and <<oidc>>
 [float]
 ===== Access and refresh tokens
 
-Once the user logs in to {kib} Single Sign-On, either using SAML or OpenID Connect, {es} issues access and refresh tokens
+Once the user logs in to {kib} with SSO, either using SAML or OpenID Connect, {es} issues access and refresh tokens
 that {kib} encrypts and stores as a part of its own session. This way, the user isn't redirected to the Identity Provider
 for every request that requires authentication. It also means that the {kib} session depends on the <<security-session-and-cookie-settings,
 `xpack.security.session.idleTimeout` and `xpack.security.session.lifespan`>> settings, and the user is automatically logged
@@ -281,7 +290,8 @@ all applications associated with the active provider session.
 [[kerberos]]
 ==== Kerberos single sign-on
 
-As with the previous SSOs, make sure that you have configured {es} first accordingly. See {ref}/kerberos-realm.html[Kerberos authentication].
+Kerberos authentication is part of single sign-on (SSO), a https://www.elastic.co/subscriptions[subscription feature]. Make sure that
+Kerberos is enabled and configured in {es} before setting it up in {kib}. See {ref}/kerberos-realm.html[Kerberos authentication].
 
 Next, to enable Kerberos in {kib}, you will need to enable the Kerberos authentication provider in the `kibana.yml` configuration file, as follows:
 
@@ -455,7 +465,7 @@ xpack.security.sameSiteCookies: "None"
 For more information about possible values and implications, refer to <<xpack-security-sameSiteCookies, xpack.security.sameSiteCookies>>.
 For more information about iframe and cookies, refer to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe[iframe] and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite[SameSite cookies].
 
-If you're embedding {kib} in a website that supports Single Sign-On with SAML, OpenID Connect, Kerberos, or PKI, it's highly advisable to configure {kib} as a part of the Single Sign-On setup. Operating in a single and properly configured security domain provides you with the most secure and seamless user experience.
+If you're embedding {kib} in a website that supports single sign-on (SSO) with SAML, OpenID Connect, Kerberos, or PKI, it's highly advisable to configure {kib} as a part of the SSO setup. Operating in a single and properly configured security domain provides you with the most secure and seamless user experience.
 
 If you have multiple authentication providers enabled, and you want to automatically log in anonymous users when embedding anything other than dashboards and visualizations, then you will need to add the `auth_provider_hint=<anonymous-provider-name>` query string parameter to the {kib} URL that you're embedding.
 

docs/user/security/authorization/index.asciidoc

@@ -26,22 +26,80 @@ cluster, and {kib} spaces do not prevent you from granting users of two differen
 [[kibana-role-management]]
 === {kib} role management
 
-To create a role that grants {kib} privileges, open the menu, then click *Stack Management > Roles* and click **Create role**.
+Roles are a collection of privileges that allow you to perform actions in {kib} and {es}. Users are not directly granted privileges, but are instead assigned one or more roles that describe the desired level of access. When you assign a user multiple roles, the user receives a union of the roles’ privileges. This means that you cannot reduce the privileges of a user by assigning them an additional role. You must instead remove or edit one of their existing roles.
+
+To create a role, open the menu, then click *Stack Management > Roles* and click **Create role**.
 
 [float]
 ==== Required permissions
 
-The `manage_security` cluster privilege is required to access role management.
+The `manage_security` {ref}/security-privileges.html#privileges-list-cluster[cluster privilege] is required to access role management.
+
+[[adding_cluster_privileges]]
+==== Cluster privileges
+
+Cluster privileges grant access to monitoring and management features in {es}. They also enable <<management, Stack Management>> capabilities in {kib}.
+
+Refer to {ref}/security-privileges.html#privileges-list-cluster[cluster privileges] for a complete description of available options.
+
+[[adding_index_privileges]]
+==== Index privileges
+
+Each role can grant access to multiple data indices, and each index can have a different set of privileges.
+We recommend granting the `read` and `view_index_metadata` privileges to each index that you expect your users to work with in {kib}.
+
+Refer to {ref}/security-privileges.html#privileges-list-indices[index privileges] for a complete description of available options.
+
+Document-level and field-level security affords you even more granularity when it comes to granting access to your data.
+With document-level security (DLS), you can write an {es} query to describe which documents this role grants access to.
+With field-level security (FLS), you can instruct {es} to grant or deny access to specific fields within each document.
+
+[[index_privilege_example_1]]
+===== Example: Grant access to indices that match the `filebeat-*` pattern
+
+. Go to **Stack Management > Roles**, and then click **Create role**.
+. In **Index privileges**, enter:
+.. `filebeat-*` in the **Index** field.
+.. `read` and `view_index_metadata` in the **Privileges** field.
+
+[role="screenshot"]
+image::security/images/create-role-index-example.png[Create role with index privileges]
+
+[[index_privilege_dls_example]]
+===== Example: Grant read access to specific documents in indices that match the `filebeat-*` pattern
+
+{ref}/document-level-security.html[Document-level security] is a https://www.elastic.co/subscriptions[subscription feature].
+
+. Go to **Stack Management > Roles**, and then click **Create role**.
+. In **Index privileges**, enter:
+.. `filebeat-*` in the **Indices** field.
+.. `read` and `view_index_metadata` in the **Privileges** field.
+. Select **Grant read privileges to specific documents**.
+. Enter an {es} query that matches the documents your users should access. This example writes a query that allows access to documents that have a `category` field equal to `click`:
++
+[source,sh]
+--------------------------------------------------
+{
+  "match": {
+    "category": "click"
+  }
+}
+--------------------------------------------------
++
+NOTE: {kib} automatically surrounds your DLS query with a `query` block, so you don't have to provide your own.
+
+[role="screenshot"]
+image::security/images/create-role-dls-example.png[Create role with DLS index privileges]
 
 [[adding_kibana_privileges]]
-==== Adding {kib} privileges
+==== {kib} privileges
 
 To assign {kib} privileges to the role, click **Add {kib} privilege** in the {kib} section.
 
 [role="screenshot"]
-image::user/security/images/add-space-privileges.png[Add {kib} privileges]
+image::spaces/images/spaces-roles.png[Add {kib} privileges]
 
-Open the **Spaces** selection control to specify whether to grant the role access to all spaces *** Global (all spaces)** or one or more individual spaces. If you select *** Global (all spaces)**, you can’t select individual spaces until you clear your selection.
+Open the **Spaces** selection control to specify whether to grant the role access to all spaces **All Spaces** or one or more individual spaces. If you select **All Spaces**, you can’t select individual spaces until you clear your selection.
 
 Use the **Privilege** menu to grant access to features. The default is **Custom**, which you can use to grant access to individual features. Otherwise, you can grant read and write access to all current and future features by selecting **All**, or grant read access to all current and future features by selecting **Read**.
 
@@ -55,7 +113,7 @@ To apply your changes, click **Add {kib} privilege**. The privilege shows up und
 
 
 [role="screenshot"]
-image::user/security/images/create-space-privilege.png[Add {kib} privilege]
+image::security/images/create-space-privilege.png[Add {kib} privilege]
 
 ==== Feature availability
 
@@ -83,9 +141,9 @@ Features are available to users when their roles grant access to the features, *
 
 ==== Assigning different privileges to different spaces
 
-Using the same role, it’s possible to assign different privileges to different spaces. After you’ve added privileges, click **Add {kib} privilege**. If you’ve already added privileges for either *** Global (all spaces)** or an individual space, you will not be able to select these in the **Spaces** selection control.
+Using the same role, it’s possible to assign different privileges to different spaces. After you’ve added privileges, click **Add {kib} privilege**. If you’ve already added privileges for either **All Spaces** or an individual space, you will not be able to select these in the **Spaces** selection control.
 
-Additionally, if you’ve already assigned privileges at *** Global (all spaces)**, you are only able to assign additional privileges to individual spaces. Similar to the behavior of multiple roles granting the union of all privileges, {kib} privileges are also a union. If you’ve already granted the user the **All** privilege at *** Global (all spaces)**, you’re not able to restrict the role to only the **Read** privilege at an individual space.
+Additionally, if you’ve already assigned privileges at **All Spaces**, you are only able to assign additional privileges to individual spaces. Similar to the behavior of multiple roles granting the union of all privileges, {kib} privileges are also a union. If you’ve already granted the user the **All** privilege at **All Spaces**, you’re not able to restrict the role to only the **Read** privilege at an individual space.
 
 
 ==== Privilege summary
@@ -93,7 +151,7 @@ Additionally, if you’ve already assigned privileges at *** Global (all spaces)
 To view a summary of the privileges granted, click **View privilege summary**.
 
 [role="screenshot"]
-image::user/security/images/view-privilege-summary.png[View privilege summary]
+image::security/images/view-privilege-summary.png[View privilege summary]
 
 ==== Example 1: Grant all access to Dashboard at an individual space
 
@@ -104,7 +162,7 @@ image::user/security/images/view-privilege-summary.png[View privilege summary]
 . Click **Add {kib} privilege**.
 
 [role="screenshot"]
-image::user/security/images/privilege-example-1.png[Privilege example 1]
+image::security/images/privilege-example-1.png[Privilege example 1]
 
 ==== Example 2: Grant all access to one space and read access to another
 
@@ -117,12 +175,12 @@ image::user/security/images/privilege-example-1.png[Privilege example 1]
 . Click **Add {kib} privilege**.
 
 [role="screenshot"]
-image::user/security/images/privilege-example-2.png[Privilege example 2]
+image::security/images/privilege-example-2.png[Privilege example 2]
 
 ==== Example 3: Grant read access to all spaces and write access to an individual space
 
 . Click **Add {kib} privilege**.
-. For **Spaces**, select *** Global (all spaces)**.
+. For **Spaces**, select **All Spaces**.
 . For **Privilege**, select **Read**.
 . Click **Add {kib} privilege**.
 . For **Spaces**, select the individual space.
@@ -130,4 +188,4 @@ image::user/security/images/privilege-example-2.png[Privilege example 2]
 . Click **Add {kib} privilege**.
 
 [role="screenshot"]
-image::user/security/images/privilege-example-3.png[Privilege example 3]
+image::security/images/privilege-example-3.png[Privilege example 3]

docs/user/security/authorization/kibana-privileges.asciidoc

@@ -14,7 +14,7 @@ Assigning a base privilege grants access to all {kib} features, such as *Discove
 From the role management screen:
 
 [role="screenshot"]
-image::user/security/images/assign_base_privilege.png[Assign base privilege]
+image::security/images/assign-base-privilege.png[Assign base privilege]
 
 From the <<role-management-api-put, role management API>>:
 [source,js]
@@ -45,13 +45,13 @@ Assigning a feature privilege grants access to a specific feature.
 
 ===== Sub-feature privileges
 Some features allow for finer access control than the `all` and `read` privileges.
-This additional level of control is available in the Gold subscription level and higher.
+This additional level of control is a https://www.elastic.co/subscriptions[subscription feature].
 
 ===== Assigning feature privileges
 From the role management screen:
 
 [role="screenshot"]
-image::user/security/images/assign_feature_privilege.png[Assign feature privilege]
+image::security/images/assign-subfeature-privilege.png[Assign feature privilege]
 
 From the <<role-management-api-put, role management API>>:
 [source,js]

docs/user/security/encryption-keys/index.asciidoc

@@ -1,5 +1,5 @@
 [[kibana-encryption-keys]]
-=== Set up encryptions keys to protect sensitive information
+=== Set up encryption keys to protect sensitive information
 
 The `kibana-encryption-keys` command helps you set up encryption keys that {kib} uses
 to protect sensitive information.
@@ -18,7 +18,7 @@ bin/kibana-encryption-keys generate
 === Description
 
 {kib} uses encryption keys in several areas, ranging from encrypting data
-in {kib} associated indices to storing session information.  By defining these
+in {kib} associated indices to storing session information. By defining these
 encryption keys in your configuration, you'll ensure consistent operations
 across restarts.
 

docs/user/security/role-mappings/index.asciidoc

@@ -2,11 +2,10 @@
 [[role-mappings]]
 === Role mappings
 
-Role mappings allow you to describe which roles to assign to your users
-using a set of rules. Role mappings are required when authenticating via
-an external identity provider, such as Active Directory, Kerberos, PKI, OIDC,
-or SAML.
+Role mappings are part of single sign-on (SSO), a https://www.elastic.co/subscriptions[subscription feature]. This feature allows you to
+describe which roles to assign to your users using a set of rules.
 
+Role mappings are required when authenticating via an external identity provider, such as Active Directory, Kerberos, PKI, OIDC, or SAML.
 Role mappings have no effect for users inside the `native` or `file` realms.
 
 To manage your role mappings, open the main menu, then click *Stack Management > Role Mappings*.
@@ -17,7 +16,7 @@ With *Role mappings*, you can:
 * Create/Edit/Delete role mappings
 
 [role="screenshot"]
-image:user/security/role-mappings/images/role-mappings-grid.png["Role mappings"]
+image:images/role-mappings-grid.png["Role mappings"]
 
 [float]
 ==== Required permissions
@@ -46,12 +45,12 @@ starts with `sls_`, *or* belongs to the `executive` group.
 First, we give the role mapping a name, and assign the `sales` role:
 
 [role="screenshot"]
-image:user/security/role-mappings/images/role-mappings-create-step-1.png["Create role mapping, step 1"]
+image:images/role-mappings-create-step-1.png["Create role mapping, step 1"]
 
 Next, we define the two rules, making sure to set the group to *Any are true*:
 
 [role="screenshot"]
-image:user/security/role-mappings/images/role-mappings-create-step-2.gif["Create role mapping, step 2"]
+image:images/role-mappings-create-step-2.gif["Create role mapping, step 2"]
 
 Click *Save role mapping* once you're finished.
 

docs/user/security/securing-communications/elasticsearch-mutual-tls.asciidoc

@@ -109,7 +109,7 @@ This role mapping will assign the `kibana_system` role to any user that matches
 certificate's DN attribute:
 
 [role="screenshot"]
-image:user/security/images/mutual-tls-role-mapping.png["Role mapping for the {kib} client certificate"]
+image:security/images/mutual-tls-role-mapping.png["Role mapping for the {kib} client certificate"]
 
 For more information, see <<role-mappings,role mappings>>.
 --

docs/user/security/tutorials/how-to-secure-access-to-kibana.asciidoc

@@ -61,7 +61,7 @@ Create a Marketing space for your marketing analysts to use.
 If you’ve followed the example above, you should end up with a space that looks like this:
 +
 [role="screenshot"]
-image::user/security/images/tutorial-secure-access-example-1-space.png[Create space UI]
+image::security/images/tutorial-secure-access-example-1-space.png[Create space UI]
 
 
 [float]
@@ -93,7 +93,7 @@ TIP: You can add multiple patterns of indices, and grant different access levels
 If you’ve followed the example above, you should end up with a role that looks like this:
 +
 [role="screenshot"]
-image::user/security/images/tutorial-secure-access-example-1-role.png[Create role UI]
+image::security/images/tutorial-secure-access-example-1-role.png[Create role UI]
 
 
 [float]
@@ -108,7 +108,7 @@ Now that you created a role, create a user account.
 . Click *Create user*.
 
 [role="screenshot"]
-image::user/security/images/tutorial-secure-access-example-1-user.png[Create user UI]
+image::security/images/tutorial-secure-access-example-1-user.png[Create user UI]
 
 [float]
 ==== Verify
@@ -121,7 +121,7 @@ Verify that the user and role are working correctly.
 You’re taken into the `Marketing` space, and the main navigation shows only the *Dashboard* application.
 +
 [role="screenshot"]
-image::user/security/images/tutorial-secure-access-example-1-test.png[Verifying access to dashboards]
+image::security/images/tutorial-secure-access-example-1-test.png[Verifying access to dashboards]
 
 
 [float]