Removing mention of legacy roles (#35263) (#35292)

* Removing mention of legacy roles * Removing more legacy references
elastic · Apr 18, 2019 · a1b149e · a1b149e
1 parent 89449c3
commit a1b149e
Show file tree

Hide file tree

Showing 3 changed files with 0 additions and 91 deletions.
diff --git a/docs/development/security/rbac.asciidoc b/docs/development/security/rbac.asciidoc
@@ -100,75 +100,3 @@ Authorization: Basic foo_read_only_user password
 {es} checks if the user is granted a specific action. If the user is assigned a role that grants a privilege, {es} uses the <<development-rbac-privileges, {kib} privileges>> definition to associate this with the actions, which makes authorizing users more intuitive and flexible programatically.
 
 Once we have authorized the user to perform a specific action, we can execute the request using `callWithInternalUser`.
-
-[[development-rbac-legacy-fallback]]
-==== Legacy Fallback
-
-Users have existing roles that rely on index privileges to the `.kibana` index. The legacy fallback uses the `callWithRequest` method when the user doesn't have any application privileges. This relies on the user having index privileges on `.kibana`. The legacy fallback will be available until 7.0.
-
-Within the secured instance of the `SavedObjectsClient` the `_has_privileges` check determines if the user has any index privileges on the `.kibana` index:
-
-[source,js]
-----------------------------------
-POST /_security/user/_has_privileges
-Content-Type: application/json
-Authorization: Basic foo_legacy_user password
-
-{
-   "applications":[
-       {
-           "application":"kibana-.kibana",
-           "resources":["*"],
-           "privileges":[
-             "saved_object:dashboard/save"
-           ]
-       }
-   ],
-   "index": [
-       {
-           "names": ".kibana",
-           "privileges": ["create", "delete", "read", "view_index_metadata"]
-       }
-   ]
-}
-----------------------------------
-
-Here is an example response if the user does not have application privileges, but does have privileges on the `.kibana` index:
-
-[source,js]
-----------------------------------
-{
-  "username": "foo_legacy_user",
-  "has_all_requested": false,
-  "cluster": {},
-  "index": {
-    ".kibana": {
-      "read": true,
-      "view_index_metadata": true,
-      "create": true,
-      "delete": true
-    }
-  },
-  "application": {
-    "kibana-.kibana": {
-      "*": {
-        "saved_object:dashboard/save": false
-      }
-    }
-  }
-}
-----------------------------------
-
-{kib} automatically detects that the request could be executed against `.kibana` using `callWithRequest` and does so.
-
-When the user first logs into {kib}, if they have no application privileges and will have to rely on the legacy fallback, {kib} logs a deprecation warning similar to the following:
-
-[source,js]
-----------------------------------
-${username} relies on index privileges on the {kib} index. This is deprecated and will be removed in {kib} 7.0
-----------------------------------
-
-[[development-rbac-reserved-roles]]
-==== Reserved roles
-
-Ideally, the `kibana_user` and `kibana_dashboard_only_user` roles should only use application privileges, and no longer have index privileges on the `.kibana` index. However, making this switch forces the user to incur downtime if Elasticsearch is upgraded to >= 6.4, and {kib} is running < 6.4. To mitigate this downtime, for the 6.x releases the `kibana_user` and `kibana_dashbord_only_user` roles have both application privileges and index privileges. When {kib} is running >= 6.4 it uses the application privileges to authorize the user, but when {kib} is running < 6.4 {kib} relies on the direct index privileges. 
diff --git a/docs/security/authorization/index.asciidoc b/docs/security/authorization/index.asciidoc
@@ -19,18 +19,3 @@ to assign a specific <<kibana-privileges, Kibana privilege>> at that tenant. Aft
 custom role, you should assign this role to the user(s) that you wish to have access.
 
 While multi-tenant installations are supported, the recommended approach to securing access to segments of {kib} is to grant users access to specific spaces.
-
-==== Legacy roles
-
-Prior to {kib} 6.4, {kib} users required index privileges to the `kibana.index`
-in {es}. This approach is deprecated starting in 6.4, and you will need to switch to using
-<<kibana-privileges>> before 7.0. When a user logs into {kib} and they're using
-a legacy role, the following is logged to your {kib} logs:
-
-[source,js]
-----------------------------------
-<username> relies on index privileges on the Kibana index. This is deprecated and will be removed in Kibana 7.0
-----------------------------------
-
-To disable legacy roles from being authorized in {kib}, set `xpack.security.authorization.legacyFallback` to `false`
-in your `kibana.yml`.
diff --git a/docs/settings/security-settings.asciidoc b/docs/settings/security-settings.asciidoc
@@ -25,10 +25,6 @@ authorization using <<kibana-privileges>> are disabled. +
 Set to `true` to enable audit logging for security events. This is set to `false` by default.
 For more details see <<xpack-security-audit-logging>>.
 
-`xpack.security.authorization.legacyFallback`::
-Set to `true` (default) to enable the legacy fallback. See <<xpack-security-authorization>>
-for more details.
-
 [float]
 [[security-ui-settings]]
 ==== User interface security settings