RBAC in Couchbase is less about restricting who can see what and more about defining what actions specific users can perform on specific resources.
Let’s see it in action. Imagine you have a users bucket and an orders bucket. You want a reporting user to only be able to read documents from users but read and write to orders.
First, create a role. Roles are collections of privileges.
couchbase-cli role-create --cluster=<host>:<port> --username=<admin_user> --password=<admin_password> \
--role-name="reporting_read_users" --privileges="data_read on bucket users"
Now, create another role for the orders bucket.
couchbase-cli role-create --cluster=<host>:<port> --username=<admin_user> --password=<admin_password> \
--role-name="reporting_read_write_orders" --privileges="data_read on bucket orders, data_write on bucket orders"
Next, create a user and assign these roles.
couchbase-cli user-create --cluster=<host>:<port> --username=<admin_user> --password=<admin_password> \
--user="reporting_user" --password="reporting_password" \
--roles="reporting_read_users,reporting_read_write_orders"
Now, if the reporting_user tries to read from users, it works:
curl -u reporting_user:reporting_password http://<host>:8091/get/users/user123
But if they try to delete from users:
curl -u reporting_user:reporting_password -X DELETE http://<host>:8091/delete/users/user123
They’ll get a 403 Forbidden error because the reporting_read_users role only grants data_read on the users bucket, not data_delete.
The problem RBAC solves is granular control over data operations beyond just authentication. It allows you to implement the principle of least privilege, ensuring users and applications only have the permissions they absolutely need. This is crucial for security, compliance, and preventing accidental data corruption.
Internally, Couchbase maintains a mapping of users to roles, and roles to specific privileges. When a user attempts an operation, Couchbase checks their assigned roles against the privileges required for that operation on the target resource. If any required privilege is missing, the operation is denied.
The exact levers you control are the roles and the privileges that make up those roles. Privileges are very specific: data_read, data_write, data_delete, data_upsert, bucket_create, bucket_delete, view_create, query_select, index_create, etc. You can apply these privileges to specific buckets, or to the cluster level. For example, a cluster_admin role would have broad privileges applied to the entire cluster.
A common point of confusion is the difference between data_read and query_select. data_read is a lower-level privilege that allows direct access to document data via the Key-Value API (e.g., GET, SET, DELETE operations on a specific document key). query_select is a higher-level privilege that allows executing N1QL queries. A user might be able to data_read documents but not query_select them if they don’t have the necessary privileges for N1QL.
The next concept you’ll likely encounter is managing these roles and privileges at scale, potentially integrating with external identity providers using SAML or SCIM.