The initial focus on Nun-db was to be fast and easy to use, then we moved to make it infinitely scalable and to deal with data conflicts as a first-class citizen, bringing even a few offline capabilities. Now it is time to think a bit about Security; up to this point, it has not been the focus. Security will probably drive the next six months of updates to Nun-db core, and the goal is to make it more suitable for production apps out of my control. While I will be writing examples of how to use Nun-db, my goal is to secure the database.

Latest Security Enhancements

Lately, I have implemented the concept of “Secure keys,” which means that any key prefixed by “\(" can only be set if the client is authenticated as the cluster admin. This has been a hidden feature for a long time; for example, the token for the database is stored as a key called "\)token,” and for obvious reasons, that key cannot and should not be read from any client without admin access, nor should it be sent to clients listing keys.

But now, after merging PR#83, all keys prefixed by “$$” can only be modified, listed, acquired, or watched by clients authenticated as cluster admins.

What does cluster admins mean?

Cluster admin refers to a client that authenticates with the cluster credentials using the command auth $USER $PWD. If that command is successful in that session, all subsequent commands will execute as a cluster admin, similar to a sudo su in Linux.

Existent Security keys

By default, only the $$token is protected, but over time, more and more implementations will use it to store metadata about Nun-db. All data about Nun-db is stored as Nun-db values; given its simplicity, we can abstract it to enable any of that.

What is next in Security?

• We will be implementing multiple users in a single database. Today, a database can only have one credential.
• Fine-grated permission control key level. Who can do what in what key?
• What else?