Securing NoSQL Database Using Roles in NosDB

In a previous post I described the different parts of NosDB Security in terms of realms, logins, users, authentication and authorizations. Here I will present a practical perspective of how to assign security privileges to users across realms.

But before we begin I want to briefly touch-back on what we have learned.

  • Realms: There are 3 realms in NosDB security. These realms are logical entities. The System Realm grants read-only access to the infrastructure. The Cluster Realm is where all the active participating machines are. The Database Realm is where you need to be to access the database.
  • Logins: Logins grant you access to the System Realm. Logins can be authenticated using either Windows Authentication or the built-in NosDB authentication.
  • Users: To perform any action either on the cluster or the database, users are created with a login.

Now that we have the basics defined, let’s take a look at how you would restrict or grant access to your data, based on users. Security Roles are what you assign to users to provide access/permissions to different parts of NosDB. There are three types of security roles in NosDB.

Cluster Roles

Assigning a cluster role to a user provides permissions to access the cluster configuration and also grants access to the Cluster Realm. Assuming you already know the basic architecture of a NosDB cluster (if not, check the documentation), a user can remove or add nodes to a shard, change the number of shards etc. To further define which specific changes a user is allowed to perform, the Cluster Role has three sub-types:

  • clusteradmin: Makes a user the cluster administrator. Allows a user to add/remove shards or servers and can also grant cluster roles to different users. This role also has the privilege to perform any cluster action that other roles can perform.
  • clustermanager: Per the cluster settings of a cluster administrator a cluster manager can manage that cluster. Privileges include stopping and starting shards and nodes.
  • dbcreator: A cluster can host multiple databases. To create a new database or delete one, a user needs the role of a database creator. While creating, this user can also provide database configurations.

While a cluster role can create or delete databases, it can also access the data as well. This helps segregate the roles and makes it easier to manage the different responsibilities for the Database Administrator.

Database Role

As discussed in the cluster role, a clustermanager or dbcreator can create databases in a cluster. To grant user access to a single database at a time, you assign database roles to the selected users and hence grant access to the Database Realm. Once again, like the cluster role, the database role is divided into further types of user control privileges.

  • db_owner: (Database Owner). A user assigned with this role has the privilege to perform any action on the chosen database. By any, I also mean this user can perform one of the most dangerous operations: Drop Database. So use this role with caution. This role can also grant database roles to different users.
  • db_admin : The Database Administrator role allows the user to perform CREATE, DROP, ALTER operations on collections. This user can also create indexes and deploy CLR functions, and grant and revoke database read and write roles of other users. The db_admin has access to the data as well; therefore only a few users should have this role. The only difference from a db_owner is that it cannot drop a database.
  • db_user: This role grants access to read or write to the database.
  • db_datawriter: A user with this role is granted only write access to the database.
  • db_datareader: A user with role is granted only read access to the database.

Server Role

Remember that a cluster role grants a user the right to add server nodes to the cluster. But you can’t just add any server machine to your cluster, you need to have server rights. Therefore, your user should also exist in that new server and your user should also have the server role.

Having said that, it follows that when a user is granted a cluster role on an existing cluster, s/he also has a server role on the machines in the cluster.

The types of server roles are as follows:

  • sysadmin: The system administrator role has all the privileges on that specific machine. This includes CREATE, DROP and ALTER USERS.
  • Security Admin: A user needs to be assigned this role in order to add a node in a cluster.

distributor role: This role applies to Distributor Service only. A distributor has permission to distribute client operations. More information on Distributors is available here

A Practical Example

Now let’s consider two users Bob and Jim and assume the following:

  • Bob has access to a cluster of 2 machines.
  • The cluster has 3 databases.
  • Jim wants to write to database 1.
  • And finally, Bob wants to scale the cluster to 3 shards, so he needs to add another machine in the cluster.

Let’s look at the user roles, by realm (cluster, database and server), required to achieve this.

To access the database, Bob needs to assign Jim a database role so that he can manipulate the data in database 1 without having access to database 2.

Now Bob needs to scale the cluster. For this Bob needs server role privileges on that new machine. Since Bob already has a cluster role, adding the new machine to the existing cluster only takes a few simple steps using NosDB Management Studio. The following figure explains this visually:

Roles - NosDB Security
Diagram: User Roles – NosDB Security

The best part in all of this is that Jim doesn’t know how many servers there are in the cluster and doesn’t even need to know. NosDB distributes the data in the database to provide a seamless user experience.

Conclusion

A good understanding of how database security works is fundamental to a great deployment. Because a NoSQL database has multiple machines, security is also more layered. Breaking down NoSQL database security privileges by users and realms makes it a lot easier to map the logic behind securing the database.

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *