Eventing Role-Based Access Control (RBAC)
Full Administrators or users with proper Role-Based Access Control (RBAC) roles can create and manage Eventing Functions.
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 Server Enterprise Edition provides RBAC with multiple roles for finer access control.
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. Roles can be assigned to individual users, and to groups, by means of either the UI or the REST API.
For a complete list of roles, see Roles.
Note that most roles can be assigned only on the Enterprise Edition of Couchbase Server: on the Community Edition of Couchbase Server, only the bucket_full_access
,
admin
, and ro_admin
roles can be assigned.
For more information, see Authorization, and Manage Users, Groups, and Roles.
Function Scope
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
Changing the access role (i.e.,
by revoking write permissions) could impact deployed eventing functions that have been assigned to this role. |
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.
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 an Eventing Function, either of these roles can set the Function Scope to *.*; no other RBAC role is allowed to use this Function Scope.
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 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.
Eventing and RBAC for Non-privileged Users
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 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
The following minimal resources are required for a non-privileged user to access the Eventing Service and create and manage Eventing Functions.
-
Data Reader
-
Eventing Storage keyspace or Scratchpad
-
-
Data Writer
-
Eventing Storage keyspace or Scratchpad
-
-
Data DCP reader
-
Mutation Source
-
-
Eventing / Manage Scope Function
-
bucket.scope or bucket.
-
Minimal Eventing RBAC role example
-
Access the Couchbase Web Console > Security and Select "ADD GROUP".
-
Configure the group as follows:
-
Data Reader
andData Writer
are required for the Eventing Storage or scratchpad. -
Data DCP Reader
is required to fetch the mutations from DCP.this item was defined as bulk.data
which would allow building Evening functions that can listen to any collection underbulk.data
.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.
-
-
Hit Save to store the GROUP to the system.
-
Access the Couchbase Web Console > Security and Select "ADD USER".
-
Associate the GROUP to the user so the user can inherit all the roles in the group.
-
Add your password and verify it in the lower two boxes
-
Hit Save to store the USER to the system.
-
Access the Couchbase Web Console > Security
-
Select GROUPS on the right, you should see your definition for GROUP
eventing_min
. -
Select USERS on the right, you should see your definition for USER
user_min
.
Beyond a Minimal Eventing RBAC role
You may consider adding
-
Data Reader
-
Mutation Source
-
-
Data Writer
-
Mutation Source
-
-
Data Monitor
-
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.
-
Data Reader
-
Bucket Alias
-
-
Data Writer
-
Bucket Alias
-
If you plan to use SQL++ consider adding at lease SELECT privileges
-
Query & Index / Query Select
-
Mutation Source
-
Multi-tenancy in Eventing
The "Function Scope" in an Eventing Function works with the RBAC selection in "Eventing / Manage Scope Function" to limit access to between tenants in both the UI and the REST API.
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 the Eventing Functions.
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
.