[DOC-11988 7.6] RBAC role change impact to eventing function

modules/eventing/pages/eventing-rbac.adoc

@@ -7,10 +7,10 @@
 [#description]
 == Description: What is RBAC
 
-Couchbase provides _Role-Based Access Control_ (RBAC), in which access privileges are assigned to fixed roles; which are in turn assigned to users (each of which may be an administrator or an application) either _directly_; or _indirectly_, by means of _user-groups_.
+Couchbase provides _Role-Based Access Control_ (RBAC), in which access privileges are assigned to fixed roles, which are in turn assigned to users, (each of which may be an administrator or an application) either _directly_; or _indirectly_, by means of _user-groups_.
 
 Couchbase Server Enterprise Edition provides RBAC with multiple roles for finer access control.
-Community Edition provides multiple users that can be assigned to limited set of roles.
+Community Edition provides multiple users that can be assigned to a limited set of roles.
 There are three fixed roles in the community edition of Couchbase providing coarser access control: Bucket Full Access (`bucket_full_access[*]`), Admin (`admin`), and Read Only Admin (`ro_admin`).
 
 A Couchbase-Server _role_ permits one or more _resources_ to be accessed according to defined _privileges_.
@@ -27,32 +27,36 @@ For more information, see xref:learn:security/authorization-overview.adoc[Author
 A bucket.scope combination is used for identifying functions belonging to the same group.
 
 Only the "Eventing Full Admin" role and also the "Full Admin" role can set the bucket.scope to  *+*+.+*+*; all other Eventing non-privileged users need to define a *Function Scope* for their Eventing functions that references an existing resource of bucket.scope. 
-This provides role based isolation of Eventing functions between non-privileged users
+This provides role-based isolation of Eventing functions between non-privileged users
 
-Typically you should set Function Scope to the bucket.scope that holds the collection that is the source of your mutations to your Eventing Function.  This best practice ensures that you _do not_  inadvertently cause an Eventing Function to undeploy by removing a *Function Scope* pointing to a resource that is not required for the function to run.
+include::cloud:eventing:partial$rbac-warning.adoc[]
 
-NOTE: A user can be assigned multiple "Eventing / Manage Scope Function" RBAC roles and if any of these roles match an existing Eventing Function's *Function Scope* then that user can manage, modify, or delete the Eventing Function even if it was created or imported by someone else.
+Typically, you should set Function Scope to the bucket.scope that holds the collection that is the source of your mutations to your Eventing Function.  This best practice ensures that you _do not_  inadvertently cause an Eventing Function to undeploy by removing a *Function Scope* pointing to a resource that is not required for the function to run.
+
+NOTE: A user can be assigned multiple "Eventing/Manage Scope Function" RBAC roles.
+If any of these roles match an existing Eventing Function's *Function Scope*, then that user can manage, modify, or delete the Eventing Function even if it was created or imported by someone else.
 
 == Privileged Users
 
 If a user role of either "Full Admin" or "Eventing Full Admin", then by default this user has all the necessary access to every resource in a cluster required to run the Eventing Service and create and manage Eventing Functions.
 
-When creating and Eventing Function either of these roles can set the *Function Scope* to *+*+.+*+*;  no other RBAC role is allowed to use this *Function Scope*.
+When creating an Eventing Function, either of these roles can set the *Function Scope* to *+*+.+*+*;  no other RBAC role is allowed to use this *Function Scope*.
 
-NOTE: When upgrading to 7.1 all Eventing Functions are assumed to be running as a privileged user and have their *Function Scope* set to *+*+.+*+* to ensure continuity of your Eventing Functions.
+NOTE: When upgrading to 7.1, all Eventing Functions are assumed to be running as a privileged user and have their *Function Scope* set to *+*+.+*+* to ensure continuity of your Eventing Functions.
 
 === Full Admin v. Eventing Full Admin
 
-Prior to 7.0.0 Eventing always run as "Full Admin". This blocked some use cases and adoption as this role allowed creation of new users and the ability to escalate privilege sets. The  "Eventing Full Admin" role introduced in 7.0 simply removes the capability of creating users and assigning/modifying RBAC credentials thus providing a bit more security.
+Prior to 7.0.0, Eventing always runs as "Full Admin". This blocked some use cases and adoption as this role allowed creation of new users and the ability to escalate privilege sets. The  "Eventing Full Admin" role introduced in 7.0 simply removes the capability of creating users and assigning/modifying RBAC credentials, thus providing a bit more security.
 
 For the Function Scope or RBAC grouping, we will use the 'bulk.data' assuming you have the role of either "Full Admin" or "Eventing Full Admin". 
-For standard or non-privileged users refer to Role-Based Access Control.
+For standard or non-privileged users, refer to Role-Based Access Control.
 
 == Eventing and RBAC for Non-privileged Users
 
-NOTE: If a user role of either "Full Admin" or "Eventing Full Admin", then this user, by default, has all the necessary access to every resource in a cluster required to run the Eventing Service and create and manage Eventing Functions.
+NOTE: If a user role of either "Full Admin" or "Eventing Full Admin", then this user, by default, has all the necessary access privileges to every resource in a cluster required to run the Eventing Service and create and manage Eventing Functions.
 
-_In RBAC although you can assign rolls directly to a *USER*,  it is generally more flexible if you define a *GROUP* and assign that group or set of roles to a *USER*, this allows reusing a *GROUP* across multiple users._
+_In RBAC, although you can assign rolls directly to a *USER*, it is generally more flexible to define a *GROUP* and then assign that group or set of roles to a *USER*.
+This allows reusing a *GROUP* across multiple users._
 
 == Minimal Eventing RBAC role
 
@@ -73,11 +77,15 @@ The following minimal resources are required for a non-privileged user to access
 +
 image::rbac_min_add_add_group.png[,%100]
 
-* Configure the group as follows: "Data Reader" and "Data Writer" are required for the Eventing Storage or scratchpad. "Data DCP Reader" is required to fetch the mutations form DCP. Note this item was defined as 'bulk.data.*' which would allow building Evening functions that can listen to any collection under 'bulk.data'.
+* Configure the group as follows:
+** `Data Reader` and `Data Writer` are required for the Eventing Storage or scratchpad.
+** `Data DCP Reader` is required to fetch the mutations from DCP.
++
+NOTE: this item was defined as `bulk.data` which would allow building Evening functions that can listen to any collection under `bulk.data`.
 +
 image::rbac_min_a.png[,538,align=middle]
 +
-The final item required is defining the *Function Scope* under "Eventing / Manage Scope Function". Since we will be listing to mutations in a collection under 'bulk.data' it makes sense to use this as our grouping.
+The final item required is defining the *Function Scope* under "Eventing / Manage Scope Function". Since we will be listing to mutations in a collection under `bulk.data`, it makes sense to use this as our grouping.
 +
 image::rbac_min_b.png[,538,align=middle]
 
@@ -101,7 +109,7 @@ image::rbac_min_c.png[,538,align=middle]
 +
 image::rbac_min_groups.png[,%100]
 
-* Select USERS on the right, you should see your definition for USER "user_min"
+* Select USERS on the right, you should see your definition for USER `user_min`.
 +
 image::rbac_min_users.png[,%100]
 
@@ -117,7 +125,8 @@ You may consider adding
 ** Mutation Source
 ** Eventing Storage keyspace or Scratchpad
 
-If you have any Bindings in your Eventing Function of type "Bucket Alias" you will need to have one or more additional settings if not already allowed.
+If you have any Bindings in your Eventing Function of type `Bucket Alias`,
+you will need to have one or more additional settings if not already allowed.
 
 * Data Reader
 ** Bucket Alias
@@ -136,12 +145,13 @@ The "Function Scope" in an Eventing Function works with the RBAC selection in "E
 A tenant might be based on company departments such as administration, sales, production and support.
 
 Below we have two tenants example (an admin and a limited user) and four Eventing Functions each with a different *Function Scope*. 
-We logged into the UI with either an Eventing Full Admin" or "Full Admin" role and thus we can access all of the  Eventing Functions. 
+We logged into the UI with either an Eventing Full Admin" or "Full Admin" role, and thus we can access all the Eventing Functions.
 
 image::rbac_admin_view.png[,%100]
 
-Now log out of the UI console and log back in as a non-privileged user (for example we use the USER "user_min" as defined above).  
-Because of the privliges defined we are only allowed access to Eventing Functions that have a *Function Scope* of 'bulk.data'.
+Now log out of the UI console and log back in as a non-privileged user,
+(for example, we use the USER `user_min` as defined above).
+Because of the privileges defined, we are only allowed access to Eventing Functions that have a *Function Scope* of `bulk.data`.
 
 image::rbac_user_view.png[,%100]