Introducing Role-Based Access Control in Couchbase Server 4.5

Over the years, it has been drilled into me to use “Least Privilege” access whenever and however possible. This specially applies to administrators – they manage important IT infrastructure components like NoSQL databases, and have the liberty to use
all the privileges the system has to offer.

If you’ve used Couchbase for long enough, the situation was –

1. The full administrator had full permission to do anything across cluster resources – buckets, views, XDCR.
2. There were only 2 out-of-the box administrator roles (all or nothing kind) – Full administrator, and read-only administrator.

This meant that if you needed someone to just to set up XDCR, or maybe to change a simple bucket setting, essentially you needed to give them full admin credentials. That was the core problem!

4.5 has been an exciting release for us from the security point of view with the introduction of Role Based Access Control (RBAC) for Administrators — a clean way of defining and enforcing which administrator gets access to which resources. With RBAC
for administrators, you are now able to segregate the duties of different administrators for compliance and to meet internal organizational security regulations.

So, what requirements does RBAC really address?

RBAC is important helps you answer the following questions for your NoSQL database:

1. Can I segregate the duties of my couchbase administrators?
2. Which administrators get access to which resource?
3. How do I centralize authentication of administrators in my environment?

So, how does RBAC meet the requirements?

The easiest way to understand RBAC is through an example.

Let’s say you have a team of 3-4 administrators responsible for Couchbase – Adam, Mary, Don and Kirk. Hopefully, you don’t want all of them to have full administrator privileges otherwise this feature is not going to be useful to you. Also, in a development-testing
environment, you might want to allow administrators full control over the cluster so that they can explore the Couchbase settings freely without being restricted and tune the cluster settings to prepare for production.

As you near production deployment,  you will need to start thinking about locking down your cluster (i.e. thinking about how you can segregate your administrator duties and figure out which administrators will need access to what resources). In most
enterprise deployments, centralizing authentication of users through LDAP is pretty common in production.

The first step to setting up RBAC is to create your administrative users in LDAP.  If you already have LDAP set up in your enterprise, you should first configure Couchbase to use LDAP.

There are 4 users needed in this example are – Adam, Mary, Don, Kirk and a user account for yourself.

Assigning Permissions to Administrators Through Role Membership

Next, you’ll want to figure out what level of permission to give to your administrators based on their job roles. Couchbase provides six distinct sets of permissions grouped by roles. This makes it easier for you to assign and understand admin access
without having to set individual permissions for each and every action possible.

These six sets of permissions are:

Full Admin: Can do anything possible to Couchbase resources. This is the full admin that you are already familiar with.  This is the highest level of access a admin user can have. So, what can a full-admin see in the UI? Pretty much
everything including security settings (under the newly added security tab in 4.5)

Cluster Admin: Similar to Full Admin, but with some restrictions around security control. This is best suited for when you want a group of admins to run your cluster but cannot give them any security privileges like ability to turn audit
on/off,  changing admin role memberships.

So, what can a cluster admin see in the UI? Everything but not the security tab.

Bucket Admin: This is best suited for when you want a group of admins who respond to application teams requests to tweak bucket settings – resetting a bucket password, changing bucket memory quotas, etc. So, what can a bucket admin see
in the UI under data buckets tab? Only the buckets you are administering.

For all other tabs (such as server nodes), it is read-only for bucket admins

View Admin: Let’s say you have an admin working with the application team to setup and deploy application views. For this, we have the view admin role.

Replication Admin: This is for admins responsible for your XDCR strategy. These are admins who setup XDCR cluster references  between clusters,
start/stop replications.

And finally,  Read-only Admin: Look, but don’t touch. Can view and inspect resources, but nothing else. This is not a new role in 4.5 but it’s something that you can use for your

Remember, these roles are overlapping, and the following diagram summarizes the role hierarchy –

Putting It All Together

So, now that you know the roles, it’s about getting Adam, Mary, Don, Kirk be members of the corresponding roles.

In Couchbase 4.5, this can be setup through the UI, REST and CLI

To summarize

RBAC is important helps you answer the following questions for your NoSQL database:

1. Can I segregate the duties of my couchbase administrators? Yes, now with RBAC for administrators in 4.5 you can!
2. Which administrators get access to which resource? It’s easy and simple — it depends on the role
3. How do I centralize authentication of administrators in my environment? LDAP needs to be used with RBAC and commonly is a way to centralize authentication for administrators.

We hope you’ve found this overview of Role-Based Access Control useful. We’re very excited about RBAC and look forward to building more enterprise-grade features for Couchbase Server in the future. Good luck using RBAC for administrators in your Couchbase
4.5 deployments!

We look forward for your feedback.