Update RBAC instructions for the Jira plugin (#65190)

Closes #62251

Edit the Jira plugin guide to note that the role given to the Access
Request plugin must be able to update Access Requests.

- Use the existing `rbac-update.mdx` plugin to explain how to create a
  role that can update Access Requests and impersonate a user with that
  role.
- Inline the Machine ID partial in Step 2 and edit the content to
  include a custom role.

docs/pages/identity-governance/access-requests/plugins/jira.mdx

@@ -71,16 +71,58 @@ your Teleport cluster.
 
 ## Step 2/8. Define a Teleport Jira plugin user
 
-The required permissions for the plugin are configured in the preset `access-plugin`
-role. To generate credentials for the plugin, define either a Machine ID bot user
-or a regular Teleport user.
+The required permissions for the plugin are configured in the preset
+`access-plugin-update` role. To generate credentials for the plugin, define
+either a Machine ID bot user or a regular Teleport user.
 
 <Tabs>
 <TabItem label="Machine & Workload Identity">
-(!docs/pages/includes/plugins/rbac-impersonate-machine-id.mdx!)
+
+Teleport's Access Request plugins authenticate to your Teleport cluster as a
+user with permissions to list, read, and update Access Requests. This way,
+plugins can retrieve Access Requests from the Teleport Auth Service, present
+them to reviewers, and modify them after a review.
+
+Define a role called `access-plugin-update` by adding the following content to a
+file called `access-plugin-update.yaml`:
+
+```yaml
+kind: role
+version: v5
+metadata:
+  name: access-plugin-update
+spec:
+  allow:
+    rules:
+      - resources: ['access_request']
+        verbs: ['list', 'read', 'update']
+      - resources: ['access_plugin_data']
+        verbs: ['update']
+```
+
+Create the role:
+
+```code
+$ tctl create -f access-plugin-update.yaml
+```
+
+(!docs/pages/includes/create-role-using-web.mdx!)
+
+If you haven't set up a Machine ID bot yet, refer to the [deployment
+guide](../../../machine-workload-identity/deployment/deployment.mdx) to run the
+`tbot` binary on your infrastructure.
+
+Next, allow the Machine ID bot to generate credentials for the
+`access-plugin-update` role. You can do this using `tctl`, replacing `my-bot`
+with the name of your bot:
+
+```code
+$ tctl bots update my-bot --add-roles access-plugin-update
+```
+
 </TabItem>
 <TabItem label="Long-lived identity files">
-(!docs/pages/includes/plugins/rbac-impersonate.mdx!)
+(!docs/pages/includes/plugins/rbac-update.mdx!)
 </TabItem>
 </Tabs>
 
@@ -96,7 +138,7 @@ longer-lived identity files with `tctl`:
 (!docs/pages/includes/plugins/tbot-identity.mdx secret="teleport-plugin-jira-identity"!)
 </TabItem>
 <TabItem label="Long-lived identity files">
-(!docs/pages/includes/plugins/identity-export.mdx user="access-plugin" secret="teleport-plugin-jira-identity"!)
+(!docs/pages/includes/plugins/identity-export.mdx user="access-plugin-update" secret="teleport-plugin-jira-identity"!)
 </TabItem>
 </Tabs>
 

docs/pages/includes/plugins/rbac-update.mdx

@@ -3,14 +3,14 @@ user with permissions to list, read, and update Access Requests. This way,
 plugins can retrieve Access Requests from the Teleport Auth Service, present
 them to reviewers, and modify them after a review.
 
-Define a user and role called `access-plugin` by adding the following content to
-a file called `access-plugin.yaml`:
+Define a user and role called `access-plugin-update` by adding the following
+content to a file called `access-plugin-update.yaml`:
 
 ```yaml
 kind: role
 version: v5
 metadata:
-  name: access-plugin
+  name: access-plugin-update
 spec:
   allow:
     rules:
@@ -21,32 +21,32 @@ spec:
 ---
 kind: user
 metadata:
-  name: access-plugin
+  name: access-plugin-update
 spec:
-  roles: ['access-plugin']
+  roles: ['access-plugin-update']
 version: v2
 ```
 
 Create the user and role:
 
 ```code
-$ tctl create -f access-plugin.yaml
+$ tctl create -f access-plugin-update.yaml
 ```
 
 (!docs/pages/includes/create-role-using-web.mdx!)
 
 As with all Teleport users, the Teleport Auth Service authenticates the
-`access-plugin` user by issuing short-lived TLS credentials. In this case, we
-will need to request the credentials manually by *impersonating* the
-`access-plugin` role and user.
+`access-plugin-update` user by issuing short-lived TLS credentials. In this
+case, we will need to request the credentials manually by *impersonating* the
+`access-plugin-update` role and user.
 
 If you are running a self-hosted Teleport Enterprise deployment and are using
 `tctl` from the Auth Service host, you will already have impersonation
 privileges.
 
-To grant your user impersonation privileges for `access-plugin`, define a role
-called `access-plugin-impersonator` by pasting the following YAML document into
-a file called `access-plugin-impersonator.yaml`:
+To grant your user impersonation privileges for `access-plugin-update`, define a
+role called `access-plugin-impersonator` by pasting the following YAML document
+into a file called `access-plugin-impersonator.yaml`:
 
 ```yaml
 kind: role
@@ -57,9 +57,9 @@ spec:
   allow:
     impersonate:
       roles:
-      - access-plugin
+      - access-plugin-update
       users:
-      - access-plugin
+      - access-plugin-update
 ```
 
 Create the `access-plugin-impersonator` role: 
@@ -68,22 +68,4 @@ Create the `access-plugin-impersonator` role:
 $ tctl create -f access-plugin-impersonator.yaml
 ```
 
-Edit your user definition:
-
-```code
-$ TELEPORT_USER=$(tsh status --format=json | jq -r .active.username)
-$ tctl edit users/${TELEPORT_USER?}
-```
-
-Edit your user to include the role you just created:
-
-```diff
-  roles:
-   - access
-   - auditor
-   - editor
-+  - access-plugin-impersonator
-```
-
-Log out of your Teleport cluster and log in again. You will now be able to
-generate signed certificates for the `access-plugin` role and user.
+(!docs/pages/includes/add-role-to-user.mdx role="access-plugin-impersonator"!)