Migrate RBAC KB

## Original KB

Title: How to define RBAC endpoint permissions across all workspaces

Question: When creating custom endpoint permissions for roles, how do I apply them to all workspaces akin to the bootstrapped default workspace permissions.

Answer: Endpoint permissions can be assigned to a single workspace or all workspaces, however Kong Manager does not send the workspace details in the JSON body of the request to create / update the endpoint permissions.

The affect of this is that permissions that are created using Kong Manager will use the currently selected workspace in Kong Manager, as the workspace to be applied to.

To circumvent the Kong Manager behaviour, the admin-api can be called directly and the permissions can be set to apply to all workspaces.

Example request to create role permissions using Kong Manager:
curl -X POST 'https://admin.local.docker:8444/default/rbac/roles/SuperAdmin/endpoints'
-H 'Content-Type: application/json'
-H 'Kong-Admin-Token: admin'
--data-raw '{"endpoint":"*","actions":"create,read,update,delete","negative":false}'

To apply to all workspaces, add the workspaces key with a value of '' to the JSON payload:
curl -X POST 'https://admin.local.docker:8444/default/rbac/roles/SuperAdmin/endpoints'
-H 'Kong-Admin-Token: admin'
-H 'Content-Type: application/json'
--data-raw '{"endpoint":"","actions":"create,read,update,delete","negative":false,"workspace":"*"}'

Regardless of the workspace used in the request URL, the applicable workspace for the permission will be all workspaces '*'.

Security Note: This works regardless of which workspace the role was assigned to the user in and therefore could propose a security risk if used incorrectly.

For example, the workspace-read-only role that is auto-created upon new workspace instantiation, could have its permissions modified in this way so that all admins that previously only had read only access to the single workspace, can now read from all endpoints in all workspaces.

## Information

Use the original KB text in this issue as the source content, then inspect the repository's documentation structure and existing migration conventions to identify the destination. Preserve the RBAC examples and security warning, and consider the work done when the article is published in the appropriate documentation location with the described behavior and all-workspace risk clear.

Written by the indexing model from the issue text.